DID WG weekly — Minutes

Date: 2020-03-10

Attendees

Present: Dave Longley, Joe Andrieu, Amy Guy, Yancy Ribbens, Justin Richer, Markus Sabadello, Michael Jones, Joel Hartshorn, Orie Steele, Chris Winczewski, Thomas Schwarz, Brent Zundel, Adrian Gropper, Phil Archer, Drummond Reed, Jonathan Holt, Andrei Sambra”, Kim Duffy, Kenneth Ebert, Benjamin Young, Ganesh Annan, Kaliya Young, Daniel Buchner

Regrets: Ivan Herman, Manu Sporny

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley

Brent Zundel: We’ll be giving an update on the DID resolution process, etc. and go through some issues.

Adrian Gropper: I’m Adrian Gropper, I’m CTO of a small non-profit called Patient Privacy Rights and I also try to lead a reference implementation of standards that sort of combine the OAuth and SSI specs.
… I call it the Alice to Bob problem, I’m mostly on the use case side of what we do here.

Adrian Gropper: https://weboftrustinfo.discourse.group/t/a-dynamic-digital-passport-for-covid-19-pandemic-mitigation/213

Adrian Gropper: I’m trying to see if there is a group interest in working on contact tracing and self-isolation economic harm reducing app around the coronavirus outbreak.
… I’ve got a link in the chat to a discourse entry in the Web of Trust Discourse, it’s a short description, less than a page. Anybody that might be interested in participating please contact me directly or contribute to the discourse thread, thanks.

Brent Zundel: Anyone on the call for the first time and would like to introduce themselves?
… There was a minor issue getting the doodle poll sent out, the correct one. So not a lot of responses have been made. The correct poll has been sent out and I would encourage everyone to please respond to it so we can schedule the meeting ASAP.
… Because of the lack of feedback so far I’m not comfortable in declaring a time for the next meeting. Let’s extend the deadline for response to that poll to the end of this week.
… We’ll schedule a meeting as soon as we have enough feedback.
… Please respond by the end of this week, the topic is to keep talking about the registries.
… Any questions on that?

1. DID resolution

Brent Zundel: Markus has volunteered to walk us through the current status of DID Resolution, so I will turn things over to him.

Markus Sabadello: https://docs.google.com/presentation/d/1Ccnbh_A53yzTyIIrw6ol_EakAliuo3MfxIFlGsaoKos/

Markus Sabadello: https://w3c-ccg.github.io/did-resolution/

Markus Sabadello: The first page shows two outlines, the current outline of the DID core spec on the left as it was restructured after the F2F. Part of that, those parts that are somehow related to DID Resolution and on the right side you see the current structure of the DID Resolution spec which isn’t happening in this group but as a work item of the CCG.
… The DID Resolution spec is not in scope for this group but there was consensus at the F2F that some pieces should be in scope for the DID core spec. Specifically, the contract (as Justin calls it) or the interface. When you have a DID/DID-URL what is the interface for what you can get, what makes resolution possible.
… There’s an overview of those two specs on that first slide. If you look through the items on the right side, Section 3 Resolving a DID, Section 4 Deferencing a DID URL. Resolution and Dereferencing are defined, but those are not protocols with client/server for example, but they are defined as abstract functions that can be realized in different ways.
… These first two sections 3 and 4 define the inputs and outputs and the algorithm for resolving and dereferencing. The section 5 talks about resolvers, etc. Do you access a DID method underlying storage directly or use an intermediary service, etc. Section 6 will change a bit involving the discussion around metadata for the data that is not in the DID Document.
… There is a structure about a DID resolution result for that, but it may change quite a bit.
… There is another section about an HTTP binding, if DIDs are deployed via HTTP services, etc.
… Privacy considerations, etc. as well.

Markus Sabadello: https://github.com/w3c/did-core/issues/198

