Figure out three fundamental roles of DIDs (controller, subject, XXX)

[jandrieu]

At TPAC, we identified three distinct roles whose terms are currently problematic and sometimes conflated. This confusion has shown up in conversations and in actual spec-text. We need to find good, clean terms for each of these roles.

DID Subject

The first is perhaps the least controversial, DID Subject, the entity referred to by a DID: the referent of a DID. Or in terms of a common use case, if a Verifiable Credential uses a DID as a subject, then its claims are understood to be about the DID Subject.

DID Controller

This second term has been used broadly, but has sometimes been conflated with the third. DID Controller was introduced as an alternative to "DID Owner"--which had complicated implications from legal and other perspectives. The DID Controller is the entity (or entities) who has (have) the ability to change the DID Document. Functionally, anyone who can control the DID Document is the DID Controller. For clarity, the DID Controller is the same as the DID Document controller. This role is essentially omnipotent wrt the DID; because they can change the DID Document, they can do anything, including rotating keys, changing service endpoints, managing authentication, and deactivating the DID.

DID XXX

The third role has been called "controller", to the dismay of some. This role is an entity capable of exercising one or more authentication capabilities (as specified in the authentication property of the DID Document). This authentication demonstrates the entity's legitimate authority to act on behalf of the DID Subject. In particular, this authentication to act on behalf of the DID Subject does NOT include the ability to change the DID Document. (If an entity has both the authority to act on behalf of the DID Subject and to change the DID Document, they simply have both roles).

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).

I suggested "actor" for this third term. DID Actor is the entity acting on behalf of the DID Subject. However, several participants bemoaned the over-use of Actor in computational systems.

@deiu brought up that this was a big issue in the WebID work, where eventually, "delegator" and "delegate" were chosen.

I like "delegate", so I'll withdraw "actor" as a proposal.

This would suggest the trio of terms could be

• DID Subject
• DID Controller
• DID Delegate

This issue is specifically to kick off what will hopefully be a relatively short period of bike shedding to find an appropriate term for this third entity.

Comments and suggestions welcome.

[RieksJ]

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.

[brentzundel]

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

[brentzundel]

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

[tplooker]

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.

[jandrieu]

@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

[peacekeeper]

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.

[tplooker]

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.

[dlongley]

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.

[jandrieu]

@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.

[tplooker]

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.

[Oskar-van-Deventer]

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

[msporny]

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.

[ewelton]

@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.

[msporny]

@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.

[ewelton]

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".

[ChristopherA]

On Mon, Feb 10, 2020 at 6:54 AM Oskar van Deventer notifications@github.com 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

[Oskar-van-Deventer]

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

[msporny]

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.

[jandrieu]

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

[talltree]

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).

[dlongley]

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.

[selfissued]

Naming is hard (and very important!).

[ewelton]

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 ;)

[jandrieu]

@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?

[ewelton]

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.

[jandrieu]

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?

[ewelton]

@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 ;)

[jandrieu]

@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?

[Oskar-van-Deventer]

@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.

[jandrieu]

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.

[msporny]

@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.

[msporny]

PR is available here: #192