Verification method block should be a first citizen like public keys

[awoie]

Public keys in the public key section can be referenced in other sections of the DID Doc, e.g., authentication. That is great because it makes the DID Doc smaller in case the same public key is used for multiple purposes.

Verification methods should have the same option.

As per https://www.w3.org/TR/did-core/#authentication:

Each verification method MAY be embedded or referenced.

ATM, referencing verification methods other than public keys is not possible. IMO, it would make more sense to introduce verificationMethod as a new first citizen block. That block would list the verification methods, so that they can be referenced in other sections of the DID Doc, e.g., authentication, in the same way as public keys.

Another approach would be to just rename the publicKey section in verificationMethod which might be even the better approach.

An example of a verification method that would benefit from this approach is ethereumAddress.

[awoie]

@OR13 @dlongley In case there is already a way to achieve that behaviour, please provide an example and we can close that issue. It might be even worth to provide an example in the specification. I could probably also live with having an ethereumAddress array similar to publicKey and just referring to those elements from the authentication section.

[OR13]

This is essentially a request to rename publicKey verificationMethod... which IMO is an excellent idea for a number of reasons...

In an ideal world, we don't reuse keys for things, so there is no size benefit to linking, since each key is declared only in the block for which it is used....

In the real world, its extremely common to declare a key once in publicKey section, and then reference it from all the other locations...

For DID Methods that don't have a default public key... like did:ethr this creates an awkward situation where we are listing ethereumAddress under publicKey.... when it's clearly not one.

IMO, this is what a did:ethr which has not been updated should look like:

{
    "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://identity.foundation/blockchain-identity/v1"
    ],
    "id": "did:ethr:0x74fd35392f1c2a97c6080e0394b1995b0e63c8bf",
    "verificationMethod": [
      {
        "id": "did:ethr:0x74fd35392f1c2a97c6080e0394b1995b0e63c8bf#0",
        "type": "EcdsaSecp256k1RecoveryMethod2020",
        "controller": "did:ethr:0x74fd35392f1c2a97c6080e0394b1995b0e63c8bf",
        "ethereumAddress": "0x74fd35392f1c2a97c6080e0394b1995b0e63c8bf"
      }
    ],
    "authentication": [
      "did:ethr:0x74fd35392f1c2a97c6080e0394b1995b0e63c8bf#0"
    ],
    "assertionMethod": [
      "did:ethr:0x74fd35392f1c2a97c6080e0394b1995b0e63c8bf#0"
    ],
    "capabilityDelegation": [
      "did:ethr:0x74fd35392f1c2a97c6080e0394b1995b0e63c8bf#0"
    ],
    "capabilityInvocation": [
      "did:ethr:0x74fd35392f1c2a97c6080e0394b1995b0e63c8bf#0"
    ]
}

[OR13]

PS, its totally valid today... https://github.com/w3c/did-core-registries/blob/master/contexts/did-v1.jsonld#L140

all we need is to define https://identity.foundation/blockchain-identity/v1.

[awoie]

@OR13 thanks, sounds pretty good!

[kdenhartog]

@awoie with PR #284 and the inclusion in this registry. I think this issue is ready to be closed. Are you satisfied with the outcome or is there more actions that need to be take non this?

[rhiaro]

@kdenhartog PR #284 expands the definition in terminology, but doesn't add verificationMethod to the core properties section of the spec. I can take an action to do this (sounds like that's what is needed?). Removing publicKey in favour of verificationMethod may then be a separate followup..

[awoie]

@rhiaro I was about to add the same note. Thanks for pointing that out. If there is a PR that fixes that, I'm fine with closing this issue.

[kdenhartog]

Thanks for the clarity! Makes sense to me now that you've pointed it out.