did:webplus - HackMD

# did:webplus notes from socialweb.coop internal discussion <ul> <li>README: <a href="https://github.com/LedgerDomain/did-webplus">https://github.com/LedgerDomain/did-webplus</a></li> <li>Why not <code>did:web</code>?</li> <ul> <li>lack of built-in 'historicity':</li> <ul> <li> <blockquote> One of the biggest challenges in delivering <code>did:web</code> within a highly regulated industry such as the pharma supply chain is its lack of built-in "historicity." Many real-world <code>did:web</code> implementations assume that W3C Verifiable Presentations are ephemeral, needing to be verified at time of receipt (e.g. to access a particular resource) but not requiring retroactive verifiability in the event of a later audit. </blockquote> </li> </ul> </ul> <li>No promise of compatability with <code>did:web</code></li> <ul> <li> <blockquote> Note that there is no formal promise that <code>did:webplus</code> is actually directly compatible with <code>did:web</code>, just that <code>did:web</code> was the initial inspiration. </blockquote> </li> </ul> <li>Overview</li> <ul> <li> <blockquote> the idea is that each DID has an associated microledger of DID documents, with each DID document referencing the self-signature of the previous DID document. The microledger is intended to be immutable, append-only, and allow updates only from authorized parties. It provides a totally-ordered sequence of DID documents whose validity durations are non-overlapping. This is accomplished by the use of successive validFrom dates </blockquote> </li> </ul> <li>Uses <code>capabilityInvocation</code></li> <ul> <li> <blockquote> The root DID document's "selfSignatureVerifier" field must correspond to one of the public keys listed in the "capabilityInvocation" field of the root DID document itself. This field defines which keys are authorized to update this DID's DID document, and in the case of the root DID document, it establishes an initial self-consistency for that authority. </blockquote> </li> </ul> <li> <blockquote> Weakness: It is possible for a non-root DID document to be altered </blockquote> </li> <ul> <li>This seems unacceptable.</li> <li>Would it be true if every did document had a <code>proof</code> of its integrity? + proof of authority to update from a prev didDoc it points to?</li> </ul> <li> <blockquote> <code>did:web</code> is a weak DID method </blockquote> </li> <li>Comparison Table with <code>did:web</code> and <code>did:ethr</code> 🌅</li> <ul> <li> <a href="https://github.com/LedgerDomain/did-webplus#comparison-of-classes-of-did-method">See did-webplus</a> </li> </ul> <li>Questions</li> <ul> <li>Why does the did doc have <code>selfSignature</code> and not <code>proof</code>?</li> <li>How is <code>selfSignature</code> produced exactly? (other than in rust code)</li> <li/> <li>Why does the prev link need to be over the signature and not the hash or even just a unique identifier of the prev version? i.e. <code>prevDIDDocumentSelfSignature</code></li> <li/> </ul> <li>Suggestions</li> <ul> <li><code>selfSignature</code> -> <code>proof</code> a la <a href="https://www.w3.org/TR/vc-data-integrity/">vc-data-integrity</a></li> <li><code>validFrom</code> -> <code>validity: { from }</code></li> <li>Don't make a new serialization for Key IDs. Use an object or COSE</li> <ul> <li> <blockquote> The fragments defining the key IDs for each public key in the DID document are derived from the public keys themselves, using conventions found in KERI (a prefix indicating the key type, then the base64-encoding of the public key bytes) </blockquote> </li> </ul> <li>If using <code>capabilityInvocation</code>, the <code>capabilityInvocation</code> verificationMethod should have to be opted-in to did doc updating. i.e. define a capability action like <code>update</code></li> <ul> <li>without a specific capability name and resource, just use <code>controller</code></li> </ul> <li>Dont overload <code>hl</code> with a <code>selfSignature</code> value, use it with a <a href="https://datatracker.ietf.org/doc/html/draft-sporny-hashlink">hashlink</a> as linked to by <a href="https://www.w3.org/TR/did-core/#did-parameters">did-core</a></li> <li/> <li/> <li/> <li/> <li/> </ul> </ul>