<rhiaro> scribe+ markus_sabadello

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

<Orie> I think this is the link we are looking for

DID Core Registries

<Orie> DID Core Registries Stabilization Checklist

manu: Today's topic is the continuation of discussing the DID Core Registry issues

<jonathan_holt> link for agenda?

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

<brent> https://github.com/w3c/did-core-registry/issues/13

manu: 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> 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: 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: 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: we have objections both ways

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

<Orie> I've be ok with URL + URI.

dlongley: 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> IPFS URIs don't resolve when the content is not pinned... they are as permanent as anything that people pay to keep permanent.

selfissued: 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.

<Zakim> manu, you wanted to suggest some text.

manu: Thinking about language. Not hearing anyone to object to "at least a URL"

<dlongley> +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: How about "at least a URL, preferably a content integrity protected one to the specification"

<Orie> 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: 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: What is the solution we can use today?

<Orie> 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

selfissued: 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: 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.

<dlongley> +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: I don't think we should be taking IPFS URIs as a dependency, we just need webpages

<Zakim> manu, you wanted to note I asked for a concrete solution - I'm not hearing one, just "foot in the door"

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

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

manu: 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: 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

<dlongley> 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: Please type +1, -1 to what jonathan_holt just provided

<Zakim> manu, you wanted to note no known attacks for this vector

<Orie> -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'

<selfissued> -1

manu: Would your vote change if it was a "dereferencable URI"?

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

<selfissued> Just make it a URL - the KISS principle applies

<selfissued> This is for developers - not machines

manu: Will write down 2 proposals

<selfissued> I agree that a "dereferencable URI" *is* a URL

<manu> 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> I agree, but I don't want to formats that developers can't follow as URLs

<selfissued> -1

<Orie> -1

<rhiaro> -0

<manu> -1

<ivan> -0

<dlongley> -1 because "dereferencable URI" is a URL, let's just use that term

<yancy> -1

jonathan_holt: Are we making decisions on this call?

<jonathan_holt> +1

<JoeAndrieu> -1

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

<selfissued> We're making recommendations to the working group

<Identitywoman> 0

+1

<Orie> 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> 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> +1

<Orie> =1

<dlongley> +1

<Orie> +!

<rhiaro> +1

<Orie> +1 lol

<manu> +1

<brent> +1

<jonathan_holt> -1

<ivan> +1

+1 (i don't really understand the difference)

<selfissued> +1

<JoeAndrieu> +1

<Orie> or customThing:broken:123 ... thats not usable...

manu: One proposal would allow "ipfs:", whereas the other one is about easy links

RESOLUTION: 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: 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> 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).

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

selfissued: 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: 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.

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

<Orie> Sounds like what we had before :) I'm fine with that

<JoeAndrieu> +1 to delete the line

manu: I'd be fine with that. Any objections?

<dlongley> +1 i'm all for going to what we had before :)

<rhiaro> +1

<Orie> +1

<jonathan_holt> +1 to decentralized solutions, -1 to the idea that these are only JSON-LD solutions

ivan: 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> jonathan_holt I think this would also apply to CBOR defintion or terms

selfissued: I don't even know what "sub-namespace" means

ivan: 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> for example, sidetree methods might want to share context and schema defintions regarding ipfs concepts.

selfissued: I think the requirement is that it's an addressable URL
... It's up to the inventor

<yancy> +1

manu: 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

<Zakim> manu, you wanted to comment on possible guidelines. and to

manu: 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

selfissued: "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: We went through the agreements, now we can move on to what we need to DO

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

<Orie> ^ selfissued

manu: 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.

<JoeAndrieu> objection

manu: 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> 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)

manu Item 3

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

manu: 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> Redirect https://w3id.org/did/ to https://www.w3.org/ns/did/ and https://w3id.org/did/(v0.11|v1) to https://www.w3.org/ns/did/(v0.11|v1)

manu: No objections
... I'm 4
... Item 4

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

manu: 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: The Permanent Identity Community Group at W3C

jonathan_holt: I'd rather keep this in our group

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

<Orie> ^ its this github

manu: Are you objecting?

<Orie> its what everyone uses today...

jonathan_holt: I don't understand what we're agreeing to. This seems like a workaround

ivan: 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: 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> See my attempt to fix it here: https://github.com/perma-id/w3id.org/pull/1638

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

ivan: 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> we can fix this, and we are trying to fix it

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

jonathan_holt: This should be decided by another group

ivan: FOrmally speaking, jonathan_holt is right

manu: But this group doesn't object to this happening?

<Orie> assign it to me

selfissued: 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: 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: 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: 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: 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> thats right... w3id.org becomes the thing that controls these security concepts....

<Orie> regarding vocabulary...

manu: +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: 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: 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: I think we are aware of those attack vectors

<Zakim> manu, you wanted to note that it's not DID specific.

selfissued: 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)

<manu> PROPOSAL: 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.

<Orie> +1

<manu> +1

<dlongley> +1

<ivan> +1

<brent> +1

jonathan_holt: These shouldn't be just links you download. These should be cached and hashed.

<yancy> +1

+1

<selfissued> +1

manu: 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> 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: 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

selfissued: Are those other special calls scheduled?

brent: Will share the link for Doodle polls

<brent> https://doodle.com/poll/prwxqv6k23prt8g3

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/MUST/MUST be/
Succeeded: s/find/fine/
Default Present: rhiaro, ivan, selfissued, yancy, dlongley, jonathan_holt, manu, Orie, brent, JoeAndrieu, Identitywoman, !
Present: rhiaro ivan selfissued yancy dlongley jonathan_holt manu Orie brent JoeAndrieu Identitywoman !
No ScribeNick specified.  Guessing ScribeNick: markus_sabadello
Inferring Scribes: markus_sabadello

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)