Markus Sabadello: We have an issue in IRC.
… There was consensus at F2F to add some of DID Resolution into DID core. That’s what this issue is for. The sections in the DID core spec, 3.4 and section 10, they are empty or almost empty and they need to be filled.
… That’s what issue 198 is trying to do. So in the remaining slides in this presentation I came up with ideas for what the boundary could be and what we might want to include in DID core and so far what’s been in scope.
… If you look at slide 3, perhaps the functions that are defined in DID Resolution (resolving and dereferencing), what are the inputs and outputs could perhaps be moved into DID core. But the detailed algorithm could remain in the DID Resolution spec.
… That’s one idea. If you look at slide 4, there’s an open question because in the DID Resolution spec we define the “resolve” function, we also define, in DID core, the DID method operation, the READ operation, as it is required for each method and there’s a very close relationship between those things.
… On slide 5 and 6 there are some additional ideas on what content or topics could be considered in scope for DID core which have so far been in scope for DID Resolution. For example the architectures and the additional data structures, not just the DID Document.
… I’ll pause here and ask for questions.

Drummond Reed: Going through his slides it looks quite reasonable. What he’s proposing. I’ll pose this in terms of a question, we used “the contract” in Amsterdam. Is there a specific place where you’d see that contract described?

Markus Sabadello: That would be in the new section 10. That’s called “Resolution” and I think it would cover the inputs and outputs of the resolution function and the dereferencing function.
… For example, it would say, if you want to resolve something, resolution works by passing inputs a DID and options and the result would be a DID Document in one of the supported representations and metadata. Another would be for dereferencing, sending in a DID URL and options and getting back content type, metadata, some other things to discuss there.
… Open issues there, ongoing discussion on metadata and matrix parameters and things that will influence all of this. Defining the inputs and the outputs.
… The detailed implementation could remain in the DID Resolution specification or we could decide to pull it in here but I think we’d just have the interface here in DID core.

Drummond Reed: Yeah, I think the interface is the contract and that’s how I had been thinking about it, it sounds good to me.

Justin Richer: I just wanted to make the point that the nature of this contract is going to be at the same level as the rest of the DID Document, specification, it will describe the data structures that go in and out and not necessarily the syntax of those.
… Up to the point though where we have to describe the syntax of what the data structures are that need that. That’s where the content type comes in and stuff like that.

Markus Sabadello: Notes from last week’s DID Resolution call in the Credentials Community Group: https://github.com/w3c-ccg/meetings/tree/gh-pages/2020-03-05-did-resolution

Justin Richer: We had a conversation on the call last week for different approaches to that that will have to be wrapped in here, but when we say things like “options” we are saying that we will have a map between strings and other strings or strings and arrays or something like that that is simple and universal that can be used to describe what each of those parts are.
… It’s really important that that be nailed down in the DID core spec and that hasn’t been done yet.

Markus Sabadello: I agree.

Phil Archer: See My comment on matrix parameters

Phil Archer: I follows on from what Justin was saying. I find it increasingly dissonant that we aren’t making the DID Resolution spec part of the group. Especially with what’s being pulled into core per Markus. I think we should make that spec be part of our output, it makes DIDs more real, and testable. I’d like to see it part of the WG. I personally haven’t had time to look at the metadata issue but I will, it’s close to my heart.
… I did write out a comment on the matrix parameters issue which I did on github today. We have tackled similar problems at GS1 and from my point of view we don’t need matrix parameters.

Daniel Buchner: I just posted to that thread on matrix parameters, one of the most important things we can do is scope what they should and shouldn’t be used for. There should be a clear line. If you really care about this implementation, given what these matrix parameters are for … it can get ugly with URL parameters that would make them not work the way they usually do.

Markus Sabadello: https://github.com/w3c/did-core/issues/65

Markus Sabadello: These topics and issue could influence what we do, please take a look at them (in IRC).
… If there’s no objection I will probably try to put what I just presented into a concrete proposal with some initial content for the DID core specification that Justin and I already committed to.

Justin Richer: +1

Markus Sabadello: I just wanted to mention this and then move ahead with concrete text for the spec.

Dave Longley: +1

Brent Zundel: That sounds great.

2. Issues

Brent Zundel: Sorted according to how they were last updated, you should have the list. Hopefully you’ll be prepared to make some comments.
… The goal is for the person who the issue is assigned to to tell us what next steps are needed to move the issue forward, please don’t discuss the issues themselves.

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

