Decentralized Identifier Working Group — Minutes

Date: 2019-11-26

See also the Agenda and the IRC Log

Attendees

Present: Orie Steele, Manu Sporny, Jonathan Holt, Brent Zundel, Markus Sabadello, Daniel Buchner, Drummond Reed, Ted Thibodeau Jr, Michael Jones, Tobias Looker, Grant Noble, Kim Duffy, Adrian Gropper, Dudley Collinson, kimd, Kenneth Ebert, Dmitri Zagidulin, Samuel Smith

Regrets: Ivan Herman, Daniel Burnett

Guests:

Chair: Brent Zundel

Scribe(s): Drummond Reed, Kenneth Ebert

Content:

Brent Zundel: rrsagent draft minutes

1. Agenda review, Introductions, Reintroductions

Daniel Buchner: Need to add an item to the agenda

Daniel Buchner: https://github.com/w3c/did-core/pull/84

Daniel Buchner: https://github.com/w3c/did-core/issues/70

Daniel Buchner: Should be a quick consensus confirm

Daniel Buchner: there was already 0 opposition during all discussion and the PR should be clean

Drummond Reed: First up: agenda review and intros/reintros

Brent Zundel: Agenda first up will be announcements, then status update on key formats, then horizontal review, then PR 84 and issue 70, then continue DID metadata
… then if time, matrix parameters
… At the F2F in Amsterdam, the social event will be a boat tour. Ivan will help organize.
… cost will be about 20 euros per person - seeking sponsors
… FPWD of Use Cases document will be published the 28th
… next key format discussion will be Wed Dec 4th at noon Eastern Time

Grant Noble: Introduced himself. Works with Dan Burnett on the Pegasus team at Consensys. Based in Australia.

Adrian Gropper: Introduced himself. CTO of an NGO called Patient Privacy Rights.
… works on putting together the various standards that can support patient privacy in healthcare.
… working on SSI, UMA, OAuth

2. key format discussions

Brent Zundel: Asking Orie to give an update on key format discussions

Orie Steele: Been discussing different key formats. Multiple proposals for early voting.
… JWK is always a valid format for representing keys.
… Attempting to come to some consensus about what other formats should be supported.
… RSA PEM and ed25519 are being considered/discussed.

Brent Zundel: any proposals coming out of this group will be brought before the greater group for consensus
… encouraged by progress

Kim Duffy: Question for Orie: where did we land with the ongoing algorithmic agility concern?
… with JWK, there were potential nonsense combinations

Orie Steele: there is an open issue assigned to him RE the specific privacy concerns on JWK or other key formats that uses non-standard config values
… this applies to all properties in a DID document
… JWK and Jose have formal key definitions, but not for base 58
… multibase has been raised as a format that a number folks like
… there is a spec in progress at IETF on that

Orie Steele: regarding pii / extra data in did documents (and their properties): https://github.com/w3c/did-core/issues/124

Orie Steele: Regarding supported public key formats: https://github.com/w3c/did-core/issues/67

Michael Jones: Responding to Kim: it’s possible to inject stuff with privacy concerns in any key format, including JWK
… it can be somewhat controlled by required and optional fields

Brent Zundel: if you care deeply about this topic, please join the calls for the subgroup

Jonathan Holt: is on the phone

3. horizontal review

Brent Zundel: https://github.com/w3c/did-core/labels/horizontal%20review

Brent Zundel: this is the labeled horizontal review issues
… the chairs have reached out to the other chairs to let them know about the FPWD
… the chairs have looked at the assessment, especially 104 and 105
… if you disagree with the assessment, let the chairs know
… the chairs also invited feedback from the other groups
… also, the Privacy Interest Group has indicated interest in reviewing

4. Issue 70

Orie Steele: https://github.com/w3c/did-core/issues/70

Brent Zundel: 5 minute time box

Daniel Buchner: proposal is for an additional matrix parameter called initial values
… this is needed for DID methods that are anchored someplace else and thus there may be initial values that need time to be turned into final values
… having the initial values allows the DID to be used immediately

