@kdenhartog moved from CCG (w3c-ccg/did-spec#166)

@peacekeeper moved from CCG (w3c-ccg/did-spec#200)

@peacekeeper moved from CCG (w3c-ccg/did-spec#205)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#218)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#269)

@kdenhartog moved from CCG (w3c-ccg/did-spec#104)

@peacekeeper moved from CCG (w3c-ccg/did-spec#247)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#271)

...are they lost?

Taken over from the CCG (w3c-ccg/did-spec#82).

Notifications to @msporny @peacekeeper

@aaitor moved from CCG (w3c-ccg/did-spec#224)

Will the eventual https://www.w3.org/2019/did/v1 and the current https://w3id.org/did/v0.11 context for DIDs be version controlled in this repository now, or will it continue to reside at the CCG repo?

If the former, I would propose to pull over PR #272 - Add a contexts/README.md to explain the DID context versioning scheme over to this repo as well, since the topic of @context versioning may be confusing to the wider audience.

@kimdhamilton moved from CCG (w3c-ccg/did-spec#228)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#211)

Just a minor note so that we would not forget: at some point, we will have to update the did reference in https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml, more exactly in https://www.iana.org/assignments/uri-schemes/prov/did.

@AxelNennker Taken over from the CCG (w3c-ccg/did-spec#37)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#268)

@peacekeeper moved from CCG (w3c-ccg/did-spec#198)

@gklyne moved from CCG (w3c-ccg/did-spec#83)

I am not sure how we should handle the registries (LD Cryptographic Suite Registry, DID method registry) listed in Appendix A. There are discussions at W3C on setting up a somewhat more controlled approach for such registries, and this may be at our disposal in the lifetime of this WG. Alternatively, we may want to publish them as WG notes, to give them somewhat more weight. Something to keep an eye on.

@peacekeeper moved from CCG (w3c-ccg/did-spec#267)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#220)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#215)

@msporny @gklyne moved from CCG (w3c-ccg/did-spec#80)

The spec is currently sloppy about the usage of controller and how it's related to authentication. An editorial pass needs to be made on the spec to make sure we're better about use of controller and authenticate.

@mwherman2000 moved from CCG (w3c-ccg/did-spec#213)

@dhh1128 moved from CCG (w3c-ccg/did-spec#97)

The spec allows other verification methods than public keys:

The value of the authentication property SHOULD be an array of verification methods.

Furthermore ...

Each verification method MAY be embedded or referenced. An example of a verification method is a public key (see Section § 5.3 Public Keys ).

We should clarify the extension mechanism for other verification methods:

• will there be a registry?
• will there be a type?
• can you give an example of another verification method?
• ...

@AxelNennker moved from CCG (w3c-ccg/did-spec#38)

@gklyne moved from CCG (w3c-ccg/did-spec#84)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#147)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#121)

@pepoospina moved from CCG (w3c-ccg/did-spec#182)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#123)

@satazor moved from CCG (w3c-ccg/did-spec#96)

The final community specification allows for ethereumAddress public key types. We have to add the respective key type to the context to be recognized by 3rd party applications, e.g., uniresolver.io.

After following the discussion in w3c-ccg/did-spec#270, it seems like we should at least support all public key types that were mentioned in the W3C CCG DID spec.

There are some document references that are done in a normative section and have a normative reference role, although the target is currently just an IETF draft, a note of the CG, etc. It is not a problem now but may become when the document becomes a Rec (unless the target documents become standards by then). The ones I spotted (and there may be more):

• Section 4.3 is normative, and defines the generic DID parameter name hl referring to the Hashlink spec (which is a draft)
• Sections 4.3, 4.7, and 8 are normative, and normatively refer to the DID resolution document (which is a CG report)
• Section 5.9 are normative and normatively refers to the Linked Data Proofs (which is a CG report; note that this reference also bypasses the references at the end of the document, which I am not sure is o.k.)
• Section 7.1 refers to a DID registry, which is "a type of Verifiable Data Registry", referring to an informative section of the VC data model. Although the reference here is a MAY, so it may not be a normative one, but it may be better to make this somehow clearer.

I am also not sure how we should handle the registries (LD Cryptographic Suite Registry, DID method registry) listed in Appendix A. There are discussions at W3C on setting up a somewhat more controlled approach for such registries, and this may be at our disposal in the lifetime of this WG. Alternatively, we may want to publish them as WG notes, to give them somewhat more weight. Something to keep an eye on.

@OR13 moved from CCG (w3c-ccg/did-spec#152)

@mwherman2000 moved from the CCG (w3c-ccg/did-spec#143)

Would it be possible to add a mechanism for encrypting the value of either a) serviceEndpoint URLs, or b) both serviceEndpoint and service types?

Context: this came up in the context of the Solid spec, where there's interest in adopting the DID Document mechanism to replace or augment the existing WebID Document mechanism. One of the service endpoints that Solid webid docs use is to point to the OpenID Connect Issuer endpoint (similar to how we have OpenIdConnectVersion1.0Service type endpoint in the DID spec examples).
And so, the question that came up was: so right now we point to the user's OIDC endpoint in plain text. Would it be possible to obfuscate or encrypt this, instead?

I realize that this opens up a lot of really difficult topics, like how to combine encryption and access control (so that the DID Doc is still useful for discovery, but not for everybody, only for those who have appropriate keys/credentials).

I'm curious if others have came up against this use case or requirement, and how you're thinking of handling it.

@aljones15 moved from CCG (w3c-ccg/did-spec#223)

@RieksJ moved from the CCG (w3c-ccg/did-spec#172)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#148)

@AxelNennker moved from the CCG (w3c-ccg/did-spec#60)

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.

The following section in the spec is wrong, because it conflates authentication with the ability to update the DID Document:

Authentication is the mechanism by which the controller(s) of a DID can cryptographically prove that they are associated with that DID. See Section § 9.3 Binding of Identity . Note that Authentication is separate from Authorization because the controllers may wish to enable others to update their DID Document (for example, to assist with key recovery as discussed in Section § 9.8 Key Revocation and Recovery ) without enabling them to prove control (and thus be able to impersonate the controllers).

@AxelNennker moved from CCG (w3c-ccg/did-spec#39)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#216)

@mwherman2000 moved from CCG (w3c-ccg/did-spec#119)

@peacekeeper moved from CCG (w3c-ccg/did-spec#199)