Brent Zundel: I hope you’re ready Mike Jones.
… Use of terms defined in the specification should be linked to their definitions. Status update?

Michael Jones: This is just normal syntax hygiene for a W3C spec, I believe it should be assigned to one of the editors to do, it’s not rocket science.

Ganesh Annan: I can make a PR for this.

Michael Jones: Which editor is willing to do this?

Justin Richer: +1 it’s quick editorial stuff in respec, I think

Drummond Reed: I’m willing and go in and see. This obviously has been pending for a while throughout the entire spec.

Michael Jones: It’s global edit that just needs to be done. It will cause merge conflicts with everything, so it should be done at an appropriate time but an editor should be assigned to this.

Drummond Reed: Assign me right now.

Michael Jones: Ok.

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

Brent Zundel: “What are entityship and start-of-authority (SOA) problems?”

Michael Jones: This is one of the many cases of terminology used in the spec that is not well understood most people. I’m an expert in most identity topics and I still didn’t know what this was talking about. Whomever understands it should define it or I can volunteer to write a PR to remove it.

Brent Zundel: Anyone in the group who feels like they could more concretely define this terminology and would be willing to raise a PR for that?

Michael Jones: I will volunteer to write a PR to remove the unclear language.

Brent Zundel: I agree – that PR will be a good place for people to suggest changes on that PR.

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

Michael Jones: This isn’t testable, it shouldn’t be normative. Unless someone wants to own this, I’ll make the same gesture to remove the non-actionable language.

Brent Zundel: What about Amy’s suggestion to point to the Rubric?

Michael Jones: That’s fine but I would remove the normative language.

Drummond Reed: In your PR just make the language non-normative and point to the Rubric to take care of it.

Michael Jones: Ok.

Brent Zundel: If you can make comments on the issue for what will be done would be excellent.

Michael Jones: I’m doing that.

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

Brent Zundel: I figured you were, thank you.

Michael Jones: Amy writes that this is expanded using the abridged syntax. I don’t know what that does.
… When I clicked on it when I was filing these issues it didn’t do anything.
… I’m not proposing to remove this, I think someone should add a definition.

Amy Guy: selfissued: it expands the acronym on hover

Markus Sabadello: You can assign this to me, it’s relevant to resolution.

Michael Jones: We should have actual definitions in the terminology section. That’s clever but when someone prints the document it’s useless.

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

Michael Jones: This is not syntactic, it is semantic.

Brent Zundel: What do you feel this issue needs to move forward?

Michael Jones: I’d like the proponents of revoked keys to actually discuss this.
… A lot of these comments I was pointing out places where the spec says something that’s not actionable or not interoperable.
… This is one such issue. I can say I invite… I just got a comment from Orie that he’s not in favor of having revoked keys as well.

Daniel Buchner: I second that

Brent Zundel: Amy added a discuss label and I agree with that.

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

Michael Jones: I’ve gotten the sense on the registries calls that we’re agreeing to do this.

Brent Zundel: I think a comment to that effect would great and hopefully we can get feedback from the rest of the group.

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

Brent Zundel: Chair note: I hope Mike and the group doesn’t feel that Mike is getting picked on at all, I’m very grateful for this set of issues and that he’s read the spec closely and cared about its progress.
… I want that statement out there as we move forward.

Michael Jones: The text should be updated to make this clearer and I agree with Orie’s comment that we need examples. There should be examples. There should be examples with keys using JWK and I think it would help all of the engineers in the room, myself included, on how to reasonable this by looking at how the examples are written.
… I think the next step is an example using JWK.

Brent Zundel: Would you be willing to raise that PR?

Michael Jones: It’s already raised, I
… I’ll add a reference to it when I find it.

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

Brent Zundel: If there were a PR to add examples to the spec would that address 170 and 171?

Michael Jones: It would provide background for more concrete discussion of 170 and 171.

Brent Zundel: Do we have a volunteer to add some examples via PR to move these issues forward?

