Allow for ledger-less DIDs

[llorllale]

Opening this issue to track the unresolved problem of how to respond to a DIDComm message in which the from header contains a DID/DID-URL for methods that are self-certifying and do not depend on a common VDR between sender and recipient (eg. did:key, did:peer).

Motivation:

Allowing use of "ledger-less" DIDs enables a party to communicate with a DIDComm agent without incurring the cost of registering a DID in a VDR.

Context:

It has been assumed that using initial-state would be a viable way to achieve support for ledger-less DIDs. We have not demonstrated how this can be done.

Expected outcomes:

• A mechanism proposed that would allow ledger-less DIDs
• Hopefully not incur too much bloat?
• Normative text detailing how an agent resolving the DID can send a reply back to the sender
• Non-normative examples and guidelines

[OR13]

I believe this can be achieved with customer resolver middleware that understands things like signed ietf json patch...

the resolver returns the did document, and then some functions interpret did url query / path and mutate the resulting ledger-less did document into the correct shape.

[swcurran]

I'm not clear where this comes into play. did:key cannot be used for DIDComm because (by definition) it doesn't have any way to have an endpoint. did:peer is by definition resolvable by the recipient that has the DIDDoc for the DID. There is a need to convey the did:peer to the recipient on connection setup -- is that the context of this issue?

[OR13]

https://w3c.github.io/did-spec-registries/#signed-ietf-json-patch-param https://github.com/decentralized-identity/did-spec-extensions/blob/master/parameters/signed-ietf-json-patch.md

I have been unable to implement did:peer mostly due to the lack of clarity regarding the operations in spec:

https://identity.foundation/peer-did-method-spec/#backing-storage

for example the signature format, is not fully defined... if its a JWS or detached JWS, then its relatively easy to implement, by AFAIK, its not.

in any case, imagine you have a did:peer implementation that works, the latest spec says that it starts as a did:key... you add a service endpoint to it... how do you communicate that you have a did document with a service endpoint?

You should be able to do something like this:

did:peer:123?signed-ietf-json-patch=<jws>

or 

did:peer:123?operation-that-adds-service=<????>

or

did:key:123?signed-ietf-json-patch=<jws>

Then, IF the resolver understands how to get a DID Document with a service in it, from the DID URL, you can start didcomm....

That IF is pretty massive today.... nobody really understands signed-ietf-json-patch and the did:peer spec does not encode a way to communicate its first operation as a query....

I would suggest that did:peer spec needs to be updated to make this easier / less of a unique feature/

[tmarkovski]

did:key cannot be used for DIDComm because (by definition) it doesn't have any way to have an endpoint.

DIDComm doesn't require a participant to have an endpoint. A server can accept a DIDComm payload from a sender using DID without needing any of their service entries. In cases where DIDComm transport is ephemeral, did:key can specify endpoint data as part of the DID URI for example did:key:alice/service?serviceEndpoint=ble:123&type=DIDComm.

I think there's an array of use cases where DIDComm will be extremely useful that shouldn't rely in ledger or any other online resolution. Self certifying keys like did:key and did:un should be able to be used in their ephemeral mode.

Edit: I was not aware of the DID extension for signed patch, looks like a great approach. Keeping my comment for intent.

[swcurran]

While there are a couple of important use cases for ephemeral (notably, one time authentication via presenting a proof or perhaps in person transactions where there is another channel), we should not encourage abusing the mechanism vs. a long-lived connection. In particular, the use case of issuing a credential via an ephemeral connection seems to me to be a really bad idea. Before issuing a credential, the issuer needs to verify that the entity to which they are issuing is the same entity with which the DIDComm connection has been established. As we have been clear -- establishing a channel is subject to attack and so should be verified after it is established.

[tmarkovski]

How is an issuer certain that the issued credential goes to the same entity as the connection it is sent to? Theoretically, this association is repudiable, unless the credential is issued to the same DID present in the connection, or the holder proves ownership of both DIDs.

[kdenhartog]

While there are a couple of important use cases for ephemeral (notably, one time authentication via presenting a proof or perhaps in person transactions where there is another channel), we should not encourage abusing the mechanism vs. a long-lived connection. In particular, the use case of issuing a credential via an ephemeral connection seems to me to be a really bad idea. Before issuing a credential, the issuer needs to verify that the entity to which they are issuing is the same entity with which the DIDComm connection has been established. As we have been clear -- establishing a channel is subject to attack and so should be verified after it is established.

Verification doesn't have to be done in DIDComm. One could just as easily verify out of band using traditional authentication methods. Not to mention you run into a bootstrapping issue when the first credential is being issued. I don't think such strict guidance is necessary, but it's definitely a security consideration that should be mentioned.

[llorllale]

Another consideration - although I perceive this to be of less value just because it doesn't seem to be brought up as often - is the final size of the identifier. The concern brought up in the past was that it would make encoding of out-of-band invitations too big (esp. QR codes).

[llorllale]

RE: signed-ietf-json-patch

I suspect a wrench in this approach might be that it's effectively tied to a mime type - application/json.

(also it might be considered too verbose - see my comment above)

Can a recipient of this identifier use signed-ietf-json-patch an a CBOR representation of the document?

[swcurran]

Is there a reason we would do a patch vs. a full replace for updating a did:peer? For an out-of-band message we (kind of) need to worry about size because of the QR code -- although I think we will need to redirection to be practical, so even then, the size is not that important. Once a secure channel is established, is patching important for other reasons than size?

[tmarkovski]

Is there a reason we would do a patch vs. a full replace for updating a did:peer?

If I understand correctly, this would be method specific. did:peer would use patch with op = replace, since the document resolved from the method itself is empty. did:key would use patch with op = add, since the document resolved already has keys.

[swcurran]

I still don't understand the concept of "did:key" with an endpoint. That doesn't make sense based on the definition of the did:key spec.

[OR13]

@swcurran https://github.com/decentralized-identity/did-spec-extensions/blob/master/parameters/signed-ietf-json-patch.md

the point is that signed-ietf-json-patch lets you augment ANY did method with authenticatable JSON patches... which lets you add features to DID Methods that the DID Method authors are intentionally blocking or never intended to support :)

Last time I tried to implement DID Peer, I came away feeling like it was not usable... hence my desire to use did:key with didcomm.... The reason I felt DID Peer was unusable was the lack of clarity in the spec regarding how operations were generated and signed, specifically cryptographically verifiable test vectors are missing from the spec.

here are some examples of test vectors for did:key...

• https://github.com/transmute-industries/did-key.js/blob/master/packages/test-vectors/src/vc-conformance/credential.json
• https://github.com/transmute-industries/did-key.js/blob/master/packages/test-vectors/src/did-core-conformance/ed25519/ed25519-jws.json
• https://github.com/transmute-industries/did-key.js/blob/master/packages/test-vectors/src/did-core-conformance/ed25519/ed25519.json

^ I needed something like this to implement did:peer... when I couldn't find it, I gave up trying to implement did:peer... since I already have support for did:key, did:web and sidetree based dids... I don't see the need for did:peer, and am waiting for KERI based methods to mature enough before attempting it again.

TL;DR - eager to support something like did:peer when KERI matures... until then, I'm using did:key / did:web / sidetree.

[kdenhartog]

@llorllale please add the needs additional discussion label if you feel we need to work through the solution. Otherwise please add the needs PR label if you feel this is ready to go

[TelegramSam]

This issue predates DID:Peer Method 2. Given method 2 supports specifying other keys and endpoints in a static way, I think we can safely close this issue.

[TelegramSam]

Closed via discussion in WG meeting 20210802. Please reopen if it should not have been resolved.