Public key ID format

[davebryson]

The spec defines 2 specific approaches for the format of a public key ID: https://identity.foundation/peer-did-method-spec/#publickey. While I think they are good approaches, they can be limiting in some cases.

For example, an HDKD based 'wallet' seems like a logical approach to generate a number of pairwise, n-wise DIDs and their associated keys for a user. However, HDKD uses paths such as m/0/1/1 as the key identifier. In order to be spec compliant, and HDKD 'wallet' would need to have additional logic and storage just to map paths to Peer formatted public key ids and vice-versa.

Is there a need for Peer DIDs to enforce a specific format for key ids?

[dhh1128]

This is a good question. I don't think there is any incontrovertible reason why did:peer needs to be opinionated, but there is a medium-to-strong desire to be simple. The key ID formats that are given were intended to limit the difficulty of implementing the spec.

Having said that, I don't want to preclude good connections to hardware-based key tech, so maybe we should introduce more flexibility.

I'd be curious to get an opinion from @OR13 , who has followed key format debates in W3C more closely than I have, and also from @SmithSamuelM , who may have some thoughts about KERI's opinion on the subject.

[OR13]

oh boy do I have opinions on this subject....

1. JOSE is the most common web based key representation out in the wild, with excellent support in most languages and web browsers.
2. Muticodec is easy to extend, fits well with content addressing IPFS/ IPLD / Bitcoin ecosystem, and critically, its not blocked by the political dragon that is registering things with IANA.... https://github.com/multiformats/multicodec/blob/master/table.csv
3. COSE is poorly supported binary version of JOSE, I'd personally not recommend planning support for it out of gate.

You will be shooting your DID Method in the foot, if you do not support 1 and 2... 3 is a stretch goal.

[dhh1128]

@OR13 : just to be clear, the peer DID spec supports any key format -- what we are talking about here is the format of the id of the keys. The ID format is relevant to the CRDT logic.

[OR13]

The value of the id property MAY be structured as a compound key. This is especially useful for integrating with existing key management systems and key formats such as JWK. It is RECOMMENDED that JWK kid values are set to the public key fingerprint. It is RECOMMENDED that verification methods that use JWKs to represent their public keys utilize the value of kid as their fragment identifier. See the first key in EXAMPLE 15 for an example of a public key with a compound key identifier.

https://w3c.github.io/did-core/#public-keys

If the kid is present in s JWS / JWE... it should be a DID URI... see my proposal for JOSE - DID Sanity here: https://github.com/decentralized-identity/did-jose-extensions/blob/master/options.md#kid-value-in-jwajwe

[OR13]

if did peer is a linked data did document (uses @context)... you can shorten the verificationMethod identifier, with @base.... and retain linked data status.

https://didme.me/did:meme:1zgsya8mdj6mq4ytx7a57fx89r0c404eyqej6kfl2wtm3fyvm5qgpngs0725xp

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    {
      "@base": "did:meme:1zgsya8mdj6mq4ytx7a57fx89r0c404eyqej6kfl2wtm3fyvm5qgpngs0725xp"
    }
  ],
  "id": "did:meme:1zgsya8mdj6mq4ytx7a57fx89r0c404eyqej6kfl2wtm3fyvm5qgpngs0725xp",
  "publicKey": [
    {
      "id": "#z6MksH8do3evRtfrCSiF1Pg5qXkKWwbBBXAno2iiHQHWAgsU",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:meme:1zgsya8mdj6mq4ytx7a57fx89r0c404eyqej6kfl2wtm3fyvm5qgpngs0725xp",
      "publicKeyBase58": "DpsbCoQV6MBP5wsYKpiEzSCKhNKKmdvS71onT8KVFU66"
    }
  ],
  "authentication": [
    "#z6MksH8do3evRtfrCSiF1Pg5qXkKWwbBBXAno2iiHQHWAgsU"
  ],
  "assertionMethod": [
    "#z6MksH8do3evRtfrCSiF1Pg5qXkKWwbBBXAno2iiHQHWAgsU"
  ],
  "capabilityDelegation": [
    "#z6MksH8do3evRtfrCSiF1Pg5qXkKWwbBBXAno2iiHQHWAgsU"
  ],
  "capabilityInvocation": [
    "#z6MksH8do3evRtfrCSiF1Pg5qXkKWwbBBXAno2iiHQHWAgsU"
  ],
  "keyAgreement": [
    {
      "id": "#z6LSkAAvzPiT1JcSSRrBD6Tu353u4XGCDpjVBL83y28dLeAW",
      "type": "X25519KeyAgreementKey2019",
      "controller": "did:meme:1zgsya8mdj6mq4ytx7a57fx89r0c404eyqej6kfl2wtm3fyvm5qgpngs0725xp",
      "publicKeyBase58": "9UzmU5uauqthM3UQgSwwiUqRDNj5XDZLJMQNUZV6dGPk"
    }
  ]
}

[OR13]

if did peer is not planning on using JSON-LD / documentLoaders... We will need to describe document dereferencing yet again.... I strongly suggest keeping @context... especially for interoperability with LD Proofs.

[dhh1128]

@OR13 : My intention with respect to JSON-LD is to describe the structure of peer DID docs such that JSON-LD is an option; that is, we dot all the i's and cross all the t's needed to make a peer DID doc consumable in JSON-LD stacks. We always put @context at the top. We create JSON-LD context file(s) for peer DIDs and publish/register them, for example. However, I don't want to make JSON-LD a strong assumption of all implementations, and I personally don't intend to use JSON-LD to parse/consume the docs, in the code I write. This is because I do not believe in the value prop of ultra-flexible extensibility of DID docs for the semantic web; I think the value of DID docs is in the subset of their semantics that I can hard code. (In contrast, I do believe in the value prop of JSON-LD for VCs. So I am not down on JSON-LD generally; I just think DID docs is the wrong sweet spot.)

[SmithSamuelM]

I want to support @dhh1128 position. I concur that the Semantic RDF/JSON-LD model is most beneficial for small contexts but which have variability and therefore need high extensibility. In other words many sets of shallow ontologies that have some degree of intersection or overlap. The VC schema use case fits this extremely well. If there is an ideal application for RDF/JSON-LD it is VC schema. Moreover, the principle limitation of Semantic RDF/JSON-LD is that there is no practical universal ontology. For numerous well documented reasons, ontologies break down as they grow in scope . Thus limited scope ontologies are a sweet spot for extensibility. However when there is not a high degree of variability within scope, as is the majority use case for DID Docs, then for most practitioners, the extensibility overhead of RDF/JSON-LD is not justified by its benefits. Clearly the overhead cost is relative to the practitioner. Someone who is using JSON-LD/RDF extensively for other purposes will see a much lower overhead than someone whose only use case is for a DID:Doc. But just based on the demographics of web application development alone, the practitioners adopting DIDs going forward will be overwhelmingly JSON/Web practitioners not JSON-LD practitioners. This means care should be taken to minimize the JSON-LD overhead associated with adoption not increase it. Indeed the first meaningful exposure these practitioners may have to JSON-LD will be the need to populate the JSON-LD side of the registry for new JSON DID Doc properties. IMHO therefore it is concomitant on the JSON-LD community to remove JSON-LD friction as much as possible as this friction will limit the adoption rate which is bad for the community in general.

[OR13]

agreed, but deleting an @context to break interoperability with JSON-LD seems like a bad idea for me... I would not recommend anyone write a spec encouraging people to do that... just ignore it... like we are asked to ignore unknown properties in did core today.

[dhh1128]

@OR13 : yes, that (keeping @context) is what I was planning on. I think we are aligned (enough).