Extra call on registries — Minutes

Date: 2020-03-16

See also the Agenda and the IRC Log

Attendees

Present: Amy Guy, Ivan Herman, Michael Jones, Yancy Ribbens, Dave Longley, Jonathan Holt, Manu Sporny, Orie Steele, Brent Zundel, Joe Andrieu, Kaliya Young

Regrets:

Guests:

Chair: Manu Sporny

Scribe(s): Markus Sabadello

Content:

opi: is Registries call (https://lists.w3.org/Archives/Member/member-did-wg/2020Mar/0000.html)

e: by burn on 5 March 2020 at 18:04:04 GMT+1

opi: is Registries call (https://lists.w3.org/Archives/Member/member-did-wg/2020Mar/0000.html)

e: by burn on 5 March 2020 at 18:04:04 GMT+1

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

Orie Steele: I think this is the link we are looking for

1. DID Core Registries

Orie Steele: DID Core Registries Stabilization Checklist

Manu Sporny: Today’s topic is the continuation of discussing the DID Core Registry issues

Jonathan Holt: link for agenda?

Manu Sporny: We will continue where we left off last week, unless anyone has additional topics

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

Manu Sporny: There is no separate link for an agenda. The agenda IS the checklist on Github
… We had two items last week with objections, we should start with those
… We need agreement on those so we can go into action items

Orie Steele: LEts start with “ Any addition to the DID Core Registries MUST link, via a URL, to the defining specification so that implementers can implement the property.”

Manu Sporny: Let’s start with the one about linking to a spec
… jonathan_holt you objected to this, do you have any concrete modifications or changes ?

Jonathan Holt: URI vs URL

Orie Steele: In order for this to be usable for developers, they should browse to a specification and then click through to additional material
… it’s okay to click through a page controlled by another entity, that page may contain URIs
… I strongly object to including unclickable links in the DID Core Registry

Manu Sporny: we have objections both ways

Dave Longley: I would not object to having URIs and URLs in a registry, if there is a URI scheme that has content integrity

Orie Steele: I’ve be ok with URL + URI.

Dave Longley: Agree with Orie to ONLY have a URI, we should have a link to something usable

Jonathan Holt: The content integrity is where I’m going with this
… I have issues with mutable URLs that are not permanent. I want to leave the door open for a more robust solution (either URLs with hashlinks, or IPFS scheme, or other URIs that solve this that are more persistent)
… This opens a broader question about URIs in RDF; not all URIs resolve. This would be a problem for implementations. It’s a trade-off for a more hardened solution

Orie Steele: IPFS URIs don’t resolve when the content is not pinned… they are as permanent as anything that people pay to keep permanent.

Michael Jones: I think people are overthinking this. The point is to have a link that developers can follow to a spec that defines the features. This shouldn’t be hard.
… It has to be clickable and has to result in the spec (-section), so developers know what to build. Anything that is not clickable is useless.

Manu Sporny: Thinking about language. Not hearing anyone to object to “at least a URL”

Dave Longley: +1 that we need something clickable so developers can find and implement the feature; +1 to allowing some content integrity stuff to support jonathan’s concern

Manu Sporny: How about “at least a URL, preferably a content integrity protected one to the specification”

Orie Steele: Propose OS1: Any addition to the DID Core Registries MUST link at least a URL, preferably an integrity protected one, to the defining specification so that implementers can implement the property.

Manu Sporny: Make URL the standard way how we do it, but allow other ways for the future. Anyone object?

Jonathan Holt: My concern is if in 10 years websites go down.. I would like to have a more persistent solution for this

Manu Sporny: What is the solution we can use today?

Orie Steele: See also: https://github.com/perma-id/w3id.org

Jonathan Holt: Hashlinks could be used.
… URLs are URIs. There are other URIs that are resolvable.
… The elegant simplicity of just clicking on a link can be a vulnerability
… There could be a better solution, slightly hardened. If we use URIs we can leave the door open

Michael Jones: The threat here is that the developer may not be able to see the spec, e.g. the DNS system could send them to the wrong spec. I think this is detectable by the developer, and pretty remote. I think it’s much more important to make the spec available to developers in an easy way, using already widely deployed technologies

Orie Steele: I want to second what selfissued said. I worked with IPFS, I am very familiar with how that works, gateways, e.g. I love the technology, but don’t want it to be a dependency for the registry.

Dave Longley: +1 to not depend on IPFS to use the registry, +1 that the threat here for different/bad definitions is minimal – you don’t get interop

Orie Steele: I don’t think we should be taking IPFS URIs as a dependency, we just need webpages

Manu Sporny: I wanted to +1 what selfissued and Orie said. jonathan_holt I asked for a concrete solution

Orie Steele: See IPFS Gateway on Cloudflare: https://developers.cloudflare.com/distributed-web/ipfs-gateway/browsing-ipfs/

Manu Sporny: There are probably going to be objections to vague solutions. We may get consensus on having at least URLs
… People seem to be pushing back, jonathan_holt can you think of another modification to the text

Jonathan Holt: Specific modification would be to use URIs that allow us to use a more robust security solution
… People know how to resolve http, ftp. With a hashlink modifier at the end of it, a self-describing model would push this forward

Ivan Herman: What is happening these days is that one information (usually a hash of the target) can be found, e.g. when open source software is distributed
… It doesn’t necessarily have to be part of the URL, it can be published separately. People can check as long as the hash is found somewhere. Then you have the security
… This is the kind of model we can use

Dave Longley: features should have test suites that are known to the community – if your implementation passes the test suite, it doesn’t matter what page you read to implement it

Jonathan Holt: Any addition to the DID Core Registries MUST be URI, preferably a content-integrity protected URL, to the defining specification so that implementers can implement the property

Jonathan Holt: Preferably a content integrity protected URL, but better a URI

Manu Sporny: Please type +1, -1 to what jonathan_holt just provided

Orie Steele: -1, we don’t need this, we can just use GitHub…

Jonathan Holt: +1 to DID URL. that is basically what Aires is using

Jonathan Holt: +1 to “dereferencable URI’

Michael Jones: -1

Manu Sporny: Would your vote change if it was a “dereferencable URI”?

Orie Steele: I don’t think it would change, we don’t need to do this in the registry

Michael Jones: Just make it a URL - the KISS principle applies

Michael Jones: This is for developers - not machines

Manu Sporny: Will write down 2 proposals

Michael Jones: I agree that a “dereferencable URI” is a URL

Manu Sporny: PROPOSAL 1: Any addition to the DID Core Registries MUST be a deferenceable URI, preferably a content-integrity protected URL, to the defining specification so that implementers can implement the property.

Orie Steele: I agree, but I don’t want to formats that developers can’t follow as URLs

Michael Jones: -1

Orie Steele: -1

Amy Guy: -0

Manu Sporny: -1

Ivan Herman: -0

Dave Longley: -1 because “dereferencable URI” is a URL, let’s just use that term

Yancy Ribbens: -1

Jonathan Holt: Are we making decisions on this call?

Jonathan Holt: +1

Joe Andrieu: -1

Manu Sporny: This is a straw poll, just seeing where people are

Michael Jones: We’re making recommendations to the working group

Kaliya Young: 0

Markus Sabadello: +1

Orie Steele: This is the issue, were aries decided to switch from DID URIs to URLs for specs: https://github.com/hyperledger/aries-rfcs/issues/129

Manu Sporny: PROPOSAL 2: Any addition to the DID Core Registries MUST link, via at least a URL, preferably a content-integrity protected one, to the defining specification so that implementers can implement the property.

Yancy Ribbens: +1

Orie Steele: =1

Dave Longley: +1

Orie Steele: +!

Amy Guy: +1

Orie Steele: +1 lol

Ivan Herman: +1

Manu Sporny: +1

Brent Zundel: +1

Jonathan Holt: -1

Markus Sabadello: +1 (i don’t really understand the difference)

Michael Jones: +1

Joe Andrieu: +1

Orie Steele: or customThing:broken:123 … thats not usable…

Manu Sporny: One proposal would allow “ipfs:”, whereas the other one is about easy links

Resolution #1: Any addition to the DID Core Registries MUST link, via at least a URL, preferably a content-integrity protected one, to the defining specification so that implementers can implement the property.

Manu Sporny: We’re marking the second proposal as resolved, but this is not a decision, we will surface this to the broader group
… jonathan_holt you will have an opportunity to formally object when the registry becomes adopted
… I will update the wording and we will move on

Jonathan Holt: Using the “URI” language will also facilitate the use of DID URLs, which is also what Aries is using

Manu Sporny: There was an objection to: Any addition to the DID Core Registries MUST be placed in a sub-namespace if it isn’t in the DID Core Registry. For example: https://www.w3.org/ns/did/btcr/ and [https://www.w3.org/ns/did/btcr/(v1 v2 v3).](https://www.w3.org/ns/did/btcr/(v1 v2 v3).)

Manu Sporny: selfissued , I believe you objected to this, could you clarify and elaborate what your objection was about, plus any potential change?

Michael Jones: We want an open ecosystem, where anybody could define stuff, just like the JOSE registries, you can use whatever namespace you want, provided your inclusion meets the quality bar.
… If it’s hosted at foo.com, that’s still fine, we should not require the use of any particular namespace

Orie Steele: If I understand correctly, you object to requiring the use the W3C namespace
… So you would be okay with any pointer to any resolvable location.

Michael Jones: Some of it can happen at OpenID Foundation, IETF, etc. we should not exclude those
… I propose we delete the entire line

Orie Steele: Sounds like what we had before :) I’m fine with that

Joe Andrieu: +1 to delete the line

Manu Sporny: I’d be fine with that. Any objections?

Dave Longley: +1 i’m all for going to what we had before :)

