DID Fragments missing from did:peer:2 VerificationMethod Ids -- impossible to reference in Services

[swcurran]

It is important that for each key defined in a did:peer:2, there be a fragment on the ID in the expanded DIDDoc, and the fragment by formally defined in the specification. This is necessary so that a service endpoint can deterministically reference the ID of a key when creating the did:peer:2. Without a fragment (as shown in [Example 4]()), we get to a chicken and egg problem:

• A Service endpoint needing to include the ID of a key in the DID, must insert the did:peer:2 identifier into the service endpoint, BUT
• The encoded service endpoint (including the key reference) is part of the did:peer:2 identifier.

To correct this, I will propose the following PR:

• the spec defines that the fragments are of the form #key=<N>, where is the ordered number of the key, starting with 1 in the did:peer:2 identifier (e.g., #key-1, #key-2).
• the spec defines that a key in the DIDDoc can be referenced by only the fragment (e.g. #key-1).
• Update Example 4 to show these new requirements.

[FabioPinheiro]

I had the impression that the DID Core specs mention that when using the fragments alone in the refers to himself.

The did:peer implementations already defines how to determine the fragments for keys by using the publicKeyMultibase of the key. Although I prefer an index base name I think is to late to change.

[FabioPinheiro]

Thinking again maybe is not to late. Since everyone already implemented on different ways. Again interoperability is the hardest thing to achieve

For example Indicio-tech/didcomm-demo is using ...#6LSghwSEv and I was expecting ...#6LSkGy3e2z54uP4U9HyXJXRpaF2ytsnTuVgh6SNNmCyGZQZ The DID in question is did:peer:2.Ez6LSghwSE437wnDE1pt3X6hVDUQzSjsHzinpX3XFvMjRAm7y.Vz6Mkhh1e5CEYYq6JBUcTZ6Cp2ranCWRrv7Yax3Le4N59R6dd.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9hbGljZS5kaWQuZm1ncC5hcHAvIiwiciI6W10sImEiOlsiZGlkY29tbS92MiJdfQ

cc @dbluhm

[dbluhm]

This should now be resolved by #62