DID WG Topic Call on did spec registries — Minutes

Date: 2021-03-11

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Charles Lehner, Brent Zundel, Markus Sabadello, Amy Guy, Ted Thibodeau Jr., Manu Sporny, Jonathan Holt, Drummond Reed, Orie Steele

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Charles Lehner

Content:

1. DID Spec registries

Brent Zundel: my role to run the queue, encourage civility (rarely have need of that).
… add yourself to the q, and let’s get this meeting started.
… will Orie make it?

Manu Sporny: unsure. ideal if he is here. texting him
… will be right back.
… sent him something. i can try to start a discussion.
… just listing things we need to discuss: one is waiting for us to provide feedback: the did3 did method

2. registration of did:3 method

See github issue did-spec-registries#260.

Manu Sporny: the DID Core spec allows this (single-char DID methods).
… there is mention about being concerned about this kind of stuff
… their response is they shipped it; it needs to be in
… are we going to restrict methods to be at least 2? characters?

Brent Zundel: Topic 1: possible constraints on DID method length

Ivan Herman: not that i like this did:3, but do we want to get into a normative change in the core spec, and reissue a CR? (not published yet, but right after)
… this is a normative change in the core spec. it allows to have one-character method name.

Brent Zundel: +1 to needing to change core spec in order to say no here

Markus Sabadello: i don’t think anyone is suggesting a change to the DID Core spec to change the normative syntax of what is allowed or not. but there is a difference of what is allowed in the syntax and what is the policy on what is allowed in method names

Orie Steele: There MIGHT be a difference, if the registry refused to accept conformant DIDs…

Markus Sabadello: it could be to not change core spec, their did method would continue to function and be compliant, but doesn’t mean it has to be accepted and listed in the registries

Drummond Reed: +1 to Markus’s point

Markus Sabadello: registries meant to help with interoperability, discoverability, etc., but no hard requirement to use it.

Manu Sporny: agreeing with markus. might be talking about a process change to the registries process. strongly advise to use more than one character. registry may/will not list methods with single-characters. but grandfather in did:3. proposal to modify process

Brent Zundel: have to get did:z written fast

Drummond Reed: speaking from direct experience in another namespace. what we saw: single-char methods splattered on fast.
… we strongly rued the fact that we had not set that policy. i was dismayed to find out about did:3

Amy Guy: it does take quite a lot of work to squat a did method

Drummond Reed: just the fact that is out there - i would like to see documentation that it was/is actually in use
… could see that if they provide strong enough evidence, we could allow it
… strongly feel we should set the policy. interestingly enough, ivan, i wasn’t even thinking of changing the ABNF. since it would strictly be a registry policy.

Amy Guy: +1 TallTed

Ted Thibodeau Jr.: i don’t think we want to discourage people from registering their methods, because that will just encourage collision. it will be easy for other people to do another did:3, and then how do they resolve.

Amy Guy: which is worse? squatting or collisions?

Orie Steele: strong agreement

Ted Thibodeau Jr.: there are just too many problems that arise here. we want every did method to be registered. unfortunately, we can’t care whether they have single char.

Drummond Reed: I strongly disagree with Ted on this point.

Ted Thibodeau Jr.: to ensure the integrity of the system. discouraged to hear otherwise

Jonathan Holt: don’t see why it matters, one char, two, chars. don’t think is policy needing to be enforced

Manu Sporny: sounds like we are a bit split on this and maybe shouldn’t tie up a bunch of time talking about. have more important things to discuss. i can’t think of a proposal at this point that would pass.

Proposed resolution: accept any attempt to register a conformant method on a first come first serve basis (Orie Steele)

Manu Sporny: seeing objection to limiting it. i think everyone agrees we want people to register their methods.
… sounds like we should convince people to register their methods

Orie Steele: this ship sailed when we allowed DID Methods to be one character long and be valid. if not changing in core spec, i can’t see attempt to block registering conformant did methods on a first-come first-serve basis. either create tremendous bias or allow existing methods to forever have higher ground. did:3 only single-char method: terrible. same for 2-char or other limits. strongly object to blocking registration of methods conforming.