Amy Guy: +1

Orie Steele: +1

Jonathan Holt: +1 to decentralized solutions, -1 to the idea that these are only JSON-LD solutions

Ivan Herman: No objection, but I think one part is whether it is in W3C or not. I agree this doesn’t have to be required. But there’s another aspect: If the same organization registers two different things, there should be a way to define what namespace they use. What is the naming scheme we require when we add something?

Orie Steele: jonathan_holt I think this would also apply to CBOR defintion or terms

Michael Jones: I don’t even know what “sub-namespace” means

Ivan Herman: We can agree that it is not required to be at W3C, but we need a clear requirement how you name your new stuff

Orie Steele: for example, sidetree methods might want to share context and schema defintions regarding ipfs concepts.

Michael Jones: I think the requirement is that it’s an addressable URL
… It’s up to the inventor

Yancy Ribbens: +1

Manu Sporny: I’m not hearing objections. We may strike this rule, but may require other new ones
… We can add further rules on top of that later. I think we have consensus to strike this line
… Let’s talk about potential ways how we can constrain this in the future. It matters a little bit
… The URL they give you should be a long-lived stable URL. Putting no rules on it may result in judgement calls by people who manage the registry
… We can have a separate issue to discuss this later

Michael Jones: “Long-lived, stable” is normal, this is standard (common sense) for such registries anyway

