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.