Figure out three fundamental roles of DIDs (controller, subject, XXX) about did-core HOT 41 CLOSED

Conflation of terms typically means that multiple meanings are being assigned to a term (at different times and/or by different people). To resolve that, I suggest to start with identifying these different meanings by specifying criteria that allow us to distinguish between what is and what is not meant. The text by @jandrieu suggests that the following distinctions to be relevant:

1. entity referred to by the DID, other than the DID document itself.
2. entity that has the ability to change a DID Document.
3. entity capable of exercising one or more authentication capabilities (as specified in the authentication property of the DID Document)
4. entity that decides/controls who gets to authenticate on behalf of a DID
5. entity that exercises the use of (uses) authentication

Then we have to get a consensus that these are really the distinctions we need. They may need to be fine-tuned. Others may need to be added. They all need to be relevant for what we try to achieve together.

After we have gotten consensus that these are really the distinctions we need, the next step is to agree on the term to tack onto each of them. 'Subject' might be a candidate for (1). It is easier to live with a term that is not to one's particular taste if you focus on the meanings/criteria rather than on the chosen term. After all, the term will only have the assigned meaning in a context where people talk about DIDs; other contexts may well have different meanings assigned.

Then, a first version of a terminology has been defined, that should be completed by writing one or more stories (that may include use-cases) that explain how they fit together, and address any concerns that readers may have. Thus, such stories specify and explain the further constraints that apply, e.g. that instances of term#2 can rotate keys, change service endpoints, manage authentication, and deactivate the associated DID, that there should/must be at most one instance of term#1 for every DID. The set of these constraints, together with the definitions/terminology, would then be a mental model for working with DIDs.

from did-core.

