Add publicKeyHex as a valid publicKey format

[gjgd]

fixes #152

Added publicKeyHex as a valid publicKey format

The fact that publicKeyHex is missing from the did spec as a valid publicKey format is preventing us from adding did:elem to the universal resolver

Not sure if can just edit the v0.11 file or if I should create a v0.12, let me know!

[dmitrizagidulin]

@gjgd Ok, so, we're about to submit a PR (parallel to this one) that explains the context versioning mechanism (in a README in the contexts/ folder), which seems to have buy-in from at least some of the devs maintaining the contexts.

With that in mind, I recommend - make a v0.12 version (in addition to the v0.11 - leave v0.11 unchanged, without the term), and add the new term to /that/ one.

[gjgd]

Thanks @dmitrizagidulin , I put it in a separate file

[OR13]

This PR is semi-blocking the DIF interop project from demonstrating interoperability between DDOs with publicKeyHex and publicKeyJwk.

Per the spec: https://w3c-ccg.github.io/did-spec/#public-keys

The following is a non-exhaustive list of public key properties used by the community: publicKeyPem, publicKeyJwk, publicKeyHex, publicKeyBase64, publicKeyBase58, publicKeyMultibase, ethereumAddress.

There does not appear to be a single commited / hosted context that supports all of these, but there are context that support publicKeyBase58.

Additionally https://w3id.org/did/v0.11 redirects to https://w3c-ccg.github.io/did-spec/contexts/did-v0.11.jsonld, is not a hashlink, and provides no assurance that v0.11 context is immutable.

It seems likely that without a W3 hosted context that supports community key types, community members are likely to host their own contexts, is that a good thing or a bad thing?

I have been assuming that the ideal scenario is that all DID Methods would try their best to support the same latest context.

Maybe it is preferred that each DID Method host their own context which describes the key types and custom properties present in their DDO?

It feels like a security risk to point to a context you don't control, am I wrong to assume that?

[OR13]

It seems like community hosting of contexts won't work... and this PR is not sufficient to fix this issue because:

[
      {
        "@id": "did:elem:eURSFEEv6J7s3TJ-jhT_ZS4uGRyCDbwc347EWlqpNgw",
        "https://w3id.org/security#publicKey": [
          {
            "@id": "did:elem:eURSFEEv6J7s3TJ-jhT_ZS4uGRyCDbwc347EWlqpNgw#key-0"
          },
          {
            "@id": "did:elem:eURSFEEv6J7s3TJ-jhT_ZS4uGRyCDbwc347EWlqpNgw#key-JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw"
          }
        ]
      },
      {
        "@id": "did:elem:eURSFEEv6J7s3TJ-jhT_ZS4uGRyCDbwc347EWlqpNgw#key-0",
        "@type": [
          "https://w3id.org/security#EcdsaSecp256k1VerificationKey2019"
        ],
        "https://w3id.org/security#publicKeyHex": [
          {
            "@value": "027560af3387d375e3342a6968179ef3c6d04f5d33b2b611cf326d4708badd7770"
          }
        ]
      },
      {
        "@id": "did:elem:eURSFEEv6J7s3TJ-jhT_ZS4uGRyCDbwc347EWlqpNgw#key-JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw",
        "@type": [
          "https://w3id.org/security#EcdsaSecp256k1VerificationKey2019"
        ],
        "https://w3id.org/security#publicKeyJwk": [
          {
            "@id": "_:b0"
          }
        ]
      }
    ]

https://web-payments.org/vocabs/security#EcdsaSecp256k1VerificationKey2019 https://w3id.org/security#publicKeyJwk

These links won't point to anything, but does that really matter?

If it does, then there seems to be a tight coupling between valid context updates and the html content of https://w3id.org...

Based on https://github.com/w3c-ccg/did-spec/pull/272

It seems like we may want to add some additional criteria to the versioning requirements, namely that there not be any broken links in the contexts.

[OR13]

After a few more days of pondering, I created a self hosted solution for this.

There appears to be a tight coupling between contexts and their documentation.

When we update a context, there should be no broken links, new properties should be documented!

I don't think its possible to do that with the hosting setup that exists currently, or it will require several PRs across a number of repos, and I suspect that will lead to no actual documentation for contexts, as is the case currently. For example, where is the documentation for:

https://w3id.org/security/v2 ?

None of these properties are defined here: https://w3id.org/security#, these docs were last updated in 2016.

This PR: https://github.com/w3c-ccg/did-spec/pull/207

Added properties to the context that are not documented, and some of these properties are actually not usable without #270 which adds support for the key types used by EcdsaSecp256k1Signature2019...

As the DID Spec moves along, I would encourage us to host context and documentation in the same place, so that contributors can fix issues like this easier in the future.

If the repo example I have linked is useful for that purpose, feel free to copy it:

https://github.com/transmute-industries/context/issues/1

Just to be super clear, I want to use the W3 hosted did spec without extending it, and I want to contribute to it.

Contribution should not result in broken links, and should not need to be spread across multiple repos, because that will cause broken links, and slow down contribution.

Should I open issues for undocumented context properties in the did spec and cross link to these repo's?:

https://github.com/perma-id/w3id.org/blob/master/security/.htaccess https://github.com/web-payments/web-payments.org

I'm not trying to be a pest, clean documentation will help us attract more contributors, and will make all of our lives easier. I'm happy to help accomplish this however I can.

[msporny]

@OR13 you're catching us at a really heavy time of conferences and travel. Almost everyone in the community is traveling to/from RWoT9, APConf2019, W3C TPAC 2019, and a variety of other things. There are answers to some of your questions and plans for others, but I need to catch a 5am flight and need to go to sleep. Others are in the same position. Can you request some time to talk about this on a CCG call in early October? Self-hosting the solution (or ideally just overloading the JSON-LD document loader) should work for you for the time being.

[OR13]

@msporny thanks! I will request some time on the call :)

[brentzundel]

This repo is scheduled to be archived. The work has moved to the DID WG. The artifacts in the DID WG repository (including the context document) share commit history with this repo, so it should be possible to raise this PR against that repo.

[peacekeeper]

@gjgd as discussed at IIW29, do you think you could re-create this PR in the DIDWG repo: https://github.com/w3c/did-spec/pulls and then close it here?

[gjgd]

Yes, I'm not sure we want to merge it as is anymore but it's done @peacekeeper https://github.com/w3c/did-spec/pull/63

[peacekeeper]

Thanks, we can continue to discuss at https://github.com/w3c/did-spec/pull/63. Closing.