Orie Steele: must allow them. there will be a mad dash. welcome to managing a namespace.

Orie Steele: why discourage a thing that literally everyone will want… everyone wants short names….

Markus Sabadello: like manu’s idea to allow this one, not prohibiting, but make a strong warning discouraging them
… regarding opinion must use registry to avoid collision: not how it sohuld be. we should not consider the registry something that must be used. in charter, DID implementations must work without relying on a single registry
… registry is utility making certain things easier, but DIDs, DID resolution and the ecosystem must also function if you don’t use the registry.

Brent Zundel: could we work it into the reg process to require evidence that they are not just name-squatting?

Amy Guy: what brent said is already in the process isn’t it? I thought they needed to be fully spec’d at least

Brent Zundel: +1 to running Orie’s proposal

Drummond Reed: will wait until after proposal

Brent Zundel: anyone want to suggest modifications to proposal before formally running it?

Amy Guy: +1 drummond… there are other things about trademarks, offensive language, etc aren’t there

Drummond Reed: maybe now reading it i’ll reverse myself. maybe should have rest of call about what are going to be the policies to follow here. first come first serve: very basic, makes sense. but if don’t look at in conjunction with rest of policies to apply. assuming Orie’s not talking about everything going in, should look at other policies to apply.
… almost feels dangerous to start there. really need to look at the full body of policies

Manu Sporny: https://w3c.github.io/did-spec-registries/#the-registration-process

Drummond Reed: need to discuss not just each one individually, but all together. as said, welcome to managing a NS.
… like the president of IBM saying would not be more than 3 computers. i thought there wouldn’t be more than a dozen DID methods

Proposed resolution: accept any attempt to register a conformant method on a first come first serve basis (Brent Zundel)

Orie Steele: +1

Manu Sporny: +0.6

Drummond Reed: -1

Ivan Herman: 0.9

Jonathan Holt: 0

Brent Zundel: 0

Drummond Reed: the reason being that it’s not specific enough yet

Ted Thibodeau Jr.: +0.75 I think we’re rather painted into a corner

Amy Guy: -1 without caveat about other registration policies also being met

Manu Sporny: cel: abstain

Markus Sabadello: 0 we have that already, we need to talk about policies, not order

Brent Zundel: we have underwhelming support plus a couple -1s.

Manu Sporny: remind everyone we have a process. it has been edited a number of times. that is the process, you have to do all those things. a number of MUSTs and MUST NOTs

Amy Guy: +1 if meeting the rest of the process is implicit

Amy Guy: +1 then

Manu Sporny: only thing we are talking about is that you must… difficult to find wording for this, want to abandon and more on. supposed to be a softball one while waited for Orie to join. sounds like people feel strongly about this. let’s come back to it later
… i don’t think there is any real way we can stop. let’s look at immediate decision: are we going to stop did:3 from being registered? i don’t think so. there is proof they have been using it. i don’t think we can stop it. suggestion is to let PR 260 to go through, as no variation would prevent them to be registered

Drummond Reed: but they did not register it with the then-registry, correct?

Manu Sporny: can come back to do we want a policy to restrict this stuff
… proposal to allow PR 260, did:3 to be registered

Brent Zundel: if anyone would like to speak out in opposition, add to q

Orie Steele: or block it

Ivan Herman: going a bit further, i don’t think there is any reason why we would not register that one. but once we do that, we have created a precedent. no real reason to allow this one and not something else. sort of too late. should forget about this question altogether
… There may be some other discussions about the registration policy more generally, probably more important ones.

Orie Steele: +1 to ivan… there is no way to kick this can

Ted Thibodeau Jr.: there was some statement that because DIDs should not be reliant on any central registry, there should not be reliance on this registry. i think registering methods is different from registering DIDs per-se.
… part of the point of registering the method is so that people […] can figure out which one satisfies their needs.

Markus Sabadello: https://www.w3.org/2019/09/did-wg-charter.html - “These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, …”

Drummond Reed: I’m afraid that is true - and sad - but I will point out that the did:3 people did not actually register with the then-registry…

Ted Thibodeau Jr.: not the same as reliance on a centralized registry that we try to prevent.