Jonathan Holt: For a decentralized infrastructure that is under my control
… If we allow any URI, I’m as the individual am in control of my namespace, the registry becomes controlled by the individual, not W3C

Manu Sporny: We went through the agreements, now we can move on to what we need to DO

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

Orie Steele: ^ selfissued

Manu Sporny: We’re now looking at the 6 items at the bottom
… Item 1: Perform a JSON Schema linting procedure on the added JSON Schema files as a commit hook to ensure invalid JSON Schemas are not committed to the registry.
… Any objections?
… Item 2: Perform a JSON Schema verification process on a corpus of DID Documents from a variety of DID Methods as a commit hook to see if the property addition breaks any existing DID Methods.

Joe Andrieu: objection

Manu Sporny: This is a sanity check to make sure additions to the registry don’t break anything we are using. It doesn’t mean it can’t get into the registry, but it shows that something is broken

Jonathan Holt: Does this mean the DID document would have to be normalized into JSON format?
… I think we need more discussion how to implement that

Manu Sporny: Publish the latest DID vocabulary to https://www.w3.org/ns/did/ and publish latest the machine-readable JSON-LD Contexts to [https://www.w3.org/ns/did/(v0.11 v1)](https://www.w3.org/ns/did/(v0.11 v1))

Markus Sabadello: manu Item 3

Orie Steele: jonathan_holt please review: https://github.com/w3c/did-core-registry/pull/11 its been up for weeks.

Manu Sporny: This is more or less what we do right now, but we want to update the machine-readable data so that it’s actually working

Manu Sporny: Redirect https://w3id.org/did/ to https://www.w3.org/ns/did/ and [https://w3id.org/did/(v0.11 v1)](https://w3id.org/did/(v0.11 v1)) to [https://www.w3.org/ns/did/(v0.11 v1)](https://www.w3.org/ns/did/(v0.11 v1))

Manu Sporny: No objections
… I’m 4
… Item 4

Orie Steele: +1 for updating the current links to the correct location, so we can fix all the interop issues regaridn the existing methods

Manu Sporny: We just said the W3C namespace is normative, this would be updating all the links to their proper location. We will redirect the w3id.org links to the w3.org ones, for the vocabulary and the JSON-LD contexts

Jonathan Holt: Who manages w3id.org?

Manu Sporny: The Permanent Identity Community Group at W3C

Jonathan Holt: I’d rather keep this in our group

Orie Steele: jonathan_holt see: https://github.com/perma-id/w3id.org

Orie Steele: ^ its this github

Manu Sporny: Are you objecting?

Orie Steele: its what everyone uses today…

Jonathan Holt: I don’t understand what we’re agreeing to. This seems like a workaround

Ivan Herman: I don’t really understand either what this is
… I think it was one of the Security vocabularies that was in w3id.org. Who will control that? The redirection doesn’t say much.
… What are the URLs that implementers will use?

Manu Sporny: w3id.org has existed for a very long time, and today it points to the wrong documents. It’s badly broken. We’re trying to fix that.