Markus Sabadello: Has been part of the discussion of this, and generally supports it
… suggests that before we discuss any of the matrix parameters in detail, we should introduce the overall topic

Manu Sporny: would like to have the matrix parameter discussion first
… this for example might be a resolver option
… also would like to see examples in the spec, because it’s hard to understand
… for example, how are the initial values expressed/encoded

Orie Steele: for example: did:sidetree:<unique-portion>;initial-values=<encoded-original-did-document>

Orie Steele: I just added a reference to how this is used in sidetree to the issue.

Manu Sporny: I wonder if we should do a matrix param for the specific thing Daniel mentioned.

Daniel Buchner: the initial values parameter is defined by the DID method spec
… a specific example for the sidetree method is above
… the use of initial values enables a single DID document to be stored rather than two of them

Manu Sporny: that helps. Please add that example to the PR

Brent Zundel: everyone who is interested in this issue, please review, and if you approve, indicate that

5. DID metadata

Brent Zundel: https://github.com/w3c/did-core/issues/65

Brent Zundel: wants to frame the discussion as finding answers to 2 questions:
… 1) what is DID document metadata
… 2) Where does it go in the DID document?

Dmitri Zagidulin: proposes a third question: if it does belong in the DID document, how do we represent it?
… does it belong in its own subgraph?
… does it go in its own envelope?

Manu Sporny: https://github.com/w3c/did-core/issues/65#issuecomment-558274770

Markus Sabadello: this is a deep topic, which takes us deep into the RDF discussions
… there is some discussion about DID resolution results, and how to control them
… Markus feels those should be controlled by resolution parameters
… but that is not what we are talking about in this issue
… rather we are talking about metadata about the DID, DID subject, etc.
… second point was that there was conflation of identifiers for the DID subject and the DID document
… and that is important from an RDF and semantic web context
… if the DID is an identifier for the DID subject, then how is the DID document identified?
… for example if a fragment is added to the DID, it resolves inside the DID document
… thus the DID document is a Web resource
… this results in conflation of the DID and DID document
… some would call it conflation and some would call it simplification

Manu Sporny: Markus provides two examples here – https://github.com/w3c/did-core/issues/65#issuecomment-558274770

Manu Sporny: Analysis of Markus’ examples and another example – https://github.com/w3c/did-core/issues/65#issuecomment-558838589

Manu Sporny: Markus’ two examples are very helpful
… Manu followed with his analysis
… if folks haven’t read that, we won’t get far on this call today
… first point: we have confused everyone by calling it a DID document
… fundamentally it’s not an RDF “thing” or not. It’s an informational thing.
… the DID identifies a DID subject, and then you can say things about it
… so there is information, and then there is metadata about the information
… so he disagrees with Markus that there is conflation
… Manu believes the DID always identifies the DID subject
… thus if we want metadata about the DID information, we need to make it clear
… the three potential approaches are
… 1) put the metadata on the outside (this was done with verifiable credentials)
… 2) add a meta field (done for proofs in verifiable credentials)
… Manu thinks that’s the wrong approach
… 3) put the metadata in the DID resolution result
… Manu believes that’s where most of the metadata belongs
… it may sound like this is a fairly simple discussion, but it suffers from definitions

Orie Steele: did resolution aligns with document loader concept in json-ld…

Ted Thibodeau Jr: DID identifies the entity which we’ve been calling the DID subject.
Dereferencing the DID gets a description/representation of that entity (the DID subject), which we’ve been calling the DID document.
Metadata about the description might say when that description was updated.
Metadata about the DID document which conveys that description might say when that representation was updated/generated.
*Electronic documents (and their provenance, destiny, etc.) are harder to track than paper documents, but they are no less analogous or important to be describable because of that difficulty.

Drummond Reed: I agree this is a challenging subject.

Manu Sporny: +1 to drummond!

Manu Sporny: yes, exactly

Brent Zundel: +1

Daniel Buchner: jonathan: I addressed your comment on GH Issue 70 just now

