add support for all DID doc updates from latest DID core spec

Reposting the proposal from https://github.com/decentralized-identity/ethr-did-resolver/issues/99#issuecomment-791716224 as a separate issue:

The current DIDAttributeChanged scheme used to populate the DID document is insufficient for covering all the cases described by the more modern versions of the DID spec.

@AlexYenkalov has suggested a naming scheme that uses a set of characters to describe where a key should be placed.

const DOCUMENT_SECTION_FLAGS = {
  v: 'verificationMethod',
  a: 'assertionMethod',
  u: 'authentication',
  k: 'keyAgreement',
  d: 'capabilityDelegation',
  i: 'capabilityInvocation',
  s: 'service'
}

Besides this, the did/ prefix can also be shortened (or dropped?) to make room for more expressive future additions

So, instead of trying to match the attribute name against:

/^did\/(pub|auth|svc)\/(\w+)(\/(\w+))?(\/(\w+))?$/

the resolver would look for something like this

/^d\/([vaukdis]*)\/(\w+)(\/(\w+))?$/

Examples:

• if a key needs to be expressed as a verificationMethod and also be listed in the authentication, assertionMethod, capabilityDelegation and capabilityInvocation sections, the attribute name would start with d/vaudi/
• if a keyAgreement key is added, the attribute name would start with d/vk/
• if a service is added, then d/s/

This can be made even more efficient by recognizing that keys would always be listed in the verificationMethod array and referenced from the other sections, so the /v/ flag can be dropped and considered implicit as long as the /s/ flag is not used.

There is also the problem of the types of verificationMethods that can be listed. The names of the methods listed in the DID spec registries are quite long, so they would not fit into the 32-byte limitation of the attribute name.

To get around this problem, I propose implementing a mapping to shorter strings:

const VERIFICATION_METHOD_TYPES: Record<string, string> = {
  jwk: 'JsonWebKey2020',
  secp256k1: 'EcdsaSecp256k1VerificationKey2019',
  secpk1Rec: 'EcdsaSecp256k1RecoveryMethod2020',
  secpk1Sch: 'SchnorrSecp256k1VerificationKey2019',
  ed25519: 'Ed25519VerificationKey2018',
  x25519: 'X25519KeyAgreementKey2019',
  blsG1: 'Bls12381G1Key2020',
  blsG2: 'Bls12381G2Key2020',
  gpg: 'GpgVerificationKey2020',
  rsa: 'RsaVerificationKey2018'
}

If the list of these methods is expected to remain relatively stable, an even more efficient mapping can be created:

const VERIFICATION_METHOD_TYPES: Record<string, string> = {
  j: 'JsonWebKey2020',
  s: 'EcdsaSecp256k1VerificationKey2019',
  R: 'EcdsaSecp256k1RecoveryMethod2020',
  S: 'SchnorrSecp256k1VerificationKey2019',
  e: 'Ed25519VerificationKey2018',
  x: 'X25519KeyAgreementKey2019',
  b: 'Bls12381G1Key2020',
  B: 'Bls12381G2Key2020',
  g: 'GpgVerificationKey2020',
  r: 'RsaVerificationKey2018'
}

Continuing along this line of reasoning, the key encoding can be shortened to one of:

const KEY_ENCODINGS: Record<string, string> = {
  `j`: `publicKeyJwk`,
  `58`: `publicKeyBase58`,
  `e`: `ethereumAddress`,
  `b`: `blockchainAccountId`,

  //other legacy types can also be expressed, since they are trivial to implement without dependencies:
  `16`: `publicKeyHex`,
  `64`: `publicKeyBase64`,

  //these are very inefficient in terms of storage
  `g`: `publicKeyGpg`,
  `p`: 'publicKeyPem'
}

There can be an implicit encoding of base58btc(publicKeyBase58) if none is specified.

Example:

• to list an X25519KeyAgreementKey2019 with base58btc encoding, one would publish an attribute with the name d/k/x/58
• to list an RsaVerificationKey2018 assertionMethod with publicKeyPem encoding, one would publish an attribute with the name d/a/r/p
• to list an EcdsaSecp256k1RecoveryMethod2020 assertionMethod and authentication with ethereumAddress encoding, one would publish an attribute with the name d/au/R/e

Any thoughts?

cc @awoie @rado0x54

[mirceanis]

@AlexYenkalov if you are starting from a keypair, then you can use did:ethr:<publicKey> instead of did:ethr:<ethereumAddress>. Starting with the ethereumAddress representation, it’s impossible to add the full public key to the DID document for fresh DIDs

The default document for a did:ethr<publicKey> will contain a verificationMethod with publicKeyHex that can be converted to JWK. For secp256k1 I suppose the dependencies to do this conversion to JWK are already imported by the resolver so perhaps that would be an option.

[mirceanis]

Hi @leowcy , Those 2 keys are optional in the DID spec and were not added to this DID method because there is no equivalent mechanism that could populate them.

There is a potential use for alsoKnownAs to link together a did:ethr:<publicKey> to its subset referred to by did:ethr:<ethereumAddress>, or perhaps even a little further with using did:ethr:<ens.domain>, but at this point these are not necessary, and would only serve to complicate the spec.

did:ethr is based on ERC1056 which has the concept of owner, but that is only useful for the ERC1056 smart contract implementation, and is not meant to be reflected in the DID document as a controller using a DID URI format, but rather as one of the verification methods using at most a blockchainAccountId, since it is represented internally as an ethereum address.