Decentralized Identifier Working Group, Special Topic Call — Minutes

Date: 2020-05-12

See also the Agenda and the IRC Log

Attendees

Present: Michael Jones, Brent Zundel, Dave Longley, Tobias Looker, Drummond Reed, Daniel Burnett, Manu Sporny, Kyle Den Hartog, Orie Steele, Kaliya Young, Tim Cappalli, Jonathan Holt

Regrets: Amy Guy

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley, Brent Zundel

Content:

Brent Zundel: The editors of the DID Registries document are Orie and Manu … I’m going to turn things over to them.

Manu Sporny: This special topic call is in general on the DID registries document.
… I think one of the things we might want to get approval for is the name. Drummond came up with a name that we like.

Drummond Reed: DID Specification Registries

Manu Sporny: The main point of this discussion is to give everyone an update on where the registries are headed and some key decisions we need to make primarily summarized by Amy. She sent an email earlier today to the DID WG mailing list on three proposals to consider.
… It really has to do with organizational stuff and making it easier for people to contribute.

Brent Zundel: Amy’s email: https://lists.w3.org/Archives/Public/public-did-wg/2020May/0006.html

Manu Sporny: Orie, Amy, and I have been talking across multiple issues and then we got together earlier this week to put together a concrete proposal for helping all the communities involved, JSON-LD/JSON/CBOR/etc.
… Topic should be about that. There are three main questions to explore.
… First is: Where do we put properties that are not a part of did-core. These are the things like “proofPurpose”, assertionMethod, stuff in LD signature suites – things that are broadly used but not really defined in did-core. So where’s that line?
… Where is the did-core line and what is non-core?
… So we want to show how you do an extension, Orie has put a couple of those together. The publicKeyHex and ethereumAddress stuff are good examples of exploring extensions.
… And then we’ve been trying to talk about how to do versioning like, is there an extensions JSON-LD context, how do you pull that in, how do people use it. This has created a lot of conversation recently. We think the current mechanism is too complex to adopt for both JSON only and JSON-LD folks. So we have another proposal.
… Just to review, 1. what’s in core? 2. what’s an extension? 3. do we really want an extensions [single?] JSON-LD context?

Kyle Den Hartog: Question regarding the contexts, are we considering other formats as well in that regard? What’s your thoughts about json schema?

Manu Sporny: We’ll definitely be discussing it.

Orie Steele: The thing I will say is that in the initial conversations before registries discussion, I proposed json schema for JSON only folks. There was some back and forth. Mike Jones wasn’t completely opposed but wasn’t in favor. I wanted to show how it would look, but having done that I think it’s a terrible idea.
… I would now oppose it. I have things to say about it when we get there. But I think we should go through it in the order of Amy’s email.

Michael Jones: If we have to update a version identifier each time something is added to a registry, that’s a management and organization failure. The point is that stuff in a registry should be mix-matchable at your will.

Manu Sporny: Yes, I think that’s the direction you’ll see we’re headed in. We want to enable mix-matching like that.
… Orie, don’t know if you have a preference on how to discuss this – maybe we want to paint a broad brush picture … how would you like to take this?
… We could go through the way Amy has stated it and discuss things as they come up – your preference, Orie?

Orie Steele: My default preferences is to take them in the topic order and can jump around as needed.

Manu Sporny: Yes, let’s do that and can explain more as needed.

Summary: The DID Spec has some properties in it that are not common to all DID methods. The DID core json-ld context has even more terms in it that are neither defined in the spec, nor common to all DID methods. (Manu Sporny)

Manu Sporny: I will copy from Amy’s email.
… I’m just putting it in IRC.

Brent Zundel: amy’s email: https://lists.w3.org/Archives/Public/public-did-wg/2020May/0006.html

Manu Sporny: The first thing, there are things that are in the current JSON-LD context that aren’t in did-core that are from things like the security vocab and other places on the internet.

Orie Steele: Take a look at https://w3c.github.io/did-core-registries/ it has a lot of things in “core” that I think many people might argue are not “core”.

