search

w3c / did-resolution

RELEASED DRAFT: Decentralized Identifier Resolution (DID Resolution) 0.2 Specification
https://w3c.github.io/did-resolution/
Other
19 stars 9 forks source link

DID Resolution: Proof of inclusion of DID document in state of Verifiable Data Registry #102

Open Therecanbeonlyone1969 opened 1 year ago

Therecanbeonlyone1969 commented 1 year ago

Motivation: Given that Zero Trust architectures are becoming mandated by nation-states, most, if not all, Zero Trust architecture use cases utilizing DIDs have the following user story: As a User, I must be able to verify that the DID document for a given DID that belongs to a DID method that specifies a particular Verifiable Data Registry and that is provided to me through the DID resolution process is included in the current state of the Verifiable Data Registry specified in the DID method.

Done Criteria: A cryptographic proof of inclusion of the DID and its DID document in the state of the Verfiaible Data Registry as specified in the DID's DID method. A user must be able to independently verify this cryptographic proof-of-inclusion.

Issue: Since there is no requirement in the section of DID Resolution Metadata for proof that a DID document resolved as part of the DID resolution process is part of the state of the Verifiable Data Registry as specified in a DID's DID method, each user must independently verify the proper state inclusion directly on the Verifiable Data Registry which is a) not always feasible given wildly varying operating conditions and b) provided access methods may not necessarily be secure or private or both. In any event, this introduces new trust assumptions into a Zero Trust architecture rather than minimizing them.

Proposed Solution:

OR13 commented 1 year ago

See also:

TLDR, not all VDRs are append only logs / built on merkle trees / support inclusion or consistency proofs...

And we don't have standard ways to represent inclusion proofs, even for standard binary merkle trees yet, but that work is underway in IETF SCITT and KEY TRANS groups, I suggest helping push it along there.

The DID WG will not be charted for some time, and did method specific VDR issues are possibly not going to be in scope... having a stronger basis at IETF would make it more likely that this kind of thing could be made in scope for W3C, although I would be extremely concerned about the politics of the W3C leading to poor choices on this front, specifically, multicodec specific tree algorithms, and general avoidance of JOSE and COSE.

I think the W3C is not the place to define lower lever cryptographic things, like verifiable data registries or blockchains that might support inclusion proofs.

Therecanbeonlyone1969 commented 1 year ago

See also:

TLDR, not all VDRs are append only logs / built on merkle trees / support inclusion or consistency proofs...

And we don't have standard ways to represent inclusion proofs, even for standard binary merkle trees yet, but that work is underway in IETF SCITT and KEY TRANS groups, I suggest helping push it along there.

The DID WG will not be charted for some time, and did method specific VDR issues are possibly not going to be in scope... having a stronger basis at IETF would make it more likely that this kind of thing could be made in scope for W3C, although I would be extremely concerned about the politics of the W3C leading to poor choices on this front, specifically, multicodec specific tree algorithms, and general avoidance of JOSE and COSE.

I think the W3C is not the place to define lower lever cryptographic things, like verifiable data registries or blockchains that might support inclusion proofs.

@OR13 Agreed that not all VDRs are append-only logs / built on Merkle trees/support inclusion or consistency proofs.

The point is not to specify the details of a proof but rather that a proof (in whatever form) that is verifiable by a user is included in the did resolution metadata. It should be up to each DID method to specify the cryptographic details whether those details are standardized or bespoke is not really important, IMHO.

What is important IMHO, is that without such a requirement Zero Trust architectures are compromised -- not that anyone is really implementing them though everyone claims that they are -- by adding more and unnecessary trust assumptions. And given that this is started to be mandated, it could become a real impediment to DID adoption ... just saying.

peacekeeper commented 1 year ago

I agree with @OR13 and @Therecanbeonlyone1969 that even though it would clearly be desirable to have some kind of proof in the metadata which would allow independent verification of the result, this won't work for all DID methods. At some point during the DID WG there was considerable interest from some members of the group to fundamentally build the concept of "proof of control" into DID documents, but this idea wasn't adopted. The group felt that if such a requirement was added, then this would undermine the very flexible and extensible concept of DIDs and DID methods.

There are already several DID methods which add such metadata or are planning to do so, e.g. did:indy (state proofs from the ledger), did:keri (key event log).

I think this would belong into DID document metadata rather than DID resolution metadata, since it's metadata about the DID and DID document, not about a specific DID resolution process.

Finally, depending on your DID resolver architecture (which can come in different forms), you may not actually need such a proof in order for the result to be trustable. Let's say you operate your own DID resolver instance connected to your own DLT full nodes for the DID methods you want, and let's say your application connects to that DID resolver instance via mutually authenticated TLS or via DIDComm, then there isn't really any third-party intermediary that could manipulate the results, so that's probably secure enough for many use cases.

Having said all that, I do think it would be useful for a future DID Core spec or some extension to specify in more details HOW proofs of inclusion (or similar) should be part of metadata, if supported by a DID method, but without making that mandatory.

