DID Working Group Telco — Minutes

Date: 2019-11-05

See also the Agenda and the IRC Log


Present: Brent Zundel, Daniel Burnett, Ivan Herman, Amy Guy, David Trang, Dudley Collinson, Alexander Hripak, Phil Archer, Ted Thibodeau Jr, Dave Longley, Markus Sabadello, Joe Andrieu, Chris Winczewski, oliver terbu, Michael Jones, Adrian Gropper, Yancy Ribbens, Ganesh Annan, Michael Lodder, Orie Steele, Samuel Smith, ken ebert, Christopher Allen, Kim Duffy, Kyle Den Hartog, Justin Richer

Regrets: Manu Sporny, Drummond Reed, David Ezell

Guests: Sumita Jonak, Joel Harshorn

Chair: Brent Zundel

Scribe(s): Dave Longley, Amy Guy


Dave Longley: brent goes over the agenda

Brent Zundel: We want to get a FWPD NOTE for the Use Cases published by the end of November.
… Any changes to the agenda?

Daniel Buchner: I’d like to get feedback on my PR.

1. Presentations, agenda

Chris Winczewski: Chris from Learning Machine here in the WG for the first time.

Sumita Jonak: I’m Sumita from USAA.

Joel Harshorn: This is Joel from USAA as well.

Brent Zundel: Reminder that we use IRC to record minutes and to queue, use q+ to type what you want to say, if you want to remind yourself what to say when it’s your turn type q+ to say what you wanted to say
… I encourage everyone to do that and participate in the meeting as fully as you can, if you don’t have access to IRC let us know and we’ll queue you.

Daniel Buchner: Have a (seemingly) uncontentious PR in for matrix param that had good consensus, and would love to get a thumbs up/down if possible. PR can be viewed here: https://github.com/w3c/did-core/pull/84

Brent Zundel: We setup a poll to pick a time for the key format discussion.

Daniel Burnett: It will be 1pm EST Wed the 6th. 10AM PST, 7PM Central Europe.

Brent Zundel: We’ll send out an email to the times and the connection to that meeting.
… It’s for people to continue the discussion public key formats and hopefully come to consensus that we can bring back to the main group and reach agreement on public key formats.

Michael Lodder: mike-lodder has joined #did

2. Context URI

Brent Zundel: https://github.com/w3c/did-core/issues/5#issuecomment-548783580

Brent Zundel: I’m going to give this a 5 minute time box.
… We’re debating whether we’ll use the ns namespace, there are some contractual guarantees about longevity there vs. using the date field. We don’t seem to have a really clear direction either way. The date field with the ns without the version seems to be slightly more popular.
… We’d like to fix this sooner rather than later.

Dave Longley: is the version without ns more popular? I’d like to speak against excluding the version. We found in VC that using the version was useful for comparing the URL against a version that was hashed in the spec, with the expectation that the version would be incremented later
… if we’re not going ot use a version number, I’m not sure what that would end up looking like. We’ll end up having another bikeshedding discussion for whatever the new thing is going to be

Ted Thibodeau Jr: straw poll could be useful…

Daniel Burnett: straw poll has been happening in GitHub

Ted Thibodeau Jr: there are only a few people participating in github, could we do a straw poll in the call?

Brent Zundel: Option1: https://www.w3.org/2019/did/v1

Brent Zundel: Option 2: https://www.w3.org/ns/did/v1

Brent Zundel: Option 3: https://www.w3.org/ns/did/2019/v1

Michael Lodder: Option 2

Yancy Ribbens: +1 option 2

Amy Guy: 2

Phil Archer: 2

Dave Longley: option 2

Ganesh Annan: 2

Alexander Hripak: 2

Joe Andrieu: 2

David Trang: 2

Orie Steele: 2

Michael Jones: 2

Ted Thibodeau Jr: +0 option1, +1 option2, +0 option3

Dudley Collinson: Option 2

Oliver Terbu: 2

Ivan Herman: 2

Daniel Buchner: 2