Manu Sporny: The argument is that those other things that are LD sec style things, should be like any other extension. The only thing in the JSON-LD context and specifically in the DID specifications registries document in the did-core section should be the stuff in the DID core spec, everything else is an extension.
… It feels workable, the only concern there is that – we haven’t chatted with Dave Longley but were wondering if that would blow anything up.
… The idea here is that for JSON-only systems, you can mix and match from the DID registries document however you wish. You can pick and choose what you want to use and you’re fine.
… For the JSON-LD folks, you will have two contexts, the first will be the DID core context. Then you will have your DID method context layered on top. For DID documents, you’ll have two contexts, DID context and your DID method. You’ll mix and match things from the registry in your DID method context.
… So just like the JSON only folks you can mix and match how you want. If you want to use publicKeyHex that goes in your JSON-LD context for your DID method.
… You can mix and match whether you’re in JSON-only, JSON-LD, CBOR/CBOR-LD, you can look at the registry and mix and match from there and there’s a mechanism that’s defined.

Orie Steele: Example of the 2 contexts used by did:elem and likely did:ion will do something similar: https://uniresolver.io/1.0/identifiers/did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg

Michael Jones: I’m mostly here to listen to hear what all of you smart people who are working on this have done. But I will say that when you organize a registry, the principle isn’t about whether it came from the did-core document or if it’s a field of the same kind that can be used together.

Orie Steele: Another example of 2 contexts: https://uniresolver.io/1.0/identifiers/did:v1:test:nym:z6MkmbrHuhkzwWYeJjkBhTYktabXR22ECzk1WrHJPW69EsJY

Michael Jones: For instance, there’re going to be some names that we can define/that can occur as top-level JSON elements in a DID Document. Some of those will come from the did-core spec v1 and some will come from some other places. If they are top-level names in a JSON document they should all go in the same registry.

Tobias Looker: Yeah, so I had a quick question around the JSON-LD extension. So methods would not extend the base context – there’s just a single one. Is there any commentary around whether the base fetches will be protected so they can’t be overwritten?

Manu Sporny: To address the extension question, the idea here is that just like in the VC data model, you have a base DID core context and those terms will be protected, you can’t overwrite those terms. You can’t change the meaning of any of the base values in DID core. That shouldn’t come as a surprise to anyone, that’s expected behavior.
… The way you do extend though is that you add another context. As long as you don’t override the base things you can add whatever you want to in your second “DID method” context. This doesn’t prevent anyone from extending as they see fit.

Jonathan Holt: The challenge I ran into, writing the CDDL for the base data model in CBOR. Ultimately I had to put in proof any, *tstring:any because I can’t extend/test for any of these extensions. This open world model is kind of a free-for-all.
… I understand the need for handling this with the registries. I started using the semantic tags, the context for JOSE signatures and I can tag that and make it semantically concrete and binary. For the most part with the CBOR I will bypass using any registries.
… As unneeded.

Orie Steele: I put some examples of DID documents that have two contexts today and the main point around this first bit is that there are things that are defined in did-core and there are things your DID method might define that matter to you.
… If you work with ethereum and want ethereumAddress in your context you should add that to the registry and update your context to get that feature.
… If you want interop with different people … each DID method should manage their own extensions. If two DID methods want to support each other they should update their contexts to make that happen where they share something in a registry.
… This may be different from people who were looking to add 3-4 JSON-LD contexts at the top. Jamming did-core with all of the things that we need for interoperability also won’t work because we can’t agree on all properties.
… We can agree on a small subset here.

Manu Sporny: I wanted to respond really quickly to Mike’s concern that typically a registry is .. you just specify items that can be used together or are related. One of the questions that kept coming up. Effectively, this idea that some of these properties are getting special treatment and are getting into the core JSON-LD context when they aren’t a part of did-core.
… This proposal is to address that. The only stuff that goes into the core JSON-LD context is the stuff that is needed for the most basic interop. For the DID core spec. There is going to be a section in the spec that says “these properties come from DID core”. Some would argue that we don’t need to say that but because we’ve had so many arguments over it we do.
… Then we point off at specs for other extensions. This proposal is about saying that the things that go into the did-core JSON-LD context are just the things that we define in DID core. Nothing else. Everything else has to be put into a DID method context if you’re using JSON-LD. The other formats don’t really care this particular decision that’s being made.
… Mike, you make a good point, but the issue here is that people keep arguing over what’s in core/what isn’t in the context. If it’s in did-core spec it’s in the core context, otherwise it isn’t, full stop.

Michael Jones: I wanted to respond to two things. I mostly trying to listen.
… There’s going to be a bunch of stuff that’s shared between DID methods that doesn’t come from core. For instance. Let’s presume that there’s going to be a verification method’s registry or public key types registry.
… Let’s say that publicKeyHex is not defined by DID core but maybe five different methods might use it and there should be one extension that defines that thing and they all reference it. We shouldn’t force it to be DID method specific.