Proposed resolution: Allow did:3 to be registered in the DID Spec Registries – pull in PR 260. (Manu Sporny)

Orie Steele: +1

Brent Zundel: manu dropped draft proposal

Amy Guy: +1

Manu Sporny: +1

Brent Zundel: +1

Ivan Herman: +1

Jonathan Holt: +1

Markus Sabadello: +0.5

Drummond Reed: 0

Ted Thibodeau Jr.: +1

Charles Lehner: 0

Resolution #1: Allow did:3 to be registered in the DID Spec Registries – pull in PR 260.

3. Registration process details

See github issue did-spec-registries#264.

Manu Sporny: Orie, what do you feel is the next big set of decisions we need to make? i know there is one around the process. there is the new CDDL requirement.

Manu Sporny: The Registration Process currently states: “Properties defined in the DID Core Registries MUST include a Concise Data Definition Language (CDDL) [RFC8610] of the Property and its Abstract Data Model structure.”

Manu Sporny: ^ that got in a while ago. now to register things, we require you to do a JSON-LD context and CDDL. we don’t say anything about JSON Schema. My concern is that there are many more people who know JSON Schema than CDDL.
… do we even want to require CDDL. anything higher priority?

Orie Steele: i don’t think so; that is the biggest one
… This issue comes up as we think about why do we register things. we register things because we want interoperability, to see it is registered, so that people don’t invent new ways of doing the same thing. we want people to register stuff so they don’t do slight variations of the same functionality. massively redundant. if difficult, they won’t do it.
… The purpose of registration is to help with the representations. because we have multiple representations. we needed a way to register things so we could see how your new registered feature works with those representations
… JSON-LD context is not helpful for representations other than JSON-LD
… problem where we can make the bar increase for each representation. increase the number of examples required
… would block people from registering anything
… if don’t want people to register stuff, asking them to support all representations in their registrations is a good way. problem since beginning of WG, need to address it.
… Proposal: for every registered representation that is defined in the core representation, you must provide some evidence to show that new properties work. only need to require examples. structural. non-core representations not required to support.
… willing to hear other proposals

Brent Zundel: can you give us the headline of the topic and we will come back to it

Ivan Herman: want to separate two things. i think i understand and agree with what Orie said. for rep not defined in core spec, we sort of put them aside in terms of the reg process. question: how high is the bar today, and will it become a problem that any new properties that i introduce requires me to have JSON-LD and CDDL (and JSON Schema?) to become a registration? see reason, to give interoperability, but don’t know if this will become an obstacle for people to register properties.

Manu Sporny: https://w3c.github.io/did-spec-registries/#controller

Manu Sporny: looking at the registries right now. for every property, we have three properties. the normative definition. strongly defensible. where do you define it. makes sense.
… JSON-LD context: kind of makes sense. nice to have a context. but JSON folks might not really care. an argument for that.
… where the WG got to is that they are so class, might as well have it
… when it comes to schema languages: they are largely representation-specific. if have a json schema, say DIDs must be strings. if you try to apply against a CBOR-LD encoded DID document, it would fail. because CBOR-LD does semantic compression. would not pass CDDL for pure CBOR.
… now into a position where we are saying that people have to provide schema checks against potentially every representation - at least the ones they care about. that is a very high bar
… number of people who can right JSON-LD: less than JSON. CDDL: even less
… My argument to not include any schema checking in the registries. that’s not their purpose. in the registration, could have a see also section where people can list the schemas. or have it associated with the normative definition. purely optional, not required for registration
… because we are trying to get people to register stuff. low bar.

Orie Steele: +1 manu

Drummond Reed: i want to second the idea of both orie and manu that a registration should supply the appropriate schema
… to support representations should supply the necessary detail in the associatd spec. must have spec and it must meet certain requirements. but agree it shouldn’t be a requirement to produce a mapping that you have no interest in. should be encouraged.

Manu Sporny: +1 to what Drummond just said.

Orie Steele: +1