Drummond Reed: Principle 1. The did identifies the did subject. Period.
… Principle 2. I like the term did doc. The way we describe it can be muddy. We need to be clear in the spec.
… It is not covered in the community draft.
… From a web standpoint, does it need an identifier or not?

Manu Sporny: I’m agreeing w/ drummond, what he’s saying makes sense to me.

Dmitri Zagidulin: I wanted to clarify what manu was saying.
… The discussion is very much NOT about metadata about the resolution.

Dmitri Zagidulin: https://w3c-ccg.github.io/did-resolution/#example

Dmitri Zagidulin: In example 3, we have a separate resolution structure which separates the meta that is about the document and resoltion.
… this example from the DID resolution spec clearly separates the metadata about the resolution process vs. metadata about the DID document that is method-independent
… we keep retreading the same ground around questions like the date of the DID document. Some say it should be the ledger, but some ledgers don’t keep time

Jonathan Holt: I think that the datecreated is there for convenience. It could be interpolated and self-asserted.
… Some DID methods self-assert the time, whereas others are verifying it via the DID registry
… so in some cases its self-asserted and in some it is interpreted
… the self-assertion is for convenience, but they can also be verified via resolution

Orie Steele: I’m in favor of not mutating the didDocument type with metadata annotations… mostly because it will create integrity / authentication issues with signed documents…

Markus Sabadello: Disagrees with Manu and agrees with Dmitri that metadata that describes the DID document belong inside the DID document
… an example is proofs included within the DID document under the BTCR method

Tobias Looker: Does the metadata conversation need to separate along the lines of who created of the metadata? E.g metadata created by the ledger vs that is asserted by the entity who updated the did?

Dmitri Zagidulin: Orie: absolutely agreed. But we’re only talking about metadata that comes into existence the moment the DID Document is created. That is, it’s metadata that is signed over, it’s protected by the signature

Markus Sabadello: different resolvers may give you different resolution metadata, but the proof metadata should always be the same inside the DID document
… RE the question about whether the DID document has a Web URI, he again points to fragment resolution
… but he’s in favor of not changing anything

Jonathan Holt: tplooker “Turtles all the way down”

Manu Sporny: URIs are opaque, full stop
… the fact that a DID URl starts with the DID subject identifier has nothing to do with being able to point to info inside the DID document
… the point is that you have an identifier that you can use to point inside a graph of information
… Manu is also hearing argument that “it’s convenient”
… arguments for putting in the metadata are “convenient” for methods that don’t have another way to do it
… but Manu believes that there is a cleaner way to add that metadata
… a specific example is “created” or “updated” dates. Do they describe the DID subject or the DID document?
… if the data model is not clear, then implementers will use the same value for different purposes
… let’s not do this. Let’s clearly separate statements about the DID subject, and statements about how the DID document was produced

Orie Steele: +1 to manu’s point… messing with the didDocument alters its type… end up getting a type that is part data about subject / part meta data about identifier…

Manu Sporny: to put it the other way: anything that puts the metadata on a DID ledger, the DID document author cannot tell the ledger about the metadata; the ledger is authoritative.

Dmitri Zagidulin: it’s more than convenient though…
Dmitri Zagidulin: has direct implications to security.

Ted Thibodeau Jr: metadata (DID document modification date) about data (contents of DID document) about entity (DID subject)

Dmitri Zagidulin: wait.. but the resolver document /does/ have that information already.

Markus Sabadello: +1 to continuing this conversation

Samuel Smith: Having a difficult time with this conversation.
… the original purpose of the DID spec is to convey trust over the Internet
… it’s more important than anything else we might do
… so when we start discussing things that make that harder, it confuses us. One step forward, 2 steps back

Manu Sporny: yes, but I don’t think anyone is saying “don’t express created” – we’re discussing where created should go.

Samuel Smith: there are a few things done with DID documents, and those should be very strongly supported cryptographically
… so the test should be can a DID document establish a verifiable root of trust (a “control authority”) and everything else should be secondary
… if we lose sight of that fact, then we will stray from the main purpose of DID documents