Drummond Reed: +1 to extensions not needing to be DID-method specific.

Michael Jones: The other thing – every entry simply has a pointer to the document that defines it. The stuff from did-core therefore isn’t different. You just point to them and you use them if you want to. I understand the context thing makes this devilishly difficult, but for JSON and CBOR it shouldn’t be.

Manu Sporny: I think we’re doing just that.

Michael Jones: Ok, I’ll try to stop speaking and listen.

Orie Steele: we are doing what you said :)

Manu Sporny: I don’t think you said anything that goes against what’s being proposed.

Michael Jones: Great.

Drummond Reed: I wanted to reinforce the notion that DID methods might want to define extensions, that’s fine, but there’s nothing that needs to couple an extension with a DID method. There can be an extension that dozens of methods want to use.
… Just wanted to make sure that was clear. Some extensions might be very specific to a DID method, but others might not – we need to support both classes.

Manu Sporny: Yes, I think that’s exactly what we’re about to do if these proposals pass. Multiple DID methods can share one extension, no problem.
… I think we’ve found a way to do this cleanly.

Orie Steele: “DID Specification Registries v1.0”

Manu Sporny: The registries document is currently called “DID Core Registries” and people still had heartburn over that. And Drummond said let’s use “DID Specification Registries v1.0”
… And the editors liked that.

Orie Steele: holds core, extensions, parameters and methods

Manu Sporny: So feel free to object to this if you want, but let’s not bikeshed right now. I will put in a proposal.

Proposed resolution: Rename the “DID Core Registries” document to “DID Specification Registries”. (Manu Sporny)

Orie Steele: +1

Manu Sporny: +1

Drummond Reed: +1

Kyle Den Hartog: +1

Tobias Looker: +1

Dave Longley: +0

Jonathan Holt: 0

Michael Jones: -1

Michael Jones: First, what happened to calling it “DID Registries” and the second thing, there should not be a version number.

Orie Steele: DID Registries is ambiguous. This holds three separate things. This holds DID methods, core properties, extensions, and DID parameters.

Michael Jones: All of which are part of using DIDs. The word specifications doesn’t add anything.

Jonathan Holt: I question the need for registries vs. just specifying it in the spec. As we update the versions of the specifications we can update those attributes.

Brent Zundel: The working group talked long and hard and decided registries are important, don’t want to rehash.

Jonathan Holt: If it’s going to be falling on DID methods to do the extension that aren’t shared then it seems like a smaller set.

Drummond Reed: The way in which this document gets extended and added to do and what it defines is really W3C best practice to have a separate document defining registries.
… I favor sticking with the decision from Amsterdam to have a separate document.
… To respond to Mike the term “DID Registries” is now defined as the place where DIDs are registered. So that’s ambiguous. But we are looking at changing that name too.
… But this still leaves open the ambiguity around “the place where you go to register DIDs”.

Michael Jones: There’s an issue that has a lot of support that we need to change that name and the fact that it’s a historic name shouldn’t block us from using a simple name for the set of registries.
… Also, I think it’s Kyle that I’m going to respond to. That said there are three different kinds of things… from core, extensions, etc. This has to go back to my point that where things came from shouldn’t be the organizing principle. The public key types, the core might define some, some other docs might define them. But they are mixed into the same registry so you can find this stuff.
… Based on the same type. This is exactly so we can do parallel extension from unrelated parties and we only do registration to get consistency/interop.

Manu Sporny: Mike, I can take up your proposal as a counter proposal and work it that way.
… So we can see where there is less objection.

Proposed resolution: Rename the “DID Core Registries” document to “DID Registries”. (Manu Sporny)

Michael Jones: +1

Jonathan Holt: 0

Manu Sporny: -1

Drummond Reed: -1 because of the semantic confusion issues i raised

Orie Steele: -1

Kyle Den Hartog: +0

Dave Longley: -1 unfortunately too confusing at this time

Daniel Burnett: +0

Brent Zundel: 0

Tobias Looker: 0

Manu Sporny: If you have an opinion please put it into chat, we have 12 people but not everyone voting.

Kaliya Young: just make it clear?

Jonathan Holt: do we have a running list of items that need to find a home in a “registry”?

