Can we minimize the footprint of the DID document by removing all delegation

In issue #190 @jandrieu provided an excellent answer to my question about TERMX - now, as of PR #192 known as "Delegate" / "Delegation"

3 - how to determine when TERMX is better done with a self-asserted VC and the inherent semantic richness, vs. when is TERMX appropriately done "in the DID-Doc"

Joe's answer - with comments inline

This is a huge question that deserves a longer conversation, but here is a brief synopsis. I recommend doing as minimal as possible in the DID Document to keep interoperability as simple as possible. Now, I really agree with this - and that is why I think we should seriously consider removing the entirety of the delegation model (that which was named in #4, and discussed in #193, etc.) from the DID-document - specifically because it bloats the DID document with a specific model of security, capabilities, inter-personal relationships, and ultimately 'intended uses of DIDs' - putting this information in the DID w/o a strong, decentralized extensibility semantic model, does not work well for the full class of DIDs - e.g. all of the use-cases in #190 appear to have people as subjects, and because this is at the DID-level, we need to always consider all possible dimensions of DIDs when working with DID-level requirements.

@jandrieu continues to contrast capabilities w/ VCs. I include it here because it is well written and informative.

Further I'd argue for directed capabilities instead of VCs. VCs are assertions, which require the recipient to understand the meaning of the assertions as well as any intended logic wrt chained delegations. There is no guarantee that a VC delegating banking privileges to a CPA would be understood or accepted by the bank. Directed capabilities, such as zCaps, have explicit delegation semantics and explicitly support service-specific scoping and open-ended chained delegations. For example, in UC.A6. Delegation, Anastasia's CPA can delegate the capability further to allow a particular associate at the firm to invoke the capability, all without needing to bother either Anastasia or the Bank. And since the bank created the initial capability in the first place, they have seamless control over the scope of privileges that can be delegated, such as read only, deposit only, daily transaction limits, etc.

The short rule of thumb for capabilities versus credentials is that credentials are useful when presenting an assertion made by the issuer to another party. Capabilities are useful when triggering actions at the service provider who issued the capability. In the credential-based, self-asserted delegation as you described, the bank will ultimately be the "decider in chief" about whether or not your self-asserted delegation is something they support. And because VCs are open-ended semantically, banks are going to have a hard time accepting such free-form delegation until explicit, shared semantics are established. It's basically no better than a signed affidavit giving someone authority to withdraw funds. The bank may accept it. They may not. They may, but only if a notarized. And they may or may not accept subsequent delegations by your delegate. The bank also has a burden of identity-proofing the DID used to issue your delegated VC, which they may or may not be capable of.

Capabilities, in contrast, allow the Bank to specify exactly which scopes are delegatable, giving them control of the possible actions that are delegation-enabled in their software and the initial capability is always issued to a DID that has already been bound to your identity-proofed account. In short, they get to set the rules and the root authority of the capability, and you get to decide what you delegate to whom without operational involvement by the bank.

In general I accept this - and in my previous comments I've used VCs where I probably should have used capabilities - mostly because I don't yet fully appreciate the difference, and because I have already been using VCs relative to a shared, constrained semantic (the credential definition) such that most of Joe's concerns don't apply. They are serving as "certificates" that are recognized by the relying-party as authorizing a certain class of activities on the relying party in contexts of "user-substitution" - they don't allow "masquerading" but they do allow activity and generate appropriate compliance and audit logs.

It works well enough, and reduces the total number of concepts/standards I have to deal with for the product-line in question.

Thus, in answer to @jandrieu 's question

The most important question, to my mind: can any of these use cases be deferred to a later layer and still effectively be realized, if desired at all. For example, if we accept an external delegation mechanism we can probably reduce the complexity of the DID Document without loss of capability. Ideally, that mechanism should be open ended rather then a specific mechanism prescribed. Of course, some of these use cases may just be better off unsupported.

I want to suggest that they all should be deferred to an external delegation mechanism. Given that we have "capabilities" and other solutions - like VCs - and perhaps others, I propose that we wholesale ditch all authentication and verification relationships from the DID-document, retaining only the registration of DID and public-keys, without any further annotation, at all.

The guidance that a DID-controller provides about "how to use" a given public key should join the other "nice-to-have" controller-asserted properties. This minimizes the DID-document, and shifts the bulk of the conversation back to the "Ersatz-credential" - the controller-asserted claims about the subject, which are equivalent to editing the DID-document, but which simplify the DID-document specification to the bare-minimum.

I am confident that this will be rejected - but I am curious about understanding the rationale behind why some-controller-asserted-information is bound to the method-resident data store and bound into method-specific update behaviour while other information is considered qualitatively different.

Perhaps we can start w/ a "clear model" and "add back" the controller-assertions one by one, identifying clearly why it is essential to be in the DID-document and not in some other form that more correctly models "A asserts B about C" - such as "Controller asserts 'Public-Key#abc should only be used at the PGP key party next Wednesday' about Subject"

Please respond with appropriate emojis to simulate bombarding me with rotten fruit given the noxious and confrontational nature of this proposal - but also please help me understand where the boundary is between DID-resident and external controller-assertions about security and policy. Let's use UC.A0-UC.A8 from issue #190 as refrence.

I want to suggest that they all should be deferred to an external delegation mechanism. Given that we have "capabilities" and other solutions - like VCs - and perhaps others, I propose that we wholesale ditch all authentication and verification relationships from the DID-document, retaining only the registration of DID and public-keys, without any further annotation, at all.

The guidance that a DID-controller provides about "how to use" a given public key should join the other "nice-to-have" controller-asserted properties. This minimizes the DID-document, and shifts the bulk of the conversation back to the "Ersatz-credential" - the controller-asserted claims about the subject, which are equivalent to editing the DID-document, but which simplify the DID-document specification to the bare-minimum.

I am confident that this will be rejected - but I am curious about understanding the rationale behind why some-controller-asserted-information is bound to the method-resident data store and bound into method-specific update behaviour while other information is considered qualitatively different.

Yes, I, for one, would reject this. I think that this minimizes the DID Document to the point that it no longer functions properly. If you were to only specify the public keys in the DID Document (with no verification relationships), then which one do you use to make those assertions? Any of them? Which ones can't be used for that purpose? Perhaps all keys would have all authority to start with and then a system of reducing the authority of these keys could be introduced (that may very well involve other bad trade offs such as pricey updates to DID Documents that reside on blockchains). But where would these authoritative set of statements go? Now the original problem has returned. There are other examples where this problem continues. This all sounds like a security nightmare to me.

Ultimately, there is a need to distinguish these relationships at the root -- where the keys are expressed. -1 to removing this basic expression of root authority from a DID Document. I do agree that authority should be delegated outside of the DID Document, for example, through the use of capabilities like "zCaps". This works well and keeps DID Documents clean. But the simplest design, IMO, does require expressing which keys can be used for what purpose at the root level -- in the DID Document.

I also want to say that I think the list for "verification relationships" is likely short. You can only stretch it in so many different directions before the lines blur and it is no longer useful. It similar to the rainbow of colors in that way; red is red, blue is blue, green is green, but what is coquelicot? We don't need it and there's no real security benefit for having it for keys listed in a DID Document. We should be able to cover the vast majority of cases in the DID core spec and I believe we've already enumerated most of them. Anything we've missed can be handled by extension. I don't think that's a problem.

If there are very specific requirements for the use of certain keys (like your example "should only be used at the PGP key party next Wednesday"), then that implies the key will be narrowly shared within a particular relationship and it has no reason to live in a DID Document to begin with. Just because you have a DID Document doesn't mean every key you create must live in it. The assertions made about those keys may be rooted in a more commonly used key that is expressed in the DID Document under the "assertionMethod" verification relationship. All of this works cleanly -- and it doesn't interfere with other keys in the DID Document that are not meant for making such assertions but instead are for, e.g, authenticating.

@dlongley wrote:

I also want to say that I think the list for "verification relationships" is likely short.

If there are very specific requirements for the use of certain keys (like your example "should only be used at the PGP key party next Wednesday"), then that implies the key will be narrowly shared within a particular relationship and it has no reason to live in a DID Document to begin with. Just because you have a DID Document doesn't mean every key you create must live in it. The assertions made about those keys may be rooted in a more commonly used key that is expressed in the DID Document under the "assertionMethod" verification relationship. All of this works cleanly -- and it doesn't interfere with other keys in the DID Document that are not meant for making such assertions but instead are for, e.g, authenticating.

Maybe solving this will address to my increasing concerns. How do I use my DID to allow me to extend my bag of keys beyond those in my DID? What is the data model for extending my bag of keys such that different people will get different bags of keys?

This is particularly relevant in the DID BTCR architecture. In a BTCR transaction only only have a strong location (block and transaction index), a very good timestamp, a list of input and output transactions, and 80 bytes. That is all. A DID Resolver can give this "implicit" DID easily to a DID consumer ap so that DID Auth can happen and VCs can be verified — no signature is required as in a sense the blockchain signs it (we used to say "SatoshiSignatureMethod2009" ;-)

However, this isn't enough for many use cases where we want to have more than one key, thus the optional op_return can point to a "extension" DID document that is either signed with the same key as the implicit DDO, or is a content addressable hash to a document that does not need to be signed as it is in effect signed by "SatoshiSignatureMethod2009" when we put the hash in the op_return.

When the extension document merges these two together, the DID Resolver forms a new "explicit" DID document. In the case of content addressable hashes, this is a little tricky for a foundational transaction as may not actually know the DID value (as it doesn't exist yet), but we've figured out how to make that work.

As far as I know, BTCR is the only DID Method that has extension documents, but it could be a very useful pattern design for other DID Methods, or even a new pattern described in the root DID spec itself. In addition, with extension DID documents, I can potentially give different people different sets of additional keys beyond the root DID document, or different information about endpoints, etc. Other than the root DID document, there is no canonical DID Document for a DID — instead, if you received a valid extension to it, you could now use the additional keys and services.

Having a defined architecture to extend a DID Document also addresses some of my concerns about correlation, censorship, and security, as I can minimally disclose only that which is necessary in my root DID Document, and then based on a business processes and protocols only offer those keys, services and capabilities that are essential to that business process — no more!

Right now there is no way to extend a DID Document, no data model for it, and using a VC is clearly not the answer either. So for me there is a hole that should be filled.

-- Christopher Allen

@ChristopherA I absolutely love the "extension document" model - in fact, I've been working on a DID alternative I call "Skids, Skittles, and Truces" - basically it is this: a SCID is a self-certifying identifier expressing minimal, non-extensible, cryptographic control in a simple abstract data model suitable for any encoding. A SCID+LD (or Skittle) is a "companion document" which might best be described as an "Ersatz VC" - it is bound 1:1 with the SCID, and is the point for "controller assertion of whatever they want to say about the subject" - including, delegation, service_endpoints, and whether or not it supports either coquelicot or pluerigloss or squant or hoovooloo. A TRUst Control Expression, or TRUCE, is combination of a SCID and a SCID+LD - basically a 2019 era DID. Mapping this to DIDs you could say "if a method noes not support 'extended controller assertions' then resolution simply returns a 'null' for the skittle" - if it does support the 'companion document' model, then it is attached at that point.

Because DIDs have become complicated, heavyweight, with bulky extensiblity via coordination with some yet-to-be-formed registry administrative body, we have had to postpone supporting DIDs until the spec is released and we observe market adoption. In the interim, we are trying to capture most of the "sensibilities" of DIDs without getting bogged down in trying to figure out whether we are "using them in compliance with the spec" - we are moving product first, dealing with interop on a per-case basis, and worrying about spec compliance second. The key obstacle is the lack of clear guidance of which parts of the rainbow are "good colors" and which are "bad colors."

The very core of what we need is simple:

self-certifying identifiers against which we can register public keys - we are confident that this part will always be easily captured as a minimal DID-document - and
an extensible 'companion document' which lets the controller express what is required for the use-case and environment, and this part may or may not be allowed by the DID-spec

We ran into no trouble using "self-issued VCs" to model "Capabilities" within our domain - and it is a pattern we've been able to repeat and adapt. Perhaps, down the road, if they are needed, we will move to zCaps or ABCs or some other form, but so far what we have is enough. Engineering-first theoretical considerations about adoption and inter-op have become obstacles to daily product-level adoption and intra-op. Rather than being an enabler, DIDs have become an obstacle, rather than an enabler. URLs (and possibly did:web) pointing to DID-like documents give us what we need, and avoid us having to wait while remote teams determine "how DIDs ought to be used" so they can write it down in the DID-spec + registry instead of letting us use the flexibility of @context.

The solution that works for us is a clear, minimal, cryptographic control expression that simply associates a key set with an identifier registered on one of our blockchains, and a companion document that describes how those keys are related to the subject. The same engine also provides generic VC storage, consent receipt storage, and provides a cloud wallet. While it is not "perfect" it is a substantial improvement over current practices. We are looking to the companion document to assist with exploring KERI - something we do not feel we can do with DIDs in the near future. We can implement the DIDs of tomorrow, today, if we just sidestep the spec + registry and leverage the absolute minimum of DIDs - essential subject, controller, and publicKey.

This gets to @dlongley 's response -

Ultimately, there is a need to distinguish these relationships at the root -- where the keys are expressed.

I do not yet see the case for this. I understand the claim, but I do not think you provided a compelling case. In the 2019 model of DIDs the DID-document itself was flexible, and there was no need for a "companion document". However, pressures such as the need to encode entire DID-documents in PDFs, support the LD-allergy, and dictate the proper use of DIDs we definitely need a companion document.

I love the term "Ersatz-VC", which is 1:1 related to the DID-Document, but accommodates the shortcomings and limitations we are introducing by trying to nail down an a-priori model of all possible and allowed use cases for DIDs across all configurations of people, organizations, and things for now and the future. A classic mistake of over-reach and designing to distant future state.

That being said, I think these are good questions - they are the right questions:

Yes, I, for one, would reject this. I think that this minimizes the DID Document to the point that it no longer functions properly. If you were to only specify the public keys in the DID Document (with no verification relationships), then which one do you use to make those assertions? Any of them? Which ones can't be used for that purpose? Perhaps all keys would have all authority to start with and then a system of reducing the authority of these keys could be introduced (that may very well involve other bad trade offs such as pricey updates to DID Documents that reside on blockchains). But where would these authoritative set of statements go? Now the original problem has returned. There are other examples where this problem continues. This all sounds like a security nightmare to me.

Answers:

the companion document contains controller-assertions about how to use the keys, so no, you don't use any of them willy-nilly, you use the ones that are indicated - the same material that is currently in the DID document simply moves to the companion document - this is our solution at the moment, in order to give the spec time to mature.
key authority is not expressed in the DID document, so there is no need to come up with a scheme like "starting with all authority and then winnowing" - key authority is one of the assertions made by the controller about the subject, so it belongs in the document containing controller assertions about the subject.
cost of DID-document update is method specific, for which there is the inverse problem of forcing all DID methods to adhere to the a-priori data model. For example, the DID spec may preclude use of BTCR or most blockchains implicitly. This effort to 'shrink' the DID-method space represents confusion about whether the number of DID methods is a "problem to fix" or a "feature to leverage" - and we have the rubric environment if we want to make cross-method comparisons given some case.
the "authoritative statements" go in the "Ersatz-Credential" or "Companion Document" or Skittle which is 1:1 with the minimal key registry (SCID). A method only MUST support the SCID, but MAY support the SCID+LD

One of the things that makes me chuckle is that we've been driven to this model in order to facilitate a tentative future support for DIDs. Once there is wide adoption of the DID spec and we can see it living, we can migrate the appropriate parts of the companion document into the DID-document, but we are not blocked by the confusion and concerns about where DIDs are going when trying to develop and deploy solutions.

The open-world model of 2019 was perfect for us, the new dictatorial, a-priori, registry-driven modeling approach is a bit of a problem - we simply do not know where this is going to wind up now that the key feature of @context driven adaptation is on the ropes. Pragmatically, it is best to "hold off on DIDs" until the community comes to consensus about "what a controller is allowed to say about a subject" - and this gets to the heart of the matter, and where I still want to hear a good case for why i should bother with a DID-document at all beyond the three key fields, subject, controller, and publicKeys.

This is guidance that is still missing - the arguments provided are too subjective. The determination that red is viable, but coquelicot is unwarranted is not guidance that I can readily turn into a power-point slide or simple rubric about whether what I need is "appropriate". While I wait for the W3C to define the rainbow and tell me what colors are acceptable, I have little choice but to model my world in a companion document and rely only three fields "subject, controller, and publicKey" - this, we hope, will let us "remain compliant", and keep us on track for "full support upon spec-release", while giving us the freedom to continue product development and delivery.

What I've not heard yet, is strong, objective support for why i need all this modeling in the DID-document. Given that I need a companion document that is bound 1:1 with the DID-document, why shouldn't I run with that and move all of the controller-assertions beyond unlabeled public-key association into the companion document. This strategy maximizes compliance with the now-and-future spec, yet gives me the semantic freedom to define my own rainbow and adapt to my use-cases.

In a nutshell, I am sympathetic to the desire to make the DID-document the "root authority" - and I thought the late 2019 DID-spec was on track to do that. But as of early 2020 I am now concerned that I can not make an objective and clear assessment of whether data belongs-in or is-likely-to-wind-up-in the "Root Document" - thus the need to establish a new Root Document and bind that to DIDs, while the "powers that be" determine "how and what controllers are allowed to express about subjects" in the Root Document.

I welcome any and all guidance about how to make a clear, objective determination. I will print it out in hoovooloo ink on squant paper, and read it in a field of coquelicot poppies. ;)

@SmithSamuelM: I think you should be tracking this conversation, since it touches on principles of KERI that you've been advocating.

The minimalist approach could use a proposed DID resolver parameter that returns a proof of control authority (not the DID Doc). Then the DID Doc would only need to provide a single service endpoint to retrieve all other authorizations. this would be verifiable due to the proof.

Less minimalist would for the DID Doc to include a reference to the proof and then the service endpoint.

@SmithSamuelM that's an interesting take - i read that as (proof + single service endpoint), but I'm not clear about the role of the resolver there via a parameter. A lot of the useful resolution services - particularly for web-based DIDs, is in the magic they can do around interpreting that companion document.

This is very much just hair splitting - but the way it falls together in my head is that the core, minimal, resolution that must be supported is that pair and that all other resolution features would be secondary, based around some standardized processing of the companion document - and standardized might be a strong word - canonical might be better.

A key advantage of this approach is that it minimizes the demand upon the supporting infrastructure, making it easier to adapt to different methods. The disadvantage is that there is always a 2-step process to do much of anything useful - although that could be hidden by the resolution layer.

Also - please correct me if I'm wrong, but if I had the proof-of-control and the companion document, and I wanted to employ KERI, I'd use the companion document for the witness endpoints?

@ewelton what concrete spec text would you like to see in the spec to address your concern? As an editor, I have no idea what to do with this thread.

I am happy to close it out.

I was hoping to see some simple organizing principles to the DID-Document - like anything not about establishing control of the document could be pushed into a structured set of assertions by the controller about the subject - something in a openly extensible, non-registry based, decentralized semantic suite. That would have minimized the DID-document and let DID-controllers use DIDs how they wanted and not as dictated to them by others - a sort of "self-sovereign DID" model - letting an ecosystem of things like service_endpoints, and delegation/TERMX/proofPurpose/vericationMethods or whatnot grow up under use-case driven pragmatism.

Changes would have been very substantive - cutting out the bulk of the DID document as a set of appendices indexed by "DID-Doc key / context URI" - for example, one for service_endpoints, one for proof purposes, one for modeling immutable digital assets w/ control surrender, one for linking to common international and national documents, one for modeling control of a domain, one for modeling GS1 product data, method specific do-daddles, standard and enhanced key rotation event witness management, whatever - all sorts of incredibly useful information that didn't force us through through the prism of service_endpoints and gave us space to capture all the 'self-asserted' stuff a controller might find it useful to say about a subject.

It would have been a very substantive change to the DID spec, but DIDs went a different direction - so I'm happy to close this issue and just look forward to evaluating the DID-spec once the structure is clearly mapped out and all the elements are re-spec'd.

@ewelton wrote:

cutting out the bulk of the DID document

I'm still worried that the DID specification has become a kitchen sink, defining so much that it makes it difficult to create or make different decisions for qualify as conforming DID method, or having so many "MAY" and "SHOULD" that people who only want "MUST" will be confused.

-- Christopher Allen

Acknowledged @ewelton and @ChristopherA -- if you can provide concrete spec text or section changes in the future, it'll be easier for the editors to act on your suggestions. The conversation is good, don't get me wrong, and sometimes it knocks things loose. That said, we're getting to the point where we need to really understand what changes are going to be made to the spec and I'm not expecting major rewrites at this time. The structure is more or less there now and it'll be filling in/refining from now on. We'll try to limit further complexity as @ChristopherA is requesting... but we need to get consensus around those limitations.

Closing in 7 days if there are no objections.

No objections raised to closing since marked pending close

w3c / did-core

Can we minimize the footprint of the DID document by removing all delegation #194