Example 19 (delegation) uses the same did's everywhere
Opened this issue · 4 comments
In my attempt to come to grips with the details of capabilities and their delegation, I noticed that example 19 uses did:example:123456789abcdefghi as the DIDdoc subject, in the controller property, and as the DID-part of all DID-URLs.
I have trouble understanding how this could define a delegation to another DID subject. Can this be clarified?
You are correct. The capabilityDelegation in that example does not delegate to another DID subject.
Rather, it defines a verification method for the delegation of capabilities issued to the subject.
In other words, if you have a zCap issued to did:example:123456789abcdefghi, that has been delegated to did:example:abc by did:example:123456789abcdefghi, then you can verify that delegation using "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
The other subject's DID, did:example:abc, isn't in this DID document. (There is no need for such delegations to be publicly revealed in such a way). Rather, that DID is in the delegated zCap and then used to generate the proof in the eventual zCap invocation.
Thanks @jandrieu for explaining.
As you may see from previous issues I raised over the last weeks, I'm having trouble understanding this specification. Some concepts are explained in detail, whereas (e.g. capabilities, controllers etc.) are not obvious to readers such as me. It seems to me that the standard has functionally 'progressed' (slipped) from what used to be a way to set up secure communications has evolved into something that also deals with all sorts of authorization-related matters, which I personally would rather see at the information/business level. I guess that's a fundamental discussion for SSI architects...
I hear your frustration. I think much of it is because of the layered approach that advocates of DIDs and VCs have adopted (and I eventually came to appreciate and, in turn, advocate). By deferring some aspects to other specifications, VCs and DIDs were able to get through a consensus process at the data model level. The unfortunate result is that there's no fully published version of the grand vision, in large part because many of the pieces are still being defined. While several implementers have built and shipped DID and VC technology, the remaining layers still have much discussion and debate before we can canonicalize their boundaries and functionality. To wit: early versions of DIDs only imagined ledger-based identifiers. Now we have methods that embed the verifiable data registry in the DID itself. We're still figuring out the best way to do these decentralized things.
THAT said, I'd make the case that this is more a miscommunication / undercommunication about how verification relationships and verification methods work. IMO, at its core, DID Documents most fundamentally represent the relationships between particular identifiers and specific cryptographic methods that can be used to verify certain actions. That is, its most fundamental role is to present the relationships between a given DID and associated verification methods.
These "verification relationships" are represented as top line properties in the DID Document, as "authentication", "assertionMethod", "keyAgreement", "capabilityInvocation", and "capabilityDelegation" and each provides a way to specify verification methods to satisfy those relationships.
As I understand it, these particular verification relationships have been defined in the JSON-LD signature work, but I can't speak authoritatively on that. However, I do understand that these relationships are intentionally limited in quantity. Unlike delegation--which may require extremely sophisticated rules for what is exactly delegated to whom under what circumstances and with what exceptions--verification relationships are limited precisely to reduce semantic ambiguity.
They are, in effect, the way that you achieve better practices for key management, e.g., the NIST guidance on using different keys for different cryptographic functions:
- For this DID, use
- This key for authentication
- This key for assertions
- This key for encryption/decryption
- This key for invocations
- This key for delegations
And, because of the way that DID Documents work, it is possible to list multiple proof mechanisms for each relationship AND controllers are not just limited to public key based proof mechanisms. Any verification method can be specified in a DID Document from a specification standpoint (implementations vary).
With those five relationships, you should be able to address just about any cryptographically verifiable operation.
So, I wouldn't say the standard has functionally 'progressed' (slipped) from what used to be a way to set up secure communications but rather that the standard provides a flexible way to set up secure communications that affords functionality you hadn't yet realized were available.
In particular, I appreciate how delegation is deferred to a different layer, allowing competing options to innovate in that space. Authorization capabilities are one approach that works with capabilityInvocation and capabilityDelegation , but any system that understands a specific proof mechanism could use DIDs in the same way (including by defining a new proof mechanism).
FWIW, I find this layered approach far more scalable and reliable than end-to-end monolithic designs where every layer has to be right for the entire system to hold together. By standardizing at the different layers, we get an ability to build technology stacks that are interoperable at each layer, similar to that enabled by the OSI model and its seven layers.
p.s. I also think the "controller" property is ridiculously named given it does not identify the controller of the DID Document, but that ship has long since sailed.
Thanks, @jandrieu, for hearing my frustration, and for clarifying and pondering.
I like the idea behind verification relationships. Having different keys for different purposes has been around for a long time (authentication, integrity signatures, will-expressions), and DID-core added a few others. It is from this history that I think we haven't seen the last of them, and therefor - and also to be able to define the single concept 'Verification Relationship', I would rather see its intended purpose be a property of a generic (root)property 'Verification Relationship' than having 5 (I expect more to come in future) explicitly defined.
Regarding the ridiculously named property of 'controller' (in the context of a verification relationship), I don't mind (so much) keeping it, but I do think it can be documented much better so that people that didn't witness 'the sailing of that ship' to at least understand it (see #806).