Michael Jones: The string that was typed into the chat included v1.0, we absolutely should not have version numbers in the registries. The registries get updated in parallel and you don’t want to have to update a version number everytime. I can’t live with the version number.

Manu Sporny: We don’t need to make that decision now, I agree with you, Mike, more than likely we will do exactly what you say. The W3C spec process requires a version number right now.
… The process is being updated to remove that.
… As a result I think we will end up where you want us to be, but we will defer to the W3C master process on that. We will use the proposal that was put into IRC that does not have a version number in there.

Daniel Burnett: Quick reminder that these resolutions are just straw polls, as these topic calls are not official decision-making DID WG calls. But they are good at figuring out what there is support for.

Manu Sporny: I’m going to rename the document to “DID Specification Registries”

Resolution #1: Rename the “DID Core Registries” document to “DID Specification Registries”.

Proposed resolution: Define a section of the “DID Specification Registries” that contains “DID Core” properties section, and every other property is an extension. (Manu Sporny)

Michael Jones: -1

Orie Steele: +1

Manu Sporny: +1

Kyle Den Hartog: +0

Drummond Reed: +1

Jonathan Holt: 0

Tobias Looker: 0

Dave Longley: +0 (could just see the document it comes from)

Orie Steele: this is needed for developer usability

Michael Jones: You group by type not by origin. It doesn’t matter that they came from the core, that’s why registries work.

Drummond Reed: Mike has a point. Revising my vote to 0

Kyle Den Hartog: I find that as somewhat of a strong argument. I find that quite useful – having some stuff registered by the WebCrypto WG and some by the JOSE WG made it far easier for me to understand what is the superset of everything rather than having to parse different sections.
… As a user of the registries I find it useful to have them grouped like that.

Drummond Reed: If each registry entry references its source, that’s helpful, but Mike has a point for the registry itself to group them by type.

Orie Steele: https://w3c.github.io/did-core-registries/#created-1

Jonathan Holt: yeah! Thank you!

Michael Jones: As another example that we all care about. I’m registering secp256k1 from a new document that didn’t start out in the JWA doc, it appears and is on par with the other algorithms in the algorithms registry.

Orie Steele: I think the thing I’m having trouble understanding is – what is the logical grouping that applies to the properties that are being registered here. In the JOSE case we have signatures/keys/etc. these sections that are split out. In the case of extensions being added to the registry, you can add an extension to anything.

Kyle Den Hartog: noting for the minutes. While I find Mike’s argument a good point, I’ll get used to working with it as it’s decided hence my original +0

Orie Steele: You can add arbitrary properties. As a developer, trying to build a DID method based on the DID core specification, it’s helpful for me to know what’s in did core and then see the extensions section that isn’t in DID core and it’s maybe experimental for interoperability, that kind of thing.

Manu Sporny: I feel like we’re getting wrapped around the axle and we’re not going to end. And we haven’t gotten to the important decisions we need to make.

Kyle Den Hartog: +1 let’s move on to the deeper issues

Manu Sporny: I feel like we’re stuck at this point on this topic. I’d like to put a pin in this and move to something else. This could be viewed as an editorial thing and we can just let the editors take a shot at organizing this instead of involving the WG.
… We need to get to the real meat of the discussion in the last 15 minutes we have.

Michael Jones: It’s not editorial.

Jonathan Holt: This is very important.

Tobias Looker: Doesn’t each entry in the registry indicate where it was defined?

Michael Jones: To Orie’s point, an extension can register a bunch of stuff. It could register a public key type, a service type, a top-level element name. It might register a DID method name. It’s great. The little thing at the right edge of the document lets you tell where it was defined. You still sort things into tables of that kind.

Justin Richer: +1 it’s not editorial, this is fundamental structure – but other questions are important to talk to

Orie Steele: What kind of thing is an ethereumAddress?

Michael Jones: That’s a separate thing, but no matter where it is defined it goes into the same group.

Kyle Den Hartog: I see it as purely editorial because the HTML can sort things how I want.

Manu Sporny: I wanted to second what Kyle said. Here’s the reason it’s editorial. It doesn’t matter where in the document where they exist, they are all valid. They are at the same layer. We’re talking about how to group these things in the document and that’s important.
… But there are potential philosophical arguments about whether ethereumAddress and publicKeyHex should be grouped together in the same area or not. If people feel it’s not editorial we can talk about it. If folks feel it’s not, it would be good to understand why it’s not.
… There is no normative implementation difference based on how you group things together in the registries document.

