DID Fragments missing from did:peer:2 VerificationMethod Ids -- impossible to reference in Services
Closed this issue · 3 comments
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:2identifier into the service endpoint, BUT - The encoded service endpoint (including the key reference) is part of the
did:peer:2identifier.
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 thedid:peer:2identifier (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.
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.
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