Jonathan Holt: to tote benefits of CDDL. too much credit that i learned it overnight, it’s not that hard. it is a concise data definition language. json schema version 7 still draft. not normative yet. CDDL is a normatively described extension of ABNF rules. can right ABNF in CDDL. phenomenally expressive, and normative.
… I understand the bar. having written JSON Schema for the VC spec, chasing my tail, it was moving so quickly, to figure out what was in or not in. JSON Schema was not the right approach there.
… CDDL a superset of JSON
… both JSON-LD as well as CBOR-LD are an expansion algorithm. taking the external dictionary of CBOR-LD, expanding it as you would in JSON-LD
… get an RDF expansion. that is what needs to be modelled

Drummond Reed: Just to be clear, I am a big CDDL fan. I just don’t think we need to require all new registry entries to provide mappings to all representations. We need to encourage that.

Jonathan Holt: substitute the external dictionary, to get the same #1 means controller in the registry
… how to get the expressivity of the registry

Manu Sporny: Agree, CDDL is great – if you have a community that knows how to use it and a representation that uses it – we’re not in that position.

Markus Sabadello: +1 to ivan

Ivan Herman: first of all, to react directly to what jonathan said. i don’t think the issue here is whether CDDL is a good thing or bad thing. i think it is a good thing. but that is a different point. in the registry, the big difference between the context and JSON-LD is that for JSON-LD to work with a given property, you must have a way to say that this property maps onto that URL, because this is what JSON-LD context is all about. essentially the only thing it does is tell you what thing maps to what URL.

Amy Guy: +1 to ivan.. context is for semantic interop, not schema validation

Orie Steele: +1 ivan

Ivan Herman: all the other things are good things to have, help implementors. good citizen may want to do that as part of specification of property. but there have to draw line at what we require, and what recommend for good citizens to do

Manu Sporny: +1 to what Ivan just said.

Drummond Reed: It is true that we agreed in Amsterdam that a JSON-LD context must be provided.

Markus Sabadello: +1. also what we said when decided to introduce the ADM and different representations, i thought that was the reason we had the resolution to introduce those things at the same time, and any newly registered property must provide a JSON-LD context, for the reasons ivan mentioned.

Drummond Reed: i do think ivan has a good point. it also feels to me like the lightest of all the requirements, to just make sure that there is a mapping to unambiguous URLs for anything being proposed.
… want to ask, is that a proposal we are making here?
… asking for clarification. thought ivan was saying should still have JSON-LD requirement

Ivan Herman: JSON-LD is not a schema language

Drummond Reed: ok

Ivan Herman: that is the mistake that was done in earlier discussion. schema language is shacl or shex for rdf, not the context file

Drummond Reed: want to make modification that we encourage authors to do that

Proposed resolution: Remove the requirement in DID Spec Registries process to register any schema language (e.g., JSON Schema, SHACL, SHeX, CDDL) as a part of property registrations. The process will encourage providing schema languages for appropriate representations. (Manu Sporny)

Orie Steele: +1

Ivan Herman: +1

Drummond Reed: +1

Ted Thibodeau Jr.: +1

Amy Guy: +1

Charles Lehner: +1

Brent Zundel: +1

Manu Sporny: +1

Markus Sabadello: +1

Amy Guy: “relevant” representations

Manu Sporny: appropriate representations: for the languages for which they are appropriate

Resolution #2: Remove the requirement in DID Spec Registries process to register any schema language (e.g., JSON Schema, SHACL, SHeX, CDDL) as a part of property registrations. The process will encourage providing schema languages for appropriate representations.

Brent Zundel: always good to make our editors happy

Drummond Reed: reading through it… what is the rule around JSON-LD contexts, or do we need one?

Manu Sporny: https://w3c.github.io/did-spec-registries/#the-registration-process

Ivan Herman: that stays, is not changed

Orie Steele: See: https://github.com/w3c/did-spec-registries/issues/264

Drummond Reed: editorial change: we should always number all the way down the list

Brent Zundel: 12 minutes left on call

Drummond Reed: proposal Orie editor-in-chief for life

Brent Zundel: topics to bring up?

4. what goes into v1 DID Context?

See github issue did-spec-registries#184.