Brent Zundel: Maybe I’m off here. On one hand we’re talking about a document about how things get into a registry and how those things are organized, meta stuff. On the other hand we have the registries themselves and maybe sometimes we’re conflating the two.

Michael Jones: The reason it’s not editorial is that it is semantic. Each registry has its own schema. The fields in the table for the registry are different for different things. The fields for top-level element names are different from the fields for DID method names or public key types. Each database table has its own schema and you group things with the same schema so they go into the same table.

Drummond Reed: +1 to each database table having its own schema in the registries document

Michael Jones: That way developers can easily find stuff, if they have to search all around the document we’re not helping them.

Manu Sporny: Again, Mike, folks are talking past each other. I don’t think folks are disagreeing with that. I think there’s agreement to group like things together.

Orie Steele: kind

Orie Steele: unless we are to debate type theory

Proposed resolution: Group items that are of the same kind together in the DID Specification Registries. (Manu Sporny)

Michael Jones: +1

Drummond Reed: +1

Orie Steele: +1

Manu Sporny: +1

Kyle Den Hartog: +1

Dave Longley: +1

Justin Richer: +1

Tobias Looker: +1

Brent Zundel: +1

Resolution #2: Group items that are of the same kind together in the DID Specification Registries.

Kaliya Young: woohoo

Dave Longley: i think there’s also agreement to indicate origin.

Drummond Reed: Yes!

Drummond Reed: That was a +1 to @dlongley suggesting that there was also agreement to indicate the origin or source of the entry.

Manu Sporny: There had been a proposal to have a JSON-LD extensions context that had all extensions in it and then to bump the version for that as new things were added or on a timeline.

Manu Sporny: The new proposal is to not have a kitchen sink context like that and what we’re suggesting instead is for DID method implementers to make their own contexts.
… They can create a JSON schema/write code to enforce it, etc. The basic suggestion is the elimination of this JSON-LD context that just contains every single extension in one context.

Kyle Den Hartog: I’m of two minds on this. I hate the idea of a kitchen sink approach. The advantage from the implementation perspective is that I can type against it.
… I can do that once in my implementation and not do it often – and anything that’s in that I should be expecting. From an implementer’s perspective I prefer kitchen sink, from a registration point of view.

Dave Longley: i feel like that what is about to be proposed swings too far in the opposite direction
… I want to be able to set up a did resolver that says I support ABC, and know I’m getting something that I understand. Perhaps a did context shouldn’t always be method specific
… but rather we could have some commonly grouped features in did contexts

Tobias Looker: Yeah, I just wanted to raise the question around the kitchen sink one. If I’m intending to use JSON-LD tooling passed the kitchen sink – I still think it would be useful, if you’re going to infer a context you inject into the document and using a kitchen sink context there might be the only option.

Orie Steele: The key to not rely on a kitchen sink context is that it doesn’t prevent people from coordinating around a common vocabulary. It just makes it not the burden of a single group. I think it’s impractical, technically, to have a kitchen sink context based on observed behavior.

Drummond Reed: This is a hard problem – I have to ask the question. Is it actually … if the registry lists everything it has to list … is context packaging the job of implementers or us?

Orie Steele: If we do the kitchen sink approach we’ll be responsible for maintaining it.

Drummond Reed: The kitchen sink approach seems like the only one this group could possibly maintain, there are too many possible other cominations and we can’t be responsible for all of those.

Proposed resolution: Eliminate the need for a JSON-LD Extensions “kitchen sink” context, DID Method implementers will pick and choose which properties they want to include in their DID Method-specific JSON-LD Context or a shared context between communities. (Manu Sporny)

Dave Longley: +1

Orie Steele: +1

Drummond Reed: +1

Michael Jones: 0

Manu Sporny: +1

Kyle Den Hartog: +1

Tobias Looker: +1

Brent Zundel: 0

Jonathan Holt: 0

Justin Richer: 0

Kyle Den Hartog: Yipee! it’s resolved

Resolution #3: Eliminate the need for a JSON-LD Extensions “kitchen sink” context, DID Method implementers will pick and choose which properties they want to include in their DID Method-specific JSON-LD Context or a shared context between communities.

Manu Sporny: This will help us make a ton of progress. If people don’t like what they are seeing we can always revisit this.

Michael Jones: Thanks all

Drummond Reed: Good ending point

1. Resolutions