16:56:16 RRSAgent has joined #did 16:56:16 logging to https://www.w3.org/2020/03/05-did-irc 16:56:41 burn has changed the topic to: DID special topic call: registries 16:58:08 present+ 16:58:17 present+ 16:58:31 Meeting: Special Topic DID call (registries) 16:59:46 Eugeniu_Rusu has joined #did 17:00:42 Orie has joined #did 17:00:44 jonathan_holt has joined #did 17:00:45 present+ 17:00:56 present+ 17:00:56 https://lists.w3.org/Archives/Member/member-did-wg/2020Mar/0000.html 17:01:02 present+ jonathan_holt 17:01:15 present+ 17:01:18 scribe+ rhiaro 17:01:30 charlescunningham has joined #did 17:01:40 selfissued has joined #did 17:01:41 present+ 17:01:44 present+ 17:02:03 present+ 17:02:11 See proposal here: https://github.com/w3c/did-core-registry/issues/3 17:02:25 burn: this is a discussion, we're not taking decisions 17:02:41 see also: https://github.com/w3c/did-core-registry/issues/13 17:02:49 ... Decisions will happen as normal with github issues and prs. This group could come to what they believe everyone is happy with and then create PRs from that 17:02:54 for a task list 17:03:26 And regarding normative definitions: https://github.com/w3c/did-core-registry/issues/9 17:04:04 burn has changed the topic to: Registries call (https://lists.w3.org/Archives/Member/member-did-wg/2020Mar/0000.html) 17:04:23 Orie: high level, what we're trying to do is get the registry into shape where we can start to add properties at a more rapid pace. We want to make sure we agree to the structure and tech and foundation while it's small, and then as we add properties [..] definitions as we go 17:04:41 ... we don't want to update thousands of properties all at once because we decided the structure of the registry should cahnge drastically. It should change incrementally 17:04:47 ... there are a couple of key themes to consider 17:05:04 ... one is the mechanism for ensuring the registry dfns are valid internally, machine readable as much as we can 17:05:25 q+ to remind people to present+ and to outline the list of things we need to decide on. 17:05:33 ... there is the concept of where's the human readable documentations associated with the registry entries. That gets into, the registry is pointing to other sources, including the DID core spec, and we want to be on the same page about how that referencing for human readable defnitiosn is happening 17:05:41 present+ 17:05:49 ... a final point would be this registry has the potentila to be valuable in terms of demonstrating did method interop and compliance and testing 17:05:56 ... I'd love to be able to take advantage of that 17:06:15 present+ 17:06:21 ... historically we've had jsonld machine readable defintions for the concept of a registry 17:06:45 ... the major change now is to add json schema to support the json only representation with a level of specificity that is excellent, and benefits the jsonld representations as well as the json only ones, and potentially also the cbor ones 17:07:00 q? 17:07:03 q+ 17:07:05 ack manu 17:07:05 manu, you wanted to remind people to present+ and to outline the list of things we need to decide on. 17:07:06 ack manu 17:07:08 markus_sabadello has joined #did 17:07:10 present+ 17:07:14 manu: +1 to everything Orie said 17:07:16 JoeAndrieu has joined #did 17:07:24 present+ 17:07:35 ... I have tried to take a number of the statement Orie has said and I've tried to boil them down into very specific things that the group needs to agree to 17:07:40 ... We have to come to consensus on some core principles 17:07:58 ... and a checklist of if we agree to the core principles, these are the things we need to do to enact them and make this registry the stable thing that all implementers can depend on 17:08:09 https://github.com/w3c/did-core-registry/issues/13 17:08:13 ... I would like to go through this ^ 17:08:20 ... 16 items to discuss and/or agree or debate 17:08:36 ... if we get through all of those items, I believe we will get to a good stable process around the management of the registry 17:08:44 ... that list contains a number of things Orie said as well as other detailed things 17:08:53 ... Clarifying questions? 17:09:24 ... After that we'll start going through that list, it touches on the items Orie touched on, and if we need to do a deep dive on some of them we can 17:09:25 q? 17:09:25 I'm going to use https://www.iana.org/assignments/jose/jose.xhtml as an example when I speak 17:09:31 Orie: I think your issue is a better place to start 17:09:32 q+ to go through #13 17:09:54 selfissued: one foundational thing is we need to start using terminology the same way 17:10:07 yes, this is a set of registries. 17:10:08 ... referring to 'the registry' is misleading because per example the example I just put in the chat, the jose registries document 17:10:13 ... take 5 seconds to see that 17:10:33 ... you will see in this registries doc run by iana that there are 9 different registries that are related to each other, all in the same registry document 17:10:48 ... I'm certain that's going to be the case with us, we'll be registering mor ethan one kind of thing 17:11:03 ... top level did document params, did methods, we may have registries for algorithms, these are different registries, it's not 'the registry' 17:11:08 ... we should start using that terminology 17:11:26 ... that will align us with the way the rest of the world uses the term registry, as a repository of things of the same type 17:11:28 q+ 17:11:39 ack selfissued 17:11:51 manu: +1 to that, I think.. any objections to what mike said? I think consensus in the group is yes, this will contain multiple types of things that are similar in nature 17:11:54 yes, thats the intention 17:11:54 q- later 17:12:12 burn: I agree with mike, I want to point out something a little strange about our conversation 17:12:34 ... the registry document you're looking at that mike provded shows a number of different iana registries. The way iana registries work is as you see it here, you have a registry and links to other pieces of information 17:12:54 ... w3c is still working out exactly how they want their registries to work, but there' sa possibility that we'll have a document that contains the content, not just references 17:13:08 ... I agree with you mike, we are going to have multiple registries becasue there will be different types of information 17:13:12 ... how they're represented may be confusing in the end 17:13:24 ... there may be one document that contains multiple registries that themselves contain entries 17:13:39 ... but I agree with you we should talk about them as registries as long as we understand that how they're specifically represented is going to be worked out 17:13:46 selfissued: that's fine, I jsut want us to use consistent terminology 17:13:55 q? 17:13:58 ack burn 17:14:02 manu: with that, if there are no objections to what mike and dan just said, let's get into the list 17:14:04 https://github.com/w3c/did-core-registry/issues/13 17:14:08 ... I'm going to read through the list 17:14:20 ... there are going to be multiple people objecting to multiple items on this list 17:14:30 ... I want to explain why each item is there and then we can go back through and determine any objections 17:14:44 ... The first 3 are checked, we had consensus at the f2f to do at least these things 17:14:56 ... the items unchecked are all of the questions that came up after the f2f about how we're going to operate the registries 17:15:04 ... it says DID core registry, but read that as DID core registries 17:15:16 ... read registry as registries 17:15:33 ... There are a set of things we need to agree to, and then a set of things we need to *do* 17:15:38 ... first list is agree to, second is to do 17:15:48 ... First item is something I believe we got consnesus on at the f2f 17:15:55 ... Any addition to the DID Core Registry MUST specify a human readable description of the property and point to the appropriate specification for that property. 17:16:02 ... the latter part might be controversial 17:16:08 ... second: Any addition to the DID Core Registry MUST specify a machine readable JSON-LD Context for the property. 17:16:20 ... third: Any addition to the DID Core Registry MUST link the machine-readable property in the JSON-LD Context to the human readable description. 17:16:29 q+ 17:16:35 ... this is a best practice and people assume it, but I thought it'd be best if we state it explicitly 17:16:38 ... next: Any addition to the DID Core Registry MUST specify a non-normative JSON Schema for the property. 17:16:56 ... this is something that orie raised at the beginning of the call, it allows some level machine verification of the json 17:17:02 ... lets us automate some of the checking instead of relying on humans 17:17:09 ... next: Any addition to the DID Core Registry 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). 17:17:24 ... this has to do with did methods and how they might expand upon the registry 17:17:28 ... we could do it in a variety of ways 17:17:39 ... kitchen sink approach like schema.org, has a number of downsides 17:17:48 ... we want to enable did methods to operate independantly but still have a place to register all of those items 17:17:53 ... next item is Properties in the DID Core Registry MUST NOT be removed, only deprecated. 17:17:53 q+ 17:18:14 ... if we do anything other than this it creates potentail interop and implementer concners. We need to discuss that. Hasnt' been brought up before 17:18:18 ... next: JSON-LD Contexts MUST NOT be date stamped. The Verifiable Credentials will need to be fixed. 17:18:34 ... goes back to a decision made previously in the did wg, trying to apply something consistent to all of these 17:18:43 ... definitely not what the VC spec did. We may want to revisit that decision 17:18:58 ... we need to figure out what we're doing here because the number of contexts we have is going to be much larger 17:18:59 ... next: JSON-LD Contexts MUST use scoped terms and the @protected feature to eliminate the possibility of term conflicts. 17:19:19 ... this is to ensure that people don't step on each others toes and create some machine level enforcement of that 17:19:25 ... works in concert with the json schema stuff 17:19:31 ... the last one is: The DID Method registry will be included in this registry. 17:19:41 ... the DID method registry is maintained by the CCG 17:19:57 ... If we do this we can have one document that lists all DID related things, so there's one place for people to go to 17:20:05 q? 17:20:08 ... The subsequent list depends on us agreeing on a subset of these items 17:20:09 ack manu 17:20:09 manu, you wanted to go through #13 17:20:36 burn: meta comment. A number of these items are there because of the JSON-LD representation. Some are there because of the JSON-only representation 17:21:09 ... I dislike seeing them all piled together in a list because when someone later wants to add another representation, or when we need something like this for cbor as well, it's easy for people to forget or misunderstand that the reason we need those is in order to support that representation 17:21:23 ... keep that in mind, bring it up if relevant, I dont' think it changes our conversation now, but in the future grouping them by the kind of representation might help 17:21:28 ack burn 17:21:30 ack selfissued 17:21:39 selfissued: one of them uses terminology that's not understood by me 17:21:48 ... What do you mean by MUST be place in a sub namespace? Must be at a URL? 17:22:04 manu: Yes. There's an example there 17:22:13 ... https://www.w3.org/ns/did/btcr/ and https://www.w3.org/ns/did/btcr/(v1|v2|v3). 17:22:16 q+ 17:22:23 ... BTCR may be doing things other DID methods don't do so it gets its own context file 17:22:33 ... a sub namespace via a URL that contains the BTCR only properties as well 17:22:52 selfissued: the examples make it look like everything has to be at w3c. It might be the case that ISO or Microsoft have its own namespace 17:22:57 ... These are just URLs that have to be distinct 17:23:05 q? 17:23:07 q+ to add URI 17:23:14 selfissued: asking people to put these at w3c namespaces is onerous 17:23:44 q+ to respond to selfissued -- URLs don't have to be at W3C 17:23:54 sorry audio problem, go ahead in the queue 17:23:56 q- 17:24:08 jonathan_holt: I think a URI rather than a URL.. 17:24:12 q+ to ask mike to elaborate on the difference between requiring people to use this centralized registry at W3C and requiring people to use W3C namespace for the registries content 17:24:56 manu: URIs are not always dereferencable and it makes it more difficult to publish a human readable version if it's a URI that can't be derferences, that's the only hesitation I have jonathan_holt, one of the thing we agreed is that we would have human readable documentation 17:24:57 I prefer URL. 17:25:08 some echo... 17:25:10 ... if it's not easy to paste that into a browser and find the docs it potentially goes against something the group agreed to 17:25:33 ... In response to Mike, at ahigh level I agree, but it seems to go counter to some of the things that the JSON only folks wanted which was a registry that's more centralised than decentralised 17:25:53 ... what you said mike is completely compatible with the jsonld view of the world and is what the jsonld folks were arguing for, so I'm confused by you saying that. I think we should do it, I'm just surprised to hear you say that 17:27:03 selfissued: if you look at the jose registry, it points both to stuff that is in rfcs and stuff that is in other places 17:27:14 ... that's normal. Any healthy registry is going to have entries made by other organisations if the technology is vibrant 17:27:31 ... so those other orgs and individuals will have different namespaces and should be empowere dto use them and not increase the weight of the process 17:27:38 ... the only thing that's centralised is presentation 17:27:43 ... references to the definitions 17:27:43 q- 17:27:45 ack jonathan_holt 17:27:45 jonathan_holt, you wanted to add URI 17:27:48 q+ markus_sabadello 17:28:03 q- later 17:28:05 ack markus_sabadello 17:28:06 I agree that the did-core-registries will link to external sources, including IETF, W3C, etc.... 17:28:38 markus_sabadello: my question was whether the subnames would be inherantly linked to the did method registries, would they be specific to certain methods. We have method specific DID params, if there was a registry for that, how method specific things in the registry would relate to this namespacing 17:28:42 manu: those are all very good questions 17:28:50 ... since the queue is exhausted if we want to go through each one of these items one by one now? 17:28:57 ... any objections? 17:29:21 burn: to find out quickly which ones do not have objections, so we can get them checked out? then go back to the ones with objections? 17:29:35 instead of "objections" just say you want discussion 17:29:48 manu: okay, going to run down the list, if you have an objection please say so, and if there is we will not check it and skip to the next one. If there are no objections I'll check it and we'll move on 17:29:55 ... if you object please be ready to say how you'd change it 17:30:18 ... First one; human readable description of property and point to appropriate spec 17:30:31 selfissued: i object to the wrong terminology. Needs to be changed to plural 17:30:40 manu: going to go in and modify to say registries really quickly 17:31:21 ... and I expect we need an item to rename the title of the repo to say registries 17:31:24 I have future comments on the term "DID Core Registries", but I'm fine with it for now as an improvement over "DID Core Registry" 17:31:54 ... First item: title should be changed to DID Core Registries. Any objections? 17:31:59 ... Nope, checked the box 17:32:08 ... Next, human readable description and poitn to spec. Any objections? 17:32:10 jonathan_holt: define point? 17:32:15 manu: a link, a URL 17:32:20 jonathan_holt: I object 17:32:25 ... a URI would be fine 17:32:38 q+ 17:32:44 ... you're specifying a protocol, there are plenty of other identifiers that satisfy the same functionalty 17:32:44 ack manu 17:32:44 manu, you wanted to respond to selfissued -- URLs don't have to be at W3C 17:32:47 ack JoeAndrieu 17:32:48 q+ 17:33:18 JoeAndrieu: I want to push back agains that, the distinction here is this has to be dereferencable so you can get to the spec. Simply having an identifier doesn't do that. If there's something other than a URL that is guaranteed to be resolvable? 17:33:22 q+ 17:33:28 jonathan_holt: defining resolvable is the next thing.. not just points, point and resolve 17:33:35 ... you can do that with oids 17:33:40 q+ 17:33:48 ack selfissued 17:33:49 manu: I updated it to break this out and make the second item simpler 17:33:55 selfissued: the link that programmers use to go read the spec 17:34:01 Lets not bring other protocols into world wide web consortium registry.... it needs to be something that works in a browser 17:34:05 ... if you can't follow the link the programmer doens't know how to implement the registry entry 17:34:16 ... you could put an oid there but it means you'd have to doa search on the web for whatever purports to define the oid 17:34:38 ... every oid is defined in a document. The link in the oid case would be a link to the specification that defines the oid. The oid would probably be part of the registry, the value, but you still need a link to the defining document so people can implement it 17:34:43 ... this is for programmers 17:34:44 ack burn 17:34:45 Feel free to use a gateway: https://example-gateway.com/ipfs/QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy 17:35:07 burn: can we stop discussing right away? I'm sure we'll come back to it, but would it be possible to go through the list and ifnd out which ones have objections instead of trying to resolve them each individuall? 17:35:18 manu: +1. In this case i've split it into two where we agree one and not the other 17:35:26 ... the second item is now, must specify human readable. Any objection? 17:35:35 ... that's checked. Skipping the URL one. 17:35:52 ... Next is any addition to the registries must specify a machine readable jsonld context for the properties. we had consensus at the f2f. Any objections? 17:35:57 jonathan_holt: I have reservations, not objections 17:36:00 manu: that's remaining checked 17:36:17 ... Any addition must link the machine readable context to the human readable description. This is best practice, and agreed at f2f 17:36:20 ... objections? 17:36:26 ... hearing none, staying checked 17:36:37 ... Any addition must specify a non-normative json schema for the properties 17:36:39 ... objections? 17:36:43 selfissued: why non normative? 17:37:01 because the the registry is a note not a specification. 17:37:05 manu: if it were then the json schem aowuld be normative, and then it would raise questions about whether it should be included in the spec, and raises questions about the normative nature in the json schema 17:37:18 selfissued: I'm okay with the language provided you put in a parenthetical saying it's the spec that is normative 17:37:23 manu: any objections to the parenthetical? 17:37:38 ... the specific text is "(the specification is normative)" 17:37:40 selfissued: sure 17:37:56 manu: updated: Any addition to the DID Core Registries MUST specify a non-normative JSON Schema (the specification is normative) for the property. 17:38:00 ... checking 17:38:10 ... Any addition must be placed in a sub namespace if it isn't in the DID core registry 17:38:17 this applies to ethereum and bitcoin 17:38:21 and also sidetree 17:38:22 selfissued: the last bit is confusing and not actionable 17:38:33 manu: next - properties must not be removed, only deprecated. Objections? 17:38:41 ... checking that. 17:38:48 ... JSON-LD contexts must not be datestamped 17:39:02 selfissued: I object to the second sentence because it's out of scope 17:39:09 manu: striking that, any objections to striking that? 17:39:18 ... any objections to the first part? 17:39:24 ... checking that 17:39:35 ... JSON-LD contexts must use scope terms and the @protected feature. Objections? 17:39:54 markus_sabadello: This would preclude the use of JSON-LD 1.0 17:40:04 selfissued: I don't understand this well enough to evaluate it 17:40:20 jonathan_holt: I thought JSON-LD 1.1 was still draft? so it's hard. It's heavy handed on JSON-LD, I have reservations 17:40:33 selfissued: is this all to prevent name conflicts at the json level? 17:40:44 JSON Schema is used to protect "Pure JSON" 17:40:46 i think the use of scoped terms should be a SHOULD not a MUST 17:40:48 manu: at the JSON-LD level. The JSON level will probably be enforced by json schema 17:41:02 ... this is a mechanism for the json-ld only people to ensure that won't happen 17:41:21 selfissued: then we can move on, but the way you avoid name conflicts in json is by registring the name, so it's the registry that eliminates the conflicts 17:41:26 manu: this is for machine processing, not human processing 17:41:38 ... the goal is to make this stuff machine enforceable and this assures that it's machien enforceable in json-ld 17:41:40 q? 17:41:41 q+ 17:42:11 q- 17:42:20 manu: okay, skipping this one, needs more discussion 17:42:27 ... last one, the DID Method Registry will be included 17:42:36 q+ 17:42:40 ... right now the CCG has it as a separate document. We should include it in the DID Core Registries 17:42:43 "in the DID core registries" 17:42:43 ... objections? 17:42:48 selfissued: into this "set of registries" 17:43:08 manu: "The DID Method registry will be included into this set of registries." objections? 17:43:10 ... checking that 17:43:23 ... Let's try to address the easiest things 17:43:41 markus_sabadello: can we propose to add things to the list? 17:44:02 ... Similar to the last item, a DID parameter registry will be included or added (this is independant of the matrix params, could be query params) 17:44:16 manu: to be clear, the DID parameters, one way of expressing them is through matrix parameters? 17:44:41 markus_sabadello: that's not decided, ongoing discussion. Even if they're removed there will still be something called DID parameters, independantly of how the syntax is implemented. There is a list of them in the spec right now, perhaps that should be in the registry 17:44:53 manu: added to the list. objections? 17:45:08 ... Now the remaining 3 17:45:21 q+ to suggest "JSON-LD Contexts MUST use scoped terms and the @protected feature to eliminate the possibility of term conflicts." => "JSON-LD Contexts SHOULD use scoped terms and MUST use the @protected feature to eliminate the possibility of term conflicts." 17:45:24 ... Easiest, the JSON-LD restriction, must use scoped terms and the @protected feature 17:45:39 ack markus_sabadello 17:45:40 ack dlongley 17:45:40 dlongley, you wanted to suggest "JSON-LD Contexts MUST use scoped terms and the @protected feature to eliminate the possibility of term conflicts." => "JSON-LD Contexts SHOULD use 17:45:43 ... scoped terms and MUST use the @protected feature to eliminate the possibility of term conflicts." 17:45:48 All this is good for now. Eventually we will need to name and talk individually about the various registries to keep it clear which statements and actions apply to which registry 17:45:54 dlongley: My suggestion is to make the use of scoped terms a SHOULD to allow flexibility for cases where it's just not gonna work, but keep the MUST on @protected 17:46:11 manu: I've updated it 17:46:14 dlongley: I agree to that 17:46:20 manu: any objections or concerns? 17:46:33 q+ 17:46:35 jonathan_holt: I think the concern is how to enforce across either json-ld and the registries to make sure they're in sync 17:46:38 ack Orie 17:46:54 Orie: this registry of registries with these contexts defined here allows us to programatically ensure that property so long as this item is actually enforced 17:47:03 ... if we want to be able to ensure what we want, we need to agree to this for JSON-LD 17:47:34 q+ 17:47:35 jonathan_holt: I think the onus is on the JSON-LD ot update those protected terms based on the registry? My concern is about this mutable link as being the source of truth 17:48:03 ... to satisfy my reservation, a mitm attack or ssl proxy forging, i could redirect you to a different URL, change the namespaces and convince you 17:48:16 ... the way we handled it in hl7 is we had a url that went to the schema but we also included a system with the oid, example: 17:48:22 { "url" : "http://hl7.org/fhir/us/core/ValueSet/us-core-encounter-type", 17:48:22 "identifier" : [ 17:48:22 { 17:48:22 "system" : "urn:ietf:rfc:3986", 17:48:23 "value" : "urn:oid:2.16.840.1.113883.3.88.12.80.32" 17:48:23 } 17:48:53 q+ 17:48:56 ... the url would be jsonld @context parsing that includes a url link that has the protected fields. The system in this case is rfcs, very specific to the attributes. Could be a string that defined the attributes 17:49:04 ack Orie 17:49:30 Orie: I think that sub resource intengrity checking or other mechanisms for ensuring the uri is coupled to the machine readable defintions for all of the syntaxes is a secondary concern to the specific technologies we use for one 17:49:32 rrsagent, make logs public 17:49:35 q+ 17:49:35 rrsagent, draft minutes 17:49:35 I have made the request to generate https://www.w3.org/2020/03/05-did-minutes.html manu 17:49:42 ... for cbor we're going to have some differences for how we'll ensure integrity for cbor 17:49:56 ... I agree with what jonathan_holt is saying, we need to tackle that subsequent to defining that there's a uri and a document that is resolvable 17:50:19 dlongley: my understanidng of these registries is the literal contnet of a json-ld context or jsonschema would go into these registries so it could be hardcoded in these applications? 17:50:22 we are planning on doing that 17:50:24 manu: we are planning on doing that 17:50:31 so we don't have a MiTM problem. 17:50:41 +1 to integrity mgmt being out of scope' 17:50:48 selfissued: discussions of how to ensure integrity of the references should be out of scope right now. we could hoste signed versions or all sorts of stuff, let's not overcomplicate 17:51:11 manu: just to close this set of thoughts out, we did have to deal with this in the VC spec. We specified a resource integrity hash and provided a static version of the document and said it wouldn't change 17:51:19 ... I expect we'll do something similar here, but we need time to figure it out 17:51:24 ... We need to discuss that in parallel 17:51:33 ... Now we've had that discussion, does anyone object to this text? 17:51:56 jonathan_holt: the onus is on JSON-LD.. that's one way of solving the problem if you're using jsonld context 17:51:59 the onus is on the entity submitting to the registries 17:52:00 manu: that is true 17:52:04 q+ 17:52:10 q- later 17:52:11 ... we're recommending that as a minimum thing 17:52:22 ack selfissued 17:52:25 ack dlongley 17:52:43 dlongley: the onus is on whoever is submitting to the registry to make sure they have a valid json ld context that applies to the rules, and whoever is managing the registry to make sure that's true 17:52:48 ... strange to say the onus is on the technology 17:52:53 ... onus is on maintaner to make sure the rules are enforced 17:53:02 manu: any further concerns or objections? 17:53:30 jonathan_holt: more just brainstorming how to keep things in sync. If you want to use jsonld context and protected fields that's fine, but if you want to use json onl yand point to a URI to say here's how you do that, .. 17:53:39 manu: we're talking specifically about JSON-LD not JSON 17:53:46 we need to get through the list. 17:53:51 please stop derailing us. 17:54:02 jonathan_holt: I'm concerned because it's about JSON-LD, I want to have a more broader discussion about how to solve it 17:54:17 manu: we need to have that, but it's not necessarily this discussion 17:54:29 jonathan_holt: should have protected fields, great way to solve that 17:54:58 manu: Remaining - link via URL to specification for that property 17:55:01 ... other one is sub namespace item 17:55:05 ... not sure which is easier 17:55:12 ... Let's take the link 17:55:15 q+ 17:55:16 in case there's a misunderstanding here ... if you want to use the registries you have to provide for every representation (which includes JSON-LD) so we can have lossless transformation 17:55:19 q+ 17:55:36 ack selfissued 17:55:53 selfissued: it might make this less ambiguous if we added text of the kind "a URL to the definiing specification so that programmers can find it to implement it" 17:56:04 Orie: that language I find it useful 17:56:24 ... A note that one of the kinds of link sthat we'll be adding are links to normative language for things in the DID COre specification, because the registries is a Note 17:56:38 ... hypothetical external links could be to the iana jose registry, and links to other w3c registries that might exist in the future 17:57:16 q+ to allow URI such as urn:ietf:rfc:3986 as an example that points to a specific registry of appropriate properties 17:57:16 manu: updating to mike's text 17:57:20 ack Orie 17:57:23 ack jonathan_holt 17:57:23 jonathan_holt, you wanted to allow URI such as urn:ietf:rfc:3986 as an example that points to a specific registry of appropriate properties 17:57:26 ... "Any addition to the DID Core Registries MUST link, via a URL, to the defining specification so that implementers can implement the property." 17:57:29 q+ to close the call. 17:57:43 jonathan_holt: here's an example pointing to a URN (which is a URI) which goes to the spec that describes all the values 17:57:49 ... that solves our problem just allowing URIs 17:58:05 selfissued: that's not resolvable 17:58:09 I object to URIs... it should be a link that works in a browser. 17:58:10 jonathan_holt: most people would know where you go to download it 17:58:21 put a URI in AND a URL so you say where it is... if you want a URI in there, you must ALSO put a URL. 17:58:30 selfissued: there's a url for that rfc, i don't know why you want that URI 17:58:38 jonathan_holt: you could use a URL too 17:58:48 manu: we're out of time, thank you for the discussion we got through a lot more than I expected 17:58:52 ... We have two items to clear off the list 17:58:57 ... During our next call we'll keep going through this 17:59:08 ... Try to think of some modifications that you could make that would make you happy 17:59:10 "most people know where to look" <-- then the "most person" submitting to the registries could put the URL in there too :) 17:59:10 Thanks! 17:59:13 ... Thanks everyone for the call 17:59:22 rrsagent, draft minutes 17:59:22 I have made the request to generate https://www.w3.org/2020/03/05-did-minutes.html burn 17:59:26 charlescunningham has left #did 17:59:34 rrsagent, make logs public 18:00:18 rrsagent, bye 18:00:18 I see no action items