Jonathan Holt: I think Orie put an example and linked to it in the core registry. I think the issue is the conflict between id and kid and the centerpiece of this being pure JSON and JSON-LD and that we’re overloading the id.

Orie Steele: So, in the case where you have a key that’s not represented by JWK, you’re going to need some form of identifier for it. The identifier for a key that’s in a DID Document and the identifier for a key that may represent it in some external system – it’s helpful to have both.
… The links I’m including are examples for verification keys and there are JSON schemas for the JSON only and the JSON-LD definitions of them.
… As we are able to pick up the pace in the registries we’ll be able to provide better examples and we’ll need to link back to the spec for that.
… There is a note in the DID Core spec and there are links to the registries where the normative definitions are in the DID core spec. It’s an open question with whether the core key definitions are defined in DID core, we may not want to create normative definitions in DID core.

Brent Zundel: Thanks, Orie. Please summarize that comment in these issues, that would help the group.

Orie Steele: Related normative statements: https://github.com/w3c/did-core-registry/issues/9

Michael Jones: I’ll actually disagree with you on that point, Orie. On the key representation calls, and in the WG, we agreed that JWK would be supported for everything and some other types would be supported for some things. At the very least we have to define JWK in a normative fashion and everything else we have normative references to. We can’t just point to a community spec we have no control of.

Orie Steele: I agree with you mike :) we do need some of this stuff in core… not sure how much of it.

Michael Jones: There are examples in the core spec now but none of that use JWK even though it’s the one key format that we agreed to support across the board. That’s setting a bad example for developers.
… One idea is that we can take the example from the registries that Orie linked to and update the example in the core spec using it.

Brent Zundel: I personally think that is a fine suggestion.

Michael Jones: Who will do that?

Jonathan Holt: Is the id equivalent to the kid in the public key section? If I have to iterate through and find a key by ID, I’m struggling to understand how it would actually be performed.

Brent Zundel: You should raise that question and concern in issue 170.
… To help move that conversation forward.

Orie Steele: pubkicKey.id != kid for all key representations…. we still need to define all this stuff in core to make it clear.

Michael Jones: I will take the issue if I have to, but some of the rest of you may want to do it as well.
… I guess I’ll do so.

Brent Zundel: Thank you, Mike.

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

Brent Zundel: There’s a PR that exists that has been merged. Looks like Manu says there’s a couple more requests that may close the issue out.

Michael Jones: Ok, I think this is done.

Brent Zundel: Do the honors.

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

Michael Jones: There are comments that this may be method specific and that may be true but even if that’s true the core spec, in our list of requirements for method specifications, we should include that the method define what “updated” means to it.

Drummond Reed: I agree both with what Mike said and with what Joe just added about this being a metadata issue.

Michael Jones: I will add that comment to the issue. That doesn’t mean we’re done.

Brent Zundel: I think we need the clarifying text in the right place, that’s an important aspect of this issue.

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

Jonathan Holt: I remember discussing this a few months ago. The X.509 extensions give you the ability to add an ID field.
… You can leverage self-signed X.509 certificates with a DID.

Michael Jones: My read of this was different, I thought the author was talking about augmenting the ecosystem where DIDs were used instead of certificates. Which kind of makes my point.

Brent Zundel: That’s definitely an indication that we need more clarity around this.

Drummond Reed: I think this text is a hold over from some early versions of the spec that we simply wanted to point out that DIDs and DID Documents had a relationship with the existing PKI, which is largely X.509 based. Not defending the wording, just saying where it came from.
… As trying to enumerate the various security considerations we wanted people to understand that DID Documents could be an extension or augmentation to X.509 but we should reword what’s being communicated here. We do frequently get the question about the relationship between DIDs/existing PKI.
… So we should say something about that. I would volunteer to do that, but I would have to tap others as I’m not an X.509 expert.

Michael Jones: Do we have any way of knowing who wrote the text?

Brent Zundel: git blame.

Amy Guy: I think the text is gone.

Michael Jones: I agree that it’s gone, I’m happy to close on that basis.

Brent Zundel: Thanks for coming, we’ll keep suffering with Daylight Saving madness, keep working in github.