pauldesmondparker commented 1 year ago

To add a user story as 2 cents.

Context: We use a VDR to resolve DIDs via DIDComm, which works perfectly fine at the non-relay level. We connect to a VDR node via SSL and have the assurance of their FQDN and TLS that they are who we think they are, and that they would not pass us data that is modified in any way, maliciously or otherwise.

However, we have another consumer of identity that is a smart contract. It must rely on relayed DIDComm messages. If those messages have no inherent proof of providence, then we must jury-rig it, introducing the relay as a trusted provider of that proof.

This @peacekeeper :

... application connects to that DID resolver instance via mutually authenticated TLS or via DIDComm, then there isn't really any third-party intermediary that could manipulate the results ...

is not true in the context of relayed DIDComm messages.

The other thing that concerns me here is that DIDComm messages are meant to be transport agnostic. By relying on the security of the transport layer, we break that covenant. Which is more important, that DIDComm is transport agnostic, or that did-core isn't opinionated about proof of inclusion?

Speaking to the point about the location of the metadata, I don't understand the reasoning for putting this on the metadata of the DIDDoc:

I think this would belong into DID document metadata rather than DID resolution metadata, since it's metadata about the DID and DID document, not about a specific DID resolution process.

The proof of inclusion is like proof of storage, i.e. if your HDD had to come back to you and give you proof that it had saved your file. That has nothing to do with your word document itself, but the processes associated with storage and retrieval.

peacekeeper commented 1 year ago

This @peacekeeper :

... application connects to that DID resolver instance via mutually authenticated TLS or via DIDComm, then there isn't really any third-party intermediary that could manipulate the results ...

is not true in the context of relayed DIDComm messages.

Strange, I thought that DIDComm messages are end-to-end encrypted, and that relays could potentially withhold or delay or replay a message, but that they can't manipulate the encrypted payload intended for the recipient.

The other thing that concerns me here is that DIDComm messages are meant to be transport agnostic. By relying on the security of the transport layer, we break that covenant.

I agree. I never said that DIDComm should rely on the security of the transport layer, or that DIDComm shouldn't be transport agnostic. Maybe you misread my comment.

I don't understand the reasoning for putting this on the metadata of the DIDDoc:

Maybe you are confusing the DID document with DID document metadata? Those are two different things. See https://www.w3.org/TR/did-core/#did-document-metadata. I like your "Word document on an HDD" metaphor. Proof of storage in this case is metadata about the file, just like DID document metadata is metadata about the DID document.

pauldesmondparker commented 1 year ago

@peacekeeper Thanks for the did-document-metadata reference +1

Envelopes for DIDComm messages are here. Indicating that the plaintext DIDComm can be encrypted, but don't not need to be.

ntn-x2 commented 1 year ago

My (other) 2 cents. I see from the DID resolution spec v0.3, specifically in section 6.2, that resolution metadata can potentially change between resolutions of the same DID, even if the document has not changed since last resolution.

Our experience is that typically including a proof-of-storage as part of the response would change the value of the proof, hence the content of the metadata, as soon as the underlying storage Merkle root changes, not necessarily when the DID Document changes. It is true that the same proof, anchored to the same block, could be returned multiple times, but this now provides weaker guarantees about the "freshness" of the resolved DID document.

As of now we don't make use of this specific feature, but as we are planning to move away from centralized RPC nodes and more towards light clients, this will become a discussion point, at some stage. My opinion is that proof-of-storage of the underlying storage, where applicable, should be part of the resolution metadata and not of the document metadata, as it does not add any information about the document itself, but rather it provides authority and trust over the resolution process.

Any other thoughts on this?

peacekeeper commented 1 year ago

@ntn-x2 Interesting, thanks for the explanation! Maybe this is an example where it could be argued either way.

typically including a proof-of-storage as part of the response would change the value of the proof

I find this especially interesting. What would happen if two different resolvers (potentially even two different implementations) resolve the DID at exactly the same time? Would the proof be the same, or different?

Note that the DID Resolution specification is still at an early stage (Draft Community Group Report), so it can be changed. I think examples like this will be useful to further clarify in the specification how document/resolution metadata are supposed to be used.

ntn-x2 commented 1 year ago

I find this especially interesting. What would happen if two different resolvers (potentially even two different implementations) resolve the DID at exactly the same time? Would the proof be the same, or different?

If both resolvers have the same view over the underlying storage (e.g., they both see the same block hash as the last "final" block), then the proof will most likely be the same.

Note that the DID Resolution specification is still at an early stage (Draft Community Group Report), so it can be changed. I think examples like this will be useful to further clarify in the specification how document/resolution metadata are supposed to be used.

Yes, I agree, and I was a bit surprised myself to see that while DID spec has been v1 for a while, the resolution spec is only v0.3 😄 But I'm happy to contribute to the specification moving forward, providing feedback from the blockchain angle (specifically as a Polkadot parachain), which AFAICT is not very common for identity projects.