15:58:29 <RRSAgent> RRSAgent has joined #did
15:58:29 <RRSAgent> logging to https://www.w3.org/2020/03/16-did-irc
15:58:31 <Zakim> RRSAgent, make logs Public
15:58:32 <Zakim> please title this meeting ("meeting: ..."), ivan
15:58:52 <ivan> Meeting: Extra call on registries
15:59:10 <rhiaro> present+
15:59:47 <ivan> present+
16:00:07 <selfissued> selfissued has joined #did
16:00:11 <selfissued> present+
16:00:22 <yancy> present+
16:00:53 <ivan> chair: manu
16:01:13 <jonathan_holt> jonathan_holt has joined #did
16:01:18 <dlongley> present+
16:01:47 <jonathan_holt> present+ jonathan_holt
16:01:49 <brent> brent has joined #did
16:01:50 <manu> present+
16:01:57 <Orie> Orie has joined #did
16:02:02 <Orie> present+
16:02:20 <brent> present+
16:03:12 <markus_sabadello> markus_sabadello has joined #did
16:03:18 <rhiaro> scribe+ markus_sabadello
16:03:27 <Orie> https://github.com/w3c/did-core-registry/issues/13
16:03:42 <Orie> I think this is the link we are looking for
16:04:04 <manu> Topic: DID Core Registries
16:04:07 <brent> q?
16:04:08 <Orie> DID Core Registries Stabilization Checklist
16:04:22 <markus_sabadello> manu: Today's topic is the continuation of discussing the DID Core Registry issues
16:04:31 <jonathan_holt> link for agenda?
16:04:36 <markus_sabadello> manu: We will continue where we left off last week, unless anyone has additional topics
16:04:43 <brent> https://github.com/w3c/did-core-registry/issues/13
16:05:01 <markus_sabadello> manu: There is no separate link for an agenda. The agenda IS the checklist on Github
16:05:17 <markus_sabadello> manu: We had two items last week with objections, we should start with those
16:05:28 <markus_sabadello> manu: We need agreement on those so we can go into action items
16:05:31 <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."
16:05:44 <markus_sabadello> manu: Let's start with the one about linking to a spec
16:05:48 <Orie> q+
16:06:05 <markus_sabadello> manu: jonathan_holt you objected to this, do you have any concrete modifications or changes ?
16:06:10 <markus_sabadello> jonathan_holt: URI vs URL
16:06:33 <markus_sabadello> Orie: In order for this to be usable for developers, they should browse to a specification and then click through to additional material
16:06:53 <markus_sabadello> Orie: it's okay to click through a page controlled by another entity, that page may contain URIs
16:07:02 <dlongley> q+
16:07:09 <jonathan_holt> q+
16:07:10 <markus_sabadello> Orie: I strongly object to including unclickable links in the DID Core Registry
16:07:14 <brent> ack Orie
16:07:16 <markus_sabadello> manu: we have objections both ways
16:07:16 <JoeAndrieu> JoeAndrieu has joined #did
16:07:46 <selfissued> selfissued has joined #did
16:07:46 <markus_sabadello> dlongley: I would not object to having URIs and URLs in a registry, if there is a URI scheme that has content integrity
16:07:50 <selfissued> present+
16:07:53 <Orie> I've be ok with URL + URI.
16:07:55 <selfissued> q+
16:08:04 <markus_sabadello> dlongley: Agree with Orie  to ONLY have a URI, we should have a link to something usable
16:08:14 <brent> ack dlongley
16:08:19 <markus_sabadello> jonathan_holt: The content integrity is where I'm going with this
16:08:42 <brent> ack jonathan_holt
16:08:57 <markus_sabadello> jonathan_holt: 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)
16:09:27 <markus_sabadello> jonathan_holt: 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
16:09:28 <brent> ack selfissued
16:09:39 <Orie> IPFS URIs don't resolve when the content is not pinned... they are as permanent as anything that people pay to keep permanent.
16:09:51 <markus_sabadello> 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.
16:09:56 <manu> q+ to suggest some text.
16:10:13 <markus_sabadello> selfissued: 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.
16:10:16 <brent> ack manu
16:10:16 <Zakim> manu, you wanted to suggest some text.
16:10:32 <markus_sabadello> manu: Thinking about language. Not hearing anyone to object to "at least a URL"
16:10:46 <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
16:10:58 <markus_sabadello> manu: How about "at least a URL, preferably a content integrity protected one to the specification"
16:11:10 <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.
16:11:20 <markus_sabadello> manu: Make URL the standard way how we do it, but allow other ways for the future. Anyone object?
16:11:43 <markus_sabadello> jonathan_holt: My concern is if in 10 years websites go down.. I would like to have a more persistent solution for this
16:11:52 <markus_sabadello> manu: What is the solution we can use today?
16:11:54 <Orie> See also: https://github.com/perma-id/w3id.org
16:12:03 <markus_sabadello> jonathan_holt: Hashlinks could be used.
16:12:42 <markus_sabadello> jonathan_holt: URLs are URIs. There are other URIs that are resolvable.
16:12:45 <brent> q?
16:13:09 <markus_sabadello> jonathan_holt: The elegant simplicity of just clicking on a link can be a vulnerability
16:13:11 <selfissued> q+
16:13:31 <Orie> q+
16:13:32 <markus_sabadello> jonathan_holt: There could be a better solution, slightly hardened. If we use URIs we can leave the door open
16:13:40 <brent> ack selfissued
16:13:56 <manu> q+ I asked for a concrete solution - I'm not hearing one, just "foot in the door"
16:13:59 <manu> q+ to note I asked for a concrete solution - I'm not hearing one, just "foot in the door"
16:14:27 <markus_sabadello> 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
16:15:00 <jonathan_holt> q+
16:15:13 <markus_sabadello> 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.
16:15:28 <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
16:15:51 <markus_sabadello> Orie: I don't think we should be taking IPFS URIs as a dependency, we just need webpages
16:15:59 <brent> ack manu
16:15:59 <Zakim> manu, you wanted to note I asked for a concrete solution - I'm not hearing one, just "foot in the door"
16:16:21 <ivan> q+
16:16:22 <markus_sabadello> manu: I wanted to +1 what selfissued and Orie said. jonathan_holt I asked for a concrete solution
16:16:31 <Orie> See IPFS Gateway on Cloudflare: https://developers.cloudflare.com/distributed-web/ipfs-gateway/browsing-ipfs/
16:16:54 <markus_sabadello> manu: There are probably going to be objections to vague solutions. We may get consensus on having at least URLs
16:17:22 <manu> ack Orie
16:17:25 <markus_sabadello> manu: People seem to be pushing back, jonathan_holt can you think of another modification to the text
16:17:25 <manu> ack jonathan_holt
16:18:02 <markus_sabadello> jonathan_holt: Specific modification would be to use URIs that allow us to use a more robust security solution
16:18:29 <markus_sabadello> jonathan_holt: People know how to resolve http, ftp. With a hashlink modifier at the end of it, a self-describing model would push this forward
16:18:50 <brent> ack ivan
16:19:17 <markus_sabadello> 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