Markus Sabadello: Agrees with what Sam said.
… responding to Manu, although URIs are opaque, but we can’t ignore URI rules
… the rules are that to dereference a fragment, you first resolve the primary resource, then you resolve the fragment to a secondary resource
… by that logic, if a fragment identifies a secondary resource in a DID document, then the DID document must be the primary resource

Dmitri Zagidulin: manu: we’re discussing where 3 different ‘created’ timestamps go. 1) when the did document was created, 2) when it was registered on the ledger/whatever persistence mechanism, and 3) when it was resolved. We already have a data model for expressing 2 & 3. So we’re arguing about 1.

Ted Thibodeau Jr: they remain opaque. the lexical characters that comprise the fragment, as well as the rest of the URI, have no inherent meaning.

Manu Sporny: +1 TallTed

Dmitri Zagidulin: Believes that Manu is suggesting that resolution metadata be injected into a DID document.
… there are 3 different timestamps involved: 1) creation, 2) registration, 3) resolution
… we had a place for created-date, but this whole discussion was kicked off by the PR to remove that
… so clarified that we are talking about the creation date of the DID document itself

Michael Jones: Most important is to keep it simple
… the most important thing is to be clear about which properties describe what
… so some claims can describe the subject, but others can describe other things
… an example is the “audience” claim in JWT, which describes who the claim is for

Samuel Smith: The problem is the mental model. Well suited mental models lend themselves to straightforward answers. Poorly suited mental models have convoluted difficult to understand answers. From a cryptographic standpoint 1) We need to establish the current control authority for the DID and DID Doc. 2) Given that control authority we then need to establish if the DID Doc was provided under the current control authority.
Answering this second question requires linking the DID Document with some identifier for the current control authority. This naturally lends itself to some type of version identifier.

Ted Thibodeau Jr: It’s hard to keep it simple because there are a lot of layers here. To keep it precise, we must have some complexity
… prefers the term “Decentralized Identifier” because it’s clearer
… the statements that describe the DID subject can go anywhere

Manu Sporny: YES, +1000 to TallTed !

Ted Thibodeau Jr: when we dereference the DID, we get back some manifestation of those statements
… we need to be able to say:
… 1) they were made at some time
… 2) they were posted at some time
… 3) they were retrieved at some time
… 4) they were forwarded at some time
… what would really help is a picture that sketches out the layers and what goes where
… this might reveal 17 “created-dates”, but they can all be precise

Samuel Smith: So cryptographically how do we establish that given did doc was created by the current control authority. The easy approach is that its signed non-repudiably by the control authority. This means that some identifier within the DID Doc is included in the signature in order to make the linkage non-repudiable. Putting that linkage anywhere else is bad crypto. It doesn’t matter whether or not if fits an RDF model. Bad crypto is bad crypto

Dmitri Zagidulin: there isn’t 17 different created stamps though. There’s only 3.

Samuel Smith: The complexity is we have a poor mental model of what we are trying to accomplish with a DID Doc.

Michael Jones: +1 to what Sam said

Dmitri Zagidulin: +1 to what SamSmith is saying, about a signed non-repudiable ‘didDocumentCreated’ timestamp, as opposed to ‘didDocumentRegisteredOnLedger’ timestamp, or ‘didDocumentWasRetrievedByResolver’ timestamp.

Tobias Looker: Agrees with Manu that we don’t want confusion for implementers.
… agrees with dmitriz that there is utility in certain types of metadata
… and that there are layers of metadata involved with different parts of the DID document creation, registration, and resolution process

Markus Sabadello: no DID method should allow “created” and “updated” to be written arbitrarily by the DID subject

Samuel Smith: Is the data needed inside the DID Doc? If it is it should not be excluded because we can’t classify it as not metadata

Kim Duffy: What Mike Jones said really resonated with me, and I hope we can aspirationally get to the state he described

Brent Zundel: apologies to the rest of the queue as we are out of time
… encourages everyone to continue working in github and to add comments

Orie Steele: thanks!