Manu Sporny: what goes into the v1 DID context. just stuff in the core spec, the things to make 80% of people’s lives using it easier (crypto suites, linked domain stuff)? where do we draw the line?
… We do need to define the context and what goes in it and what doesn’t.

Orie Steele: big one: i think we’ve learned a lot since the VC spec happened. i think the one thing i feel the strongest about is: you have to plan for v2 when you do v1.

Manu Sporny: +1 to plan for v2 when you do v1

Orie Steele: We have to think about when will v2 exist; what will people do in the years between v1 and v2
… How are we going to make that not super painful so that they feel the spec is usable
… VC Data Model terrible in this regard. didn’t have spec registries to float an unstable version number

Drummond Reed: I am actually serious that I have to drop a few mins early. Besides the topic Manu is raising, the other one we should focus on is determining what additional policies are needed for managing DID Spec Registries on an ongoing basis.

Orie Steele: Proposal that we have a context that only represents DID Core terms, and a second one floated with version process, regularly cut releases as part of registry maintenance

Markus Sabadello: should crypto suites be in security vocab rather than did core?
… like VCs to make VC context just about VC data model, have crypto suites, key types in the separate security context
… wonder if also do that with DID core context. more a question than opinion

Brent Zundel: +1, simplest line to draw: this is what is in DID Core
… extensibility to ease pain of maintaining VC spec

Manu Sporny: the vc v1 context: we did not do a good job there. need to learn from mistakes made there.
… glad to hear Orie say let’s make this easier. trying to move away from kitchen sink contexts.
… tried to do that in VC and it blew up
… need to understand how people will use the DID Context.
… some DID methods will use the base context and will layer their own context on it. leave it to the DID methods to specify what to include.

Orie Steele: examples: https://w3id.org/security/bbs/v1 - https://w3id.org/security/jws/v1 - https://w3id.org/security/pgp/v1

Manu Sporny: presume they will have their own DID method context to layer on top. feels like a good middle ground.
… Another extreme: we could make it so that every tiny little crypto suite is split into two things: the crypto suite stuff you would put in the DID document, and what you would put in the credential
… context entry becomes 4,6,8+ entries deep. don’t like that
… would like a base DID context, and one up to the DID method that they can iterate at their own pace.

Orie Steele: +1 to what manu said, i think, the best way is to have the base context only thing in did core, method-specific context things the method has added, and any third ones specific to controller if allowed, other extensions, etc. probably should only have 2 or 3 urls in that list if you are doing it right. we should explain and recommend that as a best practice

Manu Sporny: +1 to what Orie just said.

Orie Steele: This would be best : “https://www.w3.org/ns/did/v1” - “https://method.example/ns/did/v1” - “https://w3id.org/security/pgp/v1”

Ivan Herman: want to understand exactly what we say. base context: the v1 currently in our examples. what you mean is that that includes the properties and things only defined in the core document. is this what you mean?
… or it includes those and the registered properties?
… for the time being, there are a bunch of things neither in core or registry - the security things. makes me more nervous

Markus Sabadello: another question for those who know this better: would we consider including other contexts in the did core context, e.g. the security context?

Orie Steele: NOOOOOO do not nest contexts

Orie Steele: markus_sabadello: definitely not. one of my least favorite thing is waiting for deeply nested contexts to resolve

Charles Lehner: method extension contexts, currently seen in security vocab. after that, things not currently registered anywhere

Orie Steele: context to include things in did core, things not defined in did core might be defined in method or seucirt vocab or somewhere else, and that is it

Markus Sabadello: Which one of the three contexts above defines Ed25519VerificationKey2018?

Manu Sporny: I believe that this is what is being proposed:

"@context": [
  "https://www.w3.org/ns/did/v1",
  "https://w3id.org/did-method-example/v2.1",
  "https://w3id.org/some-extension-example/v3.4"
]

Manu Sporny: markus_sabadello, the second one would define Ed25519VerificatioNKey2018

Ivan Herman: one more issue. some of us will hopefully work on chartering a working group for linked data signature. issue of security-related terms will come up there. we may end up with a context there. don’t want them to end up in the core context of this WG. one more consideration to remember

Brent Zundel: closing the meeting.
… thank you for your contributions

5. Resolutions