Markus Sabadello: Examples: VC uses Option 1. ActivityPub uses Option 2.

Daniel Buchner: Looks like #2 is #1

Proposed resolution: The DID WG will use https://www.w3.org/ns/did/v1 as the URL for the DID spec context documents. (Brent Zundel)

Ivan Herman: +1

Brent Zundel: hearing no objections…

Daniel Burnett: +1

Amy Guy: +1

Dave Longley: +1

Orie Steele: +1

Joe Andrieu: +1

Ganesh Annan: +1

Yancy Ribbens: +1

Alexander Hripak: +1

Phil Archer: +1

David Trang: +1

Dudley Collinson: +1

Ted Thibodeau Jr: +1

Resolution #1: The DID WG will use https://www.w3.org/ns/did/v1 as the URL for the DID spec context documents.

Ivan Herman: To try to make things proper, if one of the editors of the DID core document to make an update that we use this URL everywhere that I can at the last minute I can update the document that will be published on Thursday. If it’s done today then I can handle things tomorrow.

Amy Guy: I can PR for that if everyone else is busy

Brent Zundel: Thanks Ivan.

Markus Sabadello: if @rhiaro does a PR for this, `i can review and merge

3. Use cases and requirement document

Daniel Burnett: https://w3c.github.io/did-use-cases/

Daniel Burnett: https://github.com/w3c/did-use-cases/issues

Joe Andrieu: Phil Archer and I are the editors on the Use Case document and we’ve had some logistical troubles getting it started, we had a good call now. We had a rewrite from Phil on the opening section, specifically addressing concerns that there’s too much primer.

Phil Archer: phila: I’m here, but am in a noisy place with about 20 mins of battery power so I’ll stay on mute until I need to speak

Joe Andrieu: One of the things we’d like to talk about here is the best way to get from here to FPWD.
… We have a bunch of issues from Mike Jones and some from Ivan and some from TPAC.
… I’ve triaged most of them, maybe 6-7 I haven’t commented on and we can look at those. I mostly want to identify the ones we can get into FPWD, others require more conversation and the thought is to not include those in FPWD.

Joe Andrieu: https://philarcher.github.io/did-use-cases/

Joe Andrieu: Phil has put together a version on this personal github.
… We hoped to get it as a PR in time for the call but we’ll do that later.
… As I mentioned, there’s a significant shift in the beginning, the abstract is much simpler and is based on the 4 bullet points that Markus and Drummond have been pretty consistent about on the notion of DIDs.
… There’s a how to use a DID section that got streamlined as well.
… There was a tension here that Phil and I talked about. In what mental model is the use cases, etc. – on one hand it should be done ahead of time and on the other we need some notion of what the language is of the things we’re talking about.
… So Phil brought in those concepts but in order to talk about those implementation issues we had to get them on the table.
… We wanted to move away from a primer and towards a more traditional use case and requirements document.
… The next step here is that Phil will turn this into a PR and hopefully in the next couple of days.

Phil Archer: I’m in a noisy place. Very pleased to talk with Joe – really pleased that we quickly agreed on what Joe has sent out. That section that we’ve now suggested we call the concept section. I agree completely that we have some sort of framework to talk about the problems we’re describing. The concepts don’t tell you what the solution will be. The amount of editing that I did on that is not actually very large.
… Most of that text was there before and you can look at the diff to check that out.
… Just a slightly different framing for the reasons that Joe just said.

Joe Andrieu: Thanks Phil.
… Phil also added section 3 which is something the whole Use Case team (there are other folks that have volunteered and I wanted to give credit, Ken Ebert, and one other I can’t recall right at the moment).
… We’ll sync up with Ken on the regular call time we settled on and hopefully you can join.
… Section 3 – it is going to be a set of 20-25 short Use Cases, a paragraph or two each with compelling names. This is akin to the problem domain section in the VC use case doc. In this section we will try and capture a couple dozen key use cases that will let people see it’s related to their work and read more.
… In contrast in the focal use case section it’s a deep dive.

Markus Sabadello: I just wanted to say I don’t think I can contribute on an ongoing basis but I have responded to 3-4 issues on the repo and would be happy to help with PRs on those 3-4 issues I commented on. Mostly about references to DID resolution and DID Auth.

Joe Andrieu: Ok, great, feel free to take over the assignment to put together a PR for them. That would be great to get those references in.
… Thank you.

Markus Sabadello: okay will self-assign those issues where I commented

Joe Andrieu: This was just a brief introduction to where we’re at with the document, I feel really comfortable with the document. I feel comfortable Phil’s feedback and criticism.
… We will address other issues.

Phil Archer: I know everyone is keen to get this to FPWD, Joe and I have a regular call we’ll meet on a Wednesday to keep it on track including tomorrow and I can’t promise – I’m confident between us we’ll have a document for a potential FPWD this time next week. A week later than you wanted but we’re on the case.
… We’re both reasonably hopeful for this time next week.

Joe Andrieu: Thank you, Phil.
… Phil, you’ve got a PR to put together.

Phil Archer: Tomorrow morning first thing. Will start by integrating Amy’s first and then merge mine.

Amy Guy: phila, I can re-freeze it for fpwd when you’re done if you like

Phil Archer: It might work out easily just didn’t tackle it last night.

Phil Archer: +1 to thank Amy

Joe Andrieu: Thank you Amy for taking that and there were things you caught we didn’t and we appreciate that.
… Between those of us on the call and what we get in the triage to look at issues and assign, I’d like to get PRs small, nearly editorial PRs in for FPWD consideration next week. Chairs, how does that work for you guys?

Brent Zundel: The group’s goal is by the end of November so by the end of next week sounds fabulous.

Joe Andrieu: We’d present it on the call next week and give a week for people to shout.
… Ok, I think we can support that. We’re really mostly just doing editorial changes that are easy and quick and larger questions can be deferred to after FPWD.

Ivan Herman: When I looked at the charter this morning when looking at the use cases, the charter talks about the use cases and requirements whereas the title here is only “Use Cases”. Perhaps we should update the title to be “Use Cases and Requirements”.

Michael Jones: I agree we should do that.

Joe Andrieu: I agree.

Phil Archer: phila: It will be Use Cases and requirements, no worries

Ivan Herman: I raise an issue do that after the call.

Joe Andrieu: Thanks for that, Ivan.
… Ok, we can move over to issue triage.

4. Use cases’ issue Triage

Brent Zundel: Rest of the meeting is yours, doing great on time.

Joe Andrieu: https://github.com/w3c/did-use-cases/issues

4.1. timestamped proofs #1

Joe Andrieu: The first one is timestamped proofs.

Joe Andrieu: https://github.com/w3c/did-use-cases/issues/1

Joe Andrieu: https://github.com/w3c/did-use-cases/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc

Joe Andrieu: This was transferred over from the CCG. This is not going to be in FPWD because we need to come up with a use case that documents timestamped proofs in some way.

Brent Zundel: Did you want to see if anyone would like to be assigned to the issue?

Joe Andrieu: The issue of timestamped proofs is that DIDs that are on a public ledger do have the capability of some robust notion of when the DID may have been updated. We’d like to make sure that this gets incorporated into one or more use cases.
… Would anyone like to pick that up?
… As we go through these I will give an opportunity for people to jump on the queue or assign themselves directly on github. I do want to get to assigning FPWD or not.

4.2. Portability #2

Joe Andrieu: https://github.com/w3c/did-use-cases/issues/2

Joe Andrieu: Number 2 is about portability. About one DID method substituted for another.
… A use case that describes the need to do that would be useful.

Daniel Burnett: Just a reminder: being assigned means you will make sure the issue keeps moving forward to a decision or closure.

4.3. Portability #8

Joe Andrieu: https://github.com/w3c/did-use-cases/issues/8

Joe Andrieu: Number 8 is when do we publish FPWD of the Use Case and Requirements document.

Daniel Burnett: If an issue remains unassigned there is no guarantee it will ever be addressed . . .

Joe Andrieu: Mike Jones, can we just close this given our commitment here or do you want to wait for FPWD?

Michael Jones: It would be better it seems to leave it open until we’ve published one.

Joe Andrieu: I’m completely good with that. I will take the assignment and mark it as FPWD.

4.4. Synchronize DID role terminology #10

Ivan Herman: https://github.com/w3c/did-use-cases/issues/10

Joe Andrieu: Synchronize DID role terminology is next.
… It used to say “what can you do with a DID” and we talked about controller, relying party, and subject. This won’t be done by FPWD but I’ll assign myself to this.
… All that terminology we have issues for, I’ll sign up for this.

Michael Jones: I have a comment. Is the relying party not in common use any more?

Joe Andrieu: I can try and address that any more? I don’t know if it was two years ago any more? There was a discussion about using that term or verifier or something else.
… The world I know you from with user centric stuff that relying party term was in use. But that might not be the same here. What do you call the person who is relying on a DID but isn’t in control of it?

Michael Jones: Ok, then we should have that conversation but not now.

Joe Andrieu: That issue is a good place to queue it up and maybe talk about it there.
… I think we should add this to the DID controller, subject/etc. conversation, it’s the other side of the coin.

4.5. relationship between DID Methods and DID Authentication in Use Cases document #13

Joe Andrieu: https://github.com/w3c/did-use-cases/issues/13

Joe Andrieu: I was in the midst of writing a response to this. Won’t be resolved by FPWD and we’ve gotten through the other issues already and we’ve got 20 minutes left I’d like to open this up.
… There’s a tension here that I do believe that authentication is not method specific. I think the only exception to that is if the authentication section is empty and the only thing you can do is mention that you’re a controller.
… But there’s a DID Authentication section should not be method specific. That whatever is in there should not be method specific.

Samuel Smith: I think the complication is the “other” party is contextual. Is the DID being used to authenticate, authorize, engage in a transaction. In all cases the “other” party must verify that the use is authoritative for that DID. So is the signature on a transaction stage authoritative for that DID

Dave Longley: DID method authentication should be DID method independent in general.

Samuel Smith: So it could be encryption etc decryption

Dave Longley: That is not to say that a DID method could not define a DID authentication mechanism, but in general, DID authentication is for applications (which may or may not be DID registries/ledgers themselves). Authentication is independent of DID methods.

Markus Sabadello: I wanted to agree with Dave. In general DID authentication is DID method independent. There might be certain DID methods that have keys or methods that are inherent to that DID method, for example, some authentication methods might be related to ethereum and some DID methods might be based on ethereum. So there might be natural correlation there, but in general it should be independent as Dave said.

Joe Andrieu: Thank you, Markus.
… My larger question as a Use Case editor – how much should we go into that in the Use Case Document?

Dave Longley: the authentication mechanism should be the same across multiple did methods, as long as the service supports resolving via different methods. Providing they all express verification mechanisms in those did documents that are compatible
… there are lot of implementation details that need to be extracted
… one application should be able to accept multiple types of dids and use one authentication mechanism across that

Joe Andrieu: Ok, I like that a lot, so you don’t have to have different usernames and passwords everywhere. If you’re comfortable with one authentication method it could be tied to different DIDs, etc.

4.6. What does it mean for a DID to be recorded in a registry? #14

Joe Andrieu: https://github.com/w3c/did-use-cases/issues/14

Joe Andrieu: What does it mean for a DID to be recorded in a registry?
… We don’t explain what that means. I’ve since learned of a whole class of DID methods, mostly building off of ethereum and smart contracts – that don’t even require a DID to be recorded to be valid.
… We should clean this up.
… I’m not sure that’s still a requirement.

Michael Jones: This was one of these cases that reading it as a novice that it was clear that people meant certain things but it wasn’t written down.

Joe Andrieu: Yes, I appreciate that even when trying to be diligent when writing things down.

Michael Jones: Absolutely.

Samuel Smith: How about copartent for the corresponding party in an interaction with a DID controller

Joe Andrieu: We should clear this up one way or another, just a question of whether we can get that done this week before FPWD.

Kenneth Ebert: Wanted to ask if the peer DIDs that may or may not be recorded in a registry would be impacted by this section as well?

Joe Andrieu: Right, I agree, peer DIDs don’t have a registry. That challenges a bunch of the language in here both potentially in the core spec and the use cases.

Markus Sabadello: My understanding is that all DIDs that can be resolved have a DID registry. In the case of peer DIDs the registry is your local wallet/registry, it’s not a blockchain or DLT. We used have a term “target system”, but the way I think about it is that if a DID can be resolved then there is a registry somewhere.

Joe Andrieu: So I know at least for DID ether, any valid public key that matches the criteria to be an ethereum address is a valid DID, you can construct the DID document on that alone. It’s only if you need to rotate keys that you need to register.

Samuel Smith: As the root of trust for a self-certifying identifier is the degree of collision resistance imbued by the entropy in the creation of the private key in the public private key pair there is no intrinsic reason for a self-certifying identifier to be registered. Registrations is a discovery mechanism or an anchor for other actions

Justin Richer: This conversation is just making me wonder if the registry is the wrong overloaded term. I realize the group has arrived at “registry” with lots of stabbing and biting along the way there but given that there is a fair bit of garden pathing on this call and how registry applies to different things.
… We might really be talking about something else. I don’t have a better term for it in my pocket. Given what Markus was just saying, it’s tied to resolution, it’s tied to the nature of the connection between the DID and the DID Document, registry might not be the right word.

Joe Andrieu: Yeah. Please comment on the issue or PR.

Dave Longley: veres1 has a similar feature, with multiple did methods. You only need to register your DID if you want to enable rotating keys

Samuel Smith: Universally uniqueness comes from the entropy not from first to register. Registry implies some sort of first to register priority

Oliver Terbu: I remember we had the terminology discussion at IIW. The terminology we used back then is the anchor system.
… What Joe mentioned earlier about ether is totally true. There is no registry of all potential ether DIDs.

Daniel Buchner: Should note that this topic of non-registered DIDs is directly tied to the PR I mentioned earlier in the call: https://github.com/w3c/did-core/pull/84

Daniel Buchner: It would be great if this mechanism could be used to convey the initial DID Doc for all these methods

Joe Andrieu: I’ll note that from a privacy perspective I like that a lot and that we don’t gloss over that by choosing poor language.

Samuel Smith: I also have a problem with the term registry because it’s use implies first to register establishes ownership. Whereas the ability to assert control over pseudorandom information in the DIDs is the root of trust. The root of trust is self-evident in the entropy imbued within the identifier.

Daniel Burnett: We need these comments in GitHub

Joe Andrieu: I do think people see the value of the audibility of a public ledger. There are some things you’ve said that some people would take issue with but the entropy in the DID is a driving factor.
… But some people aren’t using DLTs.

Daniel Buchner: And the fact that you can never be certain that your branch of a DID after genesis op is essentially unknowable without a linear state oracle that your branch is correct

Samuel Smith: Saying you want auditability isn’t in contradiction with what I said, but the root of trust for the DID itself doesn’t require ledgers or registration. If it’s a self-certifying DID.
… Some that aren’t self-certifying will require more. I think all DIDs should be self-certifying but that’s a different discussion.

Joe Andrieu: Thanks everyone. Next week when we have the proposed FPWD doc we’ll be going over that.

Brent Zundel: Thank you, Joe, for taking us through that and thanks to everyone for participating in the discussion. Will remind everyone that a lot of the work needs to happen in github, we encourage everyone to read the issues and review the PRs.
… If there is a direction you feel this spec ought to go that’s where you’d make those recommendations, that’s where you’d raise any objections too. Go to github, raise issues, comment on issues, etc.
… Thank you everyone for joining us on this call. We look forward to visiting with you again next week. Thanks to Dave and Amy for scribing.
… Thanks to everyone for coming!

5. Resolutions