Orie Steele: See my attempt to fix it here: https://github.com/perma-id/w3id.org/pull/1638

Manu Sporny: Normative implementations should be using the w3.org one, but we still have older implementations that w3id.org. This is a bugfix

Ivan Herman: This is a fix that ensures backwards compatbility. You don’t want to break older implementations

Jonathan Holt: I don’t think if W3C is redirecting w3id, this would be a bigger issuer

Orie Steele: we can fix this, and we are trying to fix it

Manu Sporny: We have people in this group that can take this decision forward

Jonathan Holt: This should be decided by another group

Ivan Herman: FOrmally speaking, jonathan_holt is right

Manu Sporny: But this group doesn’t object to this happening?

Orie Steele: assign it to me

Michael Jones: I wanted to say the same thing as jonathan_holt . This is not our group, some of us may contact that other group privately, but we should remove this line from the list.

Manu Sporny: We could remove this line, understanding that this group wouldn’t object if this happens
… THis has been removed from the list.
… Publish the human readable security vocabulary https://www.w3.org/ns/security/ and publish the machine-readable JSON-LD Contexts at https://www.w3.org/ns/security/(v1|v2|v3)
… Any objections?

Jonathan Holt: Have these been normalized and have they done a security audit?

Manu Sporny: Define “normalized”

Jonathan Holt: Is there no ambiguity, e.g. there may be multiple implementations. The namespace is really important. The need for having a vocabularity, has it been vetted to be accurate

Manu Sporny: It has undergone vetting and reviewing, there is always the question how much and is it enough

Jonathan Holt: How do you find that out? These are important semantics to flesh out, make sure vocabulary is right, and someone is agreement that it describes the right algorithm, signature scheme, etc. And who decides that.

Ivan Herman: I wanted to say, we should not for the time being decide exactly what terms to use. Whether it is ns/security or ns/somethingelse. Putting a vocabulary there in the name of “security” is something that some security may not be happy about. We have to be careful about the /ns/ shared resource

Orie Steele: thats right… w3id.org becomes the thing that controls these security concepts….

Orie Steele: regarding vocabulary…

Manu Sporny: +1 to ivan . If we don’t do something here, then w3id.org becomes the controlling authority, which would be a dependency. If we don’t push for a decision, we will have a section of the DID spec that is outside the control of the Working Group.
… Current state: Non W3C, non-standards-track body is controlling the namespace. One way forward is to say the WG will take control so it gives us a stable home and stable reference for the specification

Orie Steele: The state we are in today with existing contexts relies on w3id.org, the decision not to allow the WG to control this, is a decision to allow w3id.org to continue to do that organically
… We decided earlier that it’s okay that not all registry entries are under W3C, but we should centralize the most common elements that DID methods use

Ivan Herman: Agree with all that. I propose to modify your proposal to say /ns/did/security, to avoid any political discussions on this

Jonathan Holt: Who allowed the security vocabulary to be under w3id.org, bringing it under /ns/security would be a compromise
… My big concern is security vulnerabilities, namespace registrations, SSL proxies, ..
… I could demonstrate how to make a Verifiable Credential appear valid when it isn’t

Manu Sporny: I think we are aware of those attack vectors

Michael Jones: I’m fine with us publishing this, and taking control. As a pragmatic matter I would just remove the proposed URLs from the action items, and just say “within the W3C namespace” (location to be determined)

Proposed resolution: Adopting the Security Vocabularies and JSON-LD Context documents into the control of the DID WG and the DID WG will publish these documents at stable locations under the www.w3.org/ns/ namespace. (Manu Sporny)

Orie Steele: +1

Manu Sporny: +1

Dave Longley: +1

Ivan Herman: +1

Brent Zundel: +1

Jonathan Holt: These shouldn’t be just links you download. These should be cached and hashed.

Yancy Ribbens: +1

Markus Sabadello: +1

Michael Jones: +1

Manu Sporny: I think there is general consensus, I believe the group understands and shares the concerns. The spec will be written to use content-based addressing, or use static versions of the files. I think what the group wants is in line with what you jonathan_holt are saying

Orie Steele: Here is the IPFS defintion for my custom schema, please resolve it to see how this will be problematic: https://ipfs.io/ipfs/QmTDMoVqvyBkNMRhzvukTDznntByUNDwyNdSfV8dZ3VKRd

Manu Sporny: This is the entire list, thank you everyone. Our special next call will be about DID parameters, matrix parameters. The next special call after that will likely be about the metadata discussion

Michael Jones: Are those other special calls scheduled?

Brent Zundel: Will share the link for Doodle polls

Brent Zundel: https://doodle.com/poll/prwxqv6k23prt8g3

2. Resolutions