Moving an issue from the CCG to here (w3c-ccg/did-spec#115)

from did-core.

@rhiaro moved issue from CCG to here (w3c-ccg/did-spec#263)

from did-core.

In regards to the three roles, subject, controller and delegate. Is there a potential to have just two? Isn't a controller just a delegate that has been delegated control over managing the DID document? If this is the case we could then use a definition like the following for a DID delegate:

A DID delegate is a DID that is referred to by another DID through an expression in their DID document, this expression also defines the scope/constraints of the delegation. 

For example, if a DID appears in the controller section of a DID document, this expression denotes the referenced DID has been delegated the ability to control (e.g update) the contents of the DID document.

We could also set some default language along the following lines?

In the absence of an explicitly defined controller in a DID document, concerned parties MUST assume the DID subject is the default delegate for controlling the DID documents contents.

Just to be thorough, are there any instances/use cases known at the moment whereby a DID other than that is the subject of the DID document might feature in the DID document in a context where something other than some form of authority/delegation is being expressed? Personally I don't know of any, I just want to make sure we are clear about the implications this terminology brings.

from did-core.

@tplooker There's a distinction here that you are missing, which is why we want to tease out the language.

In this case, "delegate" is an entity who is authorized (by means of one or more proofs in the authentication section) to authenticate on behalf of the controller. This delegation does NOT include the authority to edit the DID Document. It is, by design, not necessarily a DID controller.

Building on @RieksJ five distinctions, these terms might be temporarily useful:

• Subject -- entity referred to by the DID, other than the DID document itself.
• Controller -- entity that has the ability to change a DID Document.
• Delegate -- entity capable of exercising one or more authentication capabilities (as specified in the authentication property of the DID Document)
• Claimant -- entity that exercises the use of (uses) authentication

I left out the 4th listing from @RieksJ :

• entity that decides/controls who gets to authenticate on behalf of a DID

Because I don't think there is a meaningful separation between the entity that controls the DID document and the entity that controls who gets to authenticate on behalf of a DID, because the way you control who gets to authenticate is by changing the document. These are technically identical sets.

I can see a more sophisticated model of use that includes business rules beyond those technically enforced. For example, a company whose CEO actually has the legal authority to approve changes to the document, but who has another individual actually exercise that authority on his behalf. However, these kinds of complexities are effectively unbounded and run parallel with the issues about "owner" and the business and legal rules thereabout.

Just like "validation" and "verification", I think it's in our best interest to keep the spec to the distinctions that can be technically realized, while allowing users of the technology to apply any business rules desired after the technical / mathematical / procedural processes complete their operation.

Fortunately, we can distinguish a delegate from the controller by separating keys and proofs. And since we can't through technology know for sure if a claimant is actually a delegate or actually the subject, that's a distinction we should anchor in our language. We also need to acknowledge the technical possibility that the claimant of authentication may not, in fact, be authorized for authentication, aka not a delegate, even if they satisfy the requirements of authentication (they have control of the keys or device used for authentication).

Note this is related to #2, #3, and #22

from did-core.

Just a quick side note that the terms.html file contains several definitions that seem relevant to this issue but are not actually referenced anywhere in the spec, and therefore don't even show up at all in the rendered version. This includes the terms "delegate", "dependent", and "identity owner". Those should be updated and properly referenced from the spec, or removed if not needed.

from did-core.

Thanks for the explanation, to clarify a couple of points.

In this case, "delegate" is an entity who is authorized (by means of one or more proofs in the authentication section) to authenticate on behalf of the controller.

Is this on behalf of the controller or as the subject?

Delegate -- entity capable of exercising one or more authentication capabilities (as specified in the authentication property of the DID Document)

Is it more general than this e.g entity capable of exercising one or more verification methods defined in the did document, for which authentication is one? See #2 as a related topic.

I'm still digesting whether a DID controller is not just a unique form of DID delegate and whether we benefit from creating a separate top level term.

from did-core.

In this case, "delegate" is an entity who is authorized (by means of one or more proofs in the authentication section) to authenticate on behalf of the controller.

Is this on behalf of the controller or as the subject?

The authentication section in a DID Document specifies verification methods that have been authorized by the DID controller for the purpose of authenticating an entity as the DID subject.

Another way of saying this is that an entity may authenticate as a DID subject by creating a proof, for the purpose of authentication, that can be verified by a verification method listed in the authentication section of that DID subject's DID Document.

Note that a DID controller may be identified by the same DID as a DID subject -- and this is the most common case. However, it may also be the case that a DID Document specifies different controllers than the subject. Authenticating as one of those other entities involves using their own DID Documents.

A "controller" should be considered a root of authority for what appears in the DID Document -- so I think this is a unique role.

from did-core.

@dlongley There's a bunch of statements in your response that aren't quite rigorous.

To @tplooker's first question

Is this on behalf of the controller or the subject

It is only knowable that authorization is on behalf of the controller. The subject may or may not be involved. Even in the case where we believe the controller is the subject, the verification of that is a matter of identity proofing, which we intentionally avoid by making the distinction between controller and subject. We also enable situations where we KNOW the subject is not the controller, perhaps because the subject is a incapable of managing keys.

To your second question:

Is it more general than this e.g entity capable of exercising one or more verification methods defined in the did document, for which authentication is one? See #2 as a related topic.

I'm still digesting whether a DID controller is not just a unique form of DID delegate and whether we benefit from creating a separate top level term.

In theory, it could be. The biggest difference is that the controller of the DID Document may be determined by the DID method in a way that is not expressed (or perhaps even expressible) in the authentication section. However, I have my doubts about whether or not that's an important feature.

If we wanted to ensure that the controlling proof is representable, we could make that a requirement, but it is explicitly NOT that way now. Per the spec (https://w3c.github.io/did-core/#proving-control-of-a-did-and-did-document ), the only way to prove control of a DID is to exercise the DID method to retrieve the authoritative version of the DID Document.

HOWEVER, reading that section doesn't seem to actually prove control of the DID, but rather prove how to get the authoritative DID Document. Having the controller change that Document would prove control, but simply resolving the DID does not. I think the spec is in error in this section.

Whether or not we find text to improve that, the situation remains: it is in exercising the DID Method that you prove control, not by checking authentication. I believe the larger meta-point here is that a clear separation of control and authentication reduces the change of mis-applied credentials. IMO, it is an anti-pattern to authenticate with the keys that control the document, although I believe that is a common usage.

from did-core.

It is only knowable that authorization is on behalf of the controller. The subject may or may not be involved. Even in the case where we believe the controller is the subject, the verification of that is a matter of identity proofing, which we intentionally avoid by making the distinction between controller and subject. We also enable situations where we KNOW the subject is not the controller, perhaps because the subject is a incapable of managing keys.

Correct but to clarify my question was not around authorization, I understand it is the controller that is doing the authorization. However the second part of your sentence implies that when an entity is exercising an authorized verification method in a DID document, it is doing this on behalf of the controller not the subject? @dlongley, your articulation is what I believed was the case where a delegate exercising an authorized verification method results in authenticating as the subject.

from did-core.

This discussion relates to #122 , where @ewelton proposed

Equating DID-subject = DID-controller and fixing that relationship is a simplification that will reduce the burden and complexity of the spec, and as such, it will foster adoption. Perhaps limiting the problem space of DIDs is a win?

I second that proposal, see #122

from did-core.

The 2020 Spring DID WG F2F felt like it clarified a few things between Subject and Controller. Delegate seems like the appropriate 3rd item. Specifically, I'd argue against what @ewelton and @Oskar-van-Deventer are arguing above primarily because the group keeps getting wrapped around the axle by not having clear terminology to refer to these three classes of entity that may interact with the DID Document.

+1 to DID Delegate

... this feels like the controller != subject discussion we had in the Verifiable Credentials WG all over again.

from did-core.

@msporny I would love some pointers to the VC discussion, it would be good background reading.

Also, I want to make sure I understand your position - at the end of #122 (this comment )) I make the case that S!=C. The proposal that @Oskar-van-Deventer cites was an exploration of "what if" we made the simplification that S=C - it does simplify, but it oversimplifies.

from did-core.

@ewelton wrote:

@msporny I would love some pointers to the VC discussion, it would be good background reading.

The conversation was splattered over multiple CCG and VCWG meetings over the course of years :P ... but it resulted in this (mildly controversial) appendix in the spec:

https://www.w3.org/TR/vc-data-model/#subject-holder-relationships

Also, I want to make sure I understand your position - at the end of #122 (this comment )) I make the case that S!=C. The proposal that @Oskar-van-Deventer cites was an exploration of "what if" we made the simplification that S=C - it does simplify, but it oversimplifies.

Yes, agreed... we have a need to name three different things and saying that we can condense those three things to one things argues away the point of contention. We don't need to say much about DID Delegate, but we should probably mention it in the spec.

from did-core.

I'm less convinced on the controller/delegate front, at least in terms of did-core.

The F2F kinda turned me off of DIDs - i have a proposal I call "Skids, Skittles, and Truces" - where SCID = the front part of a DID doc (Self-Certifying IDentifier), a SCID+LD is the "Ersatz Credential", and a TruCE - a TRUst Control Expression is a (probably KERI-driven) signed document tracing the Control of a SCID & SCID-LD. Truces create a linked chain of Skids and Skittles - an "Ersatz blockchain" if you will. It is 90% in alignment w/ DIDs, just cuts the joints differently.

Anyhow, to me, the SCID part - the cryptographic differentiation between the Subject and Controller is fine - adding Delegation in sounds to me like a "self-assertion" made by the Controller about a Subject, and thus belongs in the Skittle (the Ersatz VC containing all controller-asserted statements about the SCID)

In the context of current DID spec, Delegation needs to be modeled in terms of registry entries, and that opens up a huge conversation around the core crypto control. I certainly wouldn't mind it, but it needs to be global, and factored into all use-cases for DIDs - from passive, non-agency capable devices and entities, through published public DIDs, all the way through to transient pairwise peer DIDs. Modeling that level of "Subject/Control + Delegation" in a core, registry based system, sounds like a long, long process.

I really do not know where to go here - and I will defer to the wisdom of the community - I just wanted to make sure that it was clear that I'm on the "S!=C" side, and that the cited "S=C" was meant to explore "what that simplification would buy us, and at what cost" - ultimately identifying the cost as "too much".

from did-core.

I finally caught up with this whole thread and, ironically, I want to provide a +1 to Joe's initial proposal for these three terms:

1. DID Subject: the entity identified by the DID
2. DID Controller: the entity (may be a group) that controls the DID document and DID URLs rooted on the DID.
3. DID Delegate: an entity who can use the key material/proofs in the DID document to act on behalf of the DID Subject.

The whole point of having these three roles is that they may or many not be played by the same entity. In some cases, one entity (e.g., a person) will play all three roles. In other cases, for example when the DID subject is organization or an IoT thing, they cannot be the same entity, because the DID subject cannot physically act as the DID Controller.

Of the three terms, the only one I'm still a little hesitant about is "DID Delegate" because I worry that it might get confused with delegation in the verifiable credential (VC) sense. DID delegation is a lower level of delegation, because it comes down to giving an entity access to key material or proof material that is represented in a DID document (whereas delegation at the VC level should not require that).

The only alternatives I can offer up as possible names for this third role are:

• DID Holder—the DID analog of a VC holder
• DID Prover—because the essence of the role is to be able to make proofs that can be verified using the DID and DID document.
• Proof Controller—because the role is similar to the role of a DID Controller, only a Proof Controller doesn't control the DID document.

from did-core.

@talltree

(looking at some synonyms)

• DID Agent — acting as a representative of the subject for a specific purpose
• DID Substitute — same as above

from did-core.

@iherman The term "agent" is widely used (and debated) in the SSI community, so best if we avoid that.

DID Substitute is interesting, but the person (and it usually would be a person) isn't necessarily substituting for someone else, but being empowered to use proof material in a particular DID document.

from did-core.

@talltree o.k. Actually, if well explained, delegate is not so bad, so we should probably avoid bike shedding too much:-)

B.t.w., as for the original question of this issue, I do find the description you gave in #4 (comment) compelling and convincing.

B.t.w., if we go for a three way terminology as opposed to two at the moment, then I think I am more in the camp of not having any default. Ie, if needed, all three roles should be explicitly stated in a DID Document even if they are the same DID-s. Setting up a decent explanation for the default setting may become too complicated. Also, I would not think DID Documents are typically created by humans, so we should not optimize for that. For a program (wallet, or whatever) filling the extra slots, even with the same values, is not an issue, and it would simplify our spec.

from did-core.

All,

I am afraid we are losing the purpose/goal of this rather abstract terminology discussion.
What are the things that we wish to express with data models that are using DIDs, in particular with Verifiable Credentials that are using DIDs?
Should we develop a use-cases document that provides examples of the things that we want to express, in order to get a common understanding?

Here are some example statements in plain English, hence focusing on the semantics. Please provide more if you deem this useful.

I declare that

• The electronic signature with this statement can be verified by resolving did:example:111
• To the best of my knowledge and verification, all of the following attributes apply to one and the same Subject
  -In my administation, the Subject is uniquely identified as "Kitty"
  -The Subject is a cat
  -The Subject has black hair
  -The Subject has a chip implanted of the type "gemxyz"
  --The chip can provide the temperature of the Subject
  --The chip can provide the location of the Subject
  --The chip electronically signs its data with an electronic signature that can be verified by resolving did:example:222
• Here is the electronic signature of this statement: "kuyfgcjhcjha"

I declare that

• The electronic signature with this statement can be verified by resolving did:example:333
• To the best of my knowledge and verification, all of the following attributes apply to one and the same Subject
  -The Subject is a living human being
  -The Subject can provide an electronic signature that can be verified by resolving did:example:111
  -The biometrics of the Subject match with a government-issued passport with number "qx445y"
• Here is the electronic signature of this statement: "ki7tg8787ha"

Useful?

Oskar

from did-core.

I definitely +1 to @Oskar-van-Deventer 's request for use-cases. I really think these examples, with delegation, are important - but I also think they relate to the role of methods, and how we assess them with rubrics.

As a point of clarification: Would the Delegation support be a requirement for the implementing methods, or optional, or with caveats - the latter two cases perhaps tracked in a rubric document? What, in general, is the relationship of this sort of processing to the method?

I feel that being able to trace through examples based on use-cases would be very useful for teasing out what part of this is "critical, essential, and core" and what part is, perhaps, more usefully implemented at a higher level, in accordance, perhaps with a VC-mediated Domain Specific Governance Framework. This would help us carve out the distinctions we are drawing as per @RieksJ 's model.

I absolutely encourage and support the development of these facilities - but looking at it as a potential "DID-Implementer" I am struggling with what this means for a DID:<method>. Being able to comb through some use-cases and work out how these requirements for the did-core relate to a specific underlying, and imperfect, chain-based registry of self-certifying identifiers would be tremendously helpful.

At what point do I deploy development-resources to ensure spec-compliance for delegation - clearly not quite yet - and how do I fold in existing VC-based models of trust-governance, or am I looking at a situation where I will wind up with two "equivalent systems" - one written in the language of VCs, and the other written in the DID-core?

The concept here, expressed by @jandrieu in the opening of the discussion:

The design goal, as discussed to a point of consensus at TPAC, is to support limited-use keys for Controlling a DID Document with more frequently used keys for authentication. This approach limits the exposure due to key compromise from authentication, which is anticipated to be a more frequent activity across more parties. It also supports use cases where control of who gets to authenticate on behalf of a DID is restricted (for example to an HR department), while the use of authentication can be exercised by a larger yet controlled set (for example to employees in a particular group).

makes a lot of sense to me. But what I am concerned about is that, in did-core it is a fundamental, firmament, issue with implications that run across all methods or require a more mature rubric/registry integration. I'm confident the working group can get those done - but, I am not confident that the day after the spec is published someone won't come up with a tweak on the requirements that were not caught.

What is the confidence that "only one more, clearly defined role" needs to be specified in the core spec? If we think we can nail this down quickly - then +1, but if we feel there might be some confusion about these roles, I heavily recommend developing a suite of use-cases which highlight the specific feature in play - if we can do that, the group can come to a PR much quicker than if we work only from first-engineering-principles.

from did-core.

I am afraid we are losing the purpose/goal of this rather abstract terminology discussion.

Until @Oskar-van-Deventer and @ewelton chimed in, it felt like we had consensus and I had a very good idea of what I needed to write in a PR. I still think I can do that, but am unsure if it'll make @Oskar-van-Deventer and @ewelton happy.

The main issue here is that there are years of discussions about delegates that we may not have written down and while @jandrieu, @talltree, and I understand what we're talking about... it's clear that @iherman, @Oskar-van-Deventer, and @ewelton do not... and that'll lead to more people being confused about the "delegate" term. We do need to point to concrete use cases, which I do think we have (refugee, IoT, pets, etc.)... @jandrieu is the use cases document in a state where we can do this today?

In the meantime, I'm going to make an attempt at a PR with "DID Delegate" and very specific language proposed by @talltree to see if it lands well with the folks in this thread.

from did-core.

The main issue here is that there are years of discussions about delegates that we may not have written down and while @jandrieu, @talltree, and I understand what we're talking about... it's clear that @iherman, @Oskar-van-Deventer, and @ewelton do not... and that'll lead to more people being confused about the "delegate" term. We do need to point to concrete use cases, which I do think we have (refugee, IoT, pets, etc.)... @jandrieu is the use cases document in a state where we can do this today?

Similarly, the (undocumented) visions by @msporny, @jandrieu and @talltree about "delegate" may or may not be in line with the visions by the Sovrin Guardian Working Group. One of the aspects uncovered by the SGWG, is that there are so many domain-specific, jurisdiction-specific, application-specific and verifier-specific variations to delegation, mandatation and guardianship, and that each variation should better be modeled in its own set of specific VC schemas, and not in a one-terminology-fits-all DID solution.

Anyway, let us discuss and document use cases first, for example in the style that I suggested before.

from did-core.

@msporny I definitely did not mean to derail anything, and I have delegation use cases - but I solved them with VCs and self-assertion using the previous extensability mechanisms. As I re-evaluate whether to continue to use DIDs in my VC environment, I need to understand

• exactly what support for the delegation model means for a method (is it even possible for us to be W3C-DID compliant)
• exactly how is delegation to be enforced at this level, or is merely "controller-asserted guidance"
• exactly how to map an existing VC-based delegation model into the centrally governed DID framework

To do this, it will be very helpful to have very clear examples of how delegation is used "in the sense of the spec". I am looking forward to reading the PR, but having very clear examples of how Delegation is used and enforced so that I can evaluate the role of the method-specific trust environment in those contexts will be stupendously useful.

from did-core.

On Mon, Feb 10, 2020 at 6:54 AM Oskar van Deventer [email protected] wrote:

"delegate" may or may not be in line with the visions by the Sovrin Guardian Working Group. One of the aspects uncovered by the SGWG, is that there are so many domain-specific, jurisdiction-specific, application-specific and verifier-specific variations to delegation, mandatation and guardianship, and that each variation should better be modeled in its own set of specific VC schemas, and not in a one-terminology-fits-all DID solution.

Would it make any sense to use a totally new word? Proxy?

— Christopher Allen

from did-core.

Would it make any sense to use a totally new word? Proxy?

No. This is not a labeling issue, it is a DID-document-versus-verifiable-credentials issue, as highlighted by @ewelton and me.

Oskar

from did-core.

This is not a labeling issue, it is a DID-document-versus-verifiable-credentials issue

The thread continues to talk past each other. It is a labeling issue on a low level concept for the person that raised the issue and some of the rest of us on this thread. It is an "appropriate use of VCs vs. DIDs issue" for @Oskar-van-Deventer and @ewelton. There are two issues that are being discussed in this thread:

1. What do we call the role that the DID Controller can cryptographically delegate certain responsibilities to (such as "authenticate as the DID subject"). This was the initial topic of this thread.
2. Where is the line wrt. delegation use cases and when we should use a DID to do so and when we should use VCs to do so. This is the topic that @ewelton and @Oskar-van-Deventer are discussing.

I suggest we split the latter topic into a new issue to keep this current thread converging toward a resolution.

PS: @Oskar-van-Deventer and @ewelton -- there are answers to your questions, but I hesitate to discuss those further in this issue. Please open a new issue, in your own words, and we can continue the discussion there.

from did-core.

I second @msporny's request to @Oskar-van-Deventer and @ewelton. The matter of general delegation is a separate issue.

The point of this issue is that we currently have two distinct notions already well-mapped to the conversation: the DID Controller and DID Subject; there is a third notion that is not yet named.

We also already have a mechanism to enable someone other than the Controller and Subject to "authenticate" in some manner, for some purposes. The mechanisms of authentication and the purposes--and how the document might represent both are, inevitably, tied up with Eric's and Oskar's points, and quickly verges into authorization and delegation, which is its own complicated conversation.

But this issue isn't about that. It isn't about whether or not delegation, nor how, but rather, how we name the parties.

This issue is about what we call the entity who is, in fact, the intended recipient of the ability to authenticate per the authentication section. This recipient may or may not be the Subject. It may or may not be the Controller. That's the point of having a separate authentication section. There are plausible use cases for both (which are probably not well documented in the use case document). The current proposal is that Delegate is a suitable descriptor of the real-world recipient of the privilege of using the authentication for a given DID.

The point of the distinction is that we need to be able to have conversations about how a claimed Delegate presents themselves for authentication. Should authentication succeed, the party who received the claim has a high-factor confidence that the entity that just authenticated is a legitimate Delegate. This is fundamentally different than proving they are the Controller (which, by definition, uses the DID Method's proof of control) or the Subject (which is a matter of identity proofing, greater than any single point of authentication). One of the main use cases driving this structure is to enable cold-storage of keys used for control with hot storage for keys used to authenticate, enabling a much more secure identity architecture than one that uses the omnipotent key (or proof mechanism) for all transactions.

So, let's create a new issue that captures Oskar's and Eric's issues.

Also, if we can agree that Delegate is the right term for this third role, it will make that conversation, and other future conversations, easier.

Of course, if someone can provide a better term, that would be great too. Absent such a term, conversations exactly like this one spiral out to talking pasting each other.

-j

from did-core.

As the one who suggested earlier that we might look at alternatives to "DID Delegate", I want to +1 proceeding with that term for the third role. Ironically the reason is that the ensuing thread helped convince me that we could distinguish a "DID delegate" from a "VC delegate" via the initial qualifier. In other words, DID delegation takes place at the cryptographic level between the DID Controller and the DID Delegate. VC delegation takes places at the VC level between entities that I expect (in 99% of the cases) both have DIDs, so that's why it's at a different level.

I'm also +1 to the suggestion that the discussion of how delegation works between DID controllers at the VC level should be in a different issue (that's a big, deep, rich area as I know via the work of the Sovrin Guardianship Task Force, which has now graduated into the Sovrin Guardianship Working Group).

from did-core.

I definitely think there are multiple concepts being discussed/conflated here.

There's one concept, for example, that involves using object capabilities to sign using a key authorized for some purpose by a DID controller (this is one concept of "delegation"), whereby the entity invoking that capability may or may not be the DID subject. Someone/some agent playing this role does not need to reveal this information directly in a DID Document in any way. Applying the term "DID Delegate" here could potentially make sense.

Another concept I've heard hinted at is to expose some kind of authentication information (regarding parties other than the DID subject) in the DID Document. I'm not sure what the details there are, but I'm hearing that "DID Delegate" could apply here as well.

A third, totally different concept, would involve something surfacing delegate relationships via VCs.

However, I don't think the role "DID Delegate" would or should apply to the third concept at all. There may be even a fourth (or more!) concept being discussed here.

from did-core.

Naming is hard (and very important!).

from did-core.

I do apologize for derailing the conversation, but I do think it is telling that it is reasonably difficult to understand what is being discussed and where the boundaries are because this is an abstract, theoretical conversation between people with strong, pre-existing mental models.

The reliance on "having been theorizing about DIDs" for years in order to convey how to use the technology is a far larger issue to deal with than the ability to encode PII exposing service_endpoints in a PDF document.

@jandrieu - I will open up a separate thread for this - in the meantime, which use case demonstrates

The current proposal is that Delegate is a suitable descriptor of the real-world recipient of the privilege of using the authentication for a given DID.
in the context of this discussion? That will go a long way to helping me avoid derailing this discussion.

Where the authentication is not involving some external system, but only the DID-method itself. I would like to see an example of delegated use of the authentication system w/in a method, and specifically not involving service_endpoints. This gets to @talltree's distinction between DID vs. VC domain for this.

At present we are struggling to pick a term for a conversation that is extremely inaccessible to the outside world. This is because the spec, in this area, does not strongly convey how this technology relates to the real world - and this confusion is the major barrier to adoptor. We will need to get both the name right, as @selfissued mentions - but we also need to make it very clear to people like myself how to tease apart the line between when something belongs "In the DID" - as in a non-controller subject using authentication for some non-controller purpose, w/in the method-only, versus this role being "guidance" for use in contexts that are more properly described by VCs - even Ersatz VCs ;)

from did-core.

@ewelton wrote:

in the meantime, which use case demonstrates

The current proposal is that Delegate is a suitable descriptor of the real-world recipient of the privilege of using the authentication for a given DID.

in the context of this discussion? That will go a long way to helping me avoid derailing this discussion. Where the authentication is not involving some external system, but only the DID-method itself. I would like to see an example of delegated use of the authentication system w/in a method, and specifically not involving service_endpoints. This gets to @talltree's distinction between DID vs. VC domain for this.

Ok. I don't know how to answer the question.

I gave the example of using separate keys for DID-Auth verses controlling the DID, so ultimate control can be in offline cold storage, while did-auth keys are used for day-to-day authentication, such as proving control for website access.

I don't know what you mean "where the authentication is not involving some external system, but only the DID-method itself." That sounds like you are seeking a DID Method that affords some sort of capability to entries in the authentication section in addition to whatever operations they already support for DID Controllers. I don't know of any method that does this. The authentication section--to my knowledge--is for a DID-based authentication into external systems, not by a DID Method. Of course, you could create such a thing. It's not disallowed.

Does that come close to responding to your question?

from did-core.

Not really - because what we've noticed is that there are people talking about different things - some of which are integral to the DID and could live nowhere else. The other are simply "guidance" given to other systems. @talltree writes

In other words, DID delegation takes place at the cryptographic level between the DID Controller and the DID Delegate. VC delegation takes places at the VC level between entities that I expect (in 99% of the cases) both have DIDs, so that's why it's at a different level.

So what I would like to see is two clear use cases - one that captures this distinction. One thing that came to mind was the ability to for a delegate to update public keys in the did document related to specific proof purposes - so a sort of "partial document control". I don't know if it makes sense or not - but that is what I get from

  "authentication": [{
    
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],

where that "entry controller" maybe is misnamed - delegate, proxy, etc. But the ability in question is not about using the key, it is about the ability to update the key in the DID-document and only that key- and it is that key, which just so happens to be used by some particular set of service endpoints. But the "partial document update" model here is something that happens "in the method" and for which the method is responsible.

and keep in mind - I entered this discussion from the "S?=C" discussion in #122 - i think some of the follow on has been confusion about the specific target use case. If it is limited to partial-document update, that's a great thing - but given the amount of discussion surrounding the term - I think this is an important indicator suggesting the include of a use case (or two!) as exemplary illustrations of the need for this specific support.

from did-core.

I don't know of any method that supports partial document update in the way you mention. The controller has complete control over the entirety of the document and no method I know of allows anyone other than a controller to change a document, including a partial update.

I do believe the "controller" in the proof section is an identifier for the "delegate" of that authentication mechanism. But it is NOT meant to be the controller of that part of the document. Rather, it identifies the entity who is authorized to use that authentication means to authenticate on behalf of the subject.

We could restrict the authentication section to always have a controller == DID Controller, such that the cold/hot storage use case is satisfied.

That, however, would NOT address use cases where entities other than the Subject or the Controller can authenticate on behalf of the subject, which may be a guardian, a fiduciary, or simply a team member (who can't control who is on the team identified as the Subject, but who should be able to authenticate on behalf of the team).

Nor does it address the whole in current usage where we expect to be able to sign and verify on behalf of the subject--and the keys used for those purposes need to be distinguished from keys used for authentication. When we get into this quagmire, the larger issue of authentication as a specific type of delegation looms large. Because it may be that neither the controlling key nor authenticating keys are appropriate for signing. We certainly don't clarify that any key used for authentication can also be used for every other cryptographic operation we might imagine.

I strongly agree that general delegation is too unbounded, but we probably do need some simple primitives from which we can build a more general approach on. Distinctions that should be a part of that conversation should include authentication, assertion, and delegation as proofPurposes (or similar scopes of authorization specified at the DID Document level).

This last two paragraphs deserve to make it into the new issue on delegation. Some of us have definite ideas about the folly of "VC Delegation", so I'm sure we'll have a lively discussion once that is created.

Eric, are you good moving forward with "Delegate" as the term for the entity(ies) for whom authentication section enables some form of action? Can we move forward with that and move the delegation discussion to a new issue?

from did-core.

@jandrieu Yes - let's pick up this conversation in a new issue - I never had any particular problem with the terminology, I entered the conversation indirectly. As I feel that this issue has left me more confused than I was previously, I will gladly accept whatever term is selected for whatever roles and functions are ultimately reflected by the thing that we are talking about.

The PR will no doubt prove quite enlightening ;)

from did-core.

@Oskar-van-Deventer are you good with moving your concerns to issue #190? If that doesn't capture your concerns, perhaps we need yet a third issue.

What do you think?

from did-core.

@Oskar-van-Deventer are you good with moving your concerns to issue #190? If that doesn't capture your concerns, perhaps we need yet a third issue.

What do you think?

I agree. Thank you for getting this clarity.

from did-core.

Excellent. Thanks.

@msporny I believe you have a PR almost ready with "Delegate" language? We have cleared the confusion on the topic and are addressing everyone's concerns, either in this discussion or in #190.

from did-core.

@msporny I believe you have a PR almost ready with "Delegate" language?

Yes, I hope to give it a go tonight... hopefully PR by tomorrow or end of week.

from did-core.

PR is available here: #192

from did-core.