16:56:16 <RRSAgent> RRSAgent has joined #did
16:56:16 <RRSAgent> logging to https://www.w3.org/2020/03/05-did-irc
16:56:41 <burn> burn has changed the topic to: DID special topic call: registries
16:58:08 <burn> present+
16:58:17 <chriswinc> present+
16:58:31 <burn> Meeting: Special Topic DID call (registries)
16:59:46 <Eugeniu_Rusu> Eugeniu_Rusu has joined #did
17:00:42 <Orie> Orie has joined #did
17:00:44 <jonathan_holt> jonathan_holt has joined #did
17:00:45 <Orie> present+
17:00:56 <Eugeniu_Rusu> present+
17:00:56 <burn> https://lists.w3.org/Archives/Member/member-did-wg/2020Mar/0000.html
17:01:02 <jonathan_holt> present+ jonathan_holt
17:01:15 <rhiaro> present+
17:01:18 <rhiaro> scribe+ rhiaro
17:01:30 <charlescunningham> charlescunningham has joined #did
17:01:40 <selfissued> selfissued has joined #did
17:01:41 <charlescunningham> present+
17:01:44 <selfissued> present+
17:02:03 <dlongley> present+
17:02:11 <Orie> See proposal here: https://github.com/w3c/did-core-registry/issues/3
17:02:25 <rhiaro> burn: this is a discussion, we're not taking decisions
17:02:41 <dlongley> see also: https://github.com/w3c/did-core-registry/issues/13
17:02:49 <rhiaro> ... 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 <dlongley> for a task list
17:03:26 <Orie> And regarding normative definitions: https://github.com/w3c/did-core-registry/issues/9
17:04:04 <burn> burn has changed the topic to: Registries call (https://lists.w3.org/Archives/Member/member-did-wg/2020Mar/0000.html)
17:04:23 <rhiaro> 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 <rhiaro> ... 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 <rhiaro> ... there are a couple of key themes to consider
17:05:04 <rhiaro> ... one is the mechanism for ensuring the registry dfns are valid internally, machine readable as much as we can
17:05:25 <manu> q+ to remind people to present+ and to outline the list of things we need to decide on.
17:05:33 <rhiaro> ... 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 <yancy> present+
17:05:49 <rhiaro> ... 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 <rhiaro> ... I'd love to be able to take advantage of that
17:06:15 <manu> present+
17:06:21 <rhiaro> ... historically we've had jsonld machine readable defintions for the concept of a registry
17:06:45 <rhiaro> ... 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 <burn> q?
17:07:03 <selfissued> q+
17:07:05 <manu> ack manu
17:07:05 <Zakim> manu, you wanted to remind people to present+ and to outline the list of things we need to decide on.
17:07:06 <burn> ack manu
17:07:08 <markus_sabadello> markus_sabadello has joined #did
17:07:10 <markus_sabadello> present+
17:07:14 <rhiaro> manu: +1 to everything Orie said
17:07:16 <JoeAndrieu> JoeAndrieu has joined #did
17:07:24 <JoeAndrieu> present+
17:07:35 <rhiaro> ... 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 <rhiaro> ... We have to come to consensus on some core principles
17:07:58 <rhiaro> ... 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 <manu> https://github.com/w3c/did-core-registry/issues/13
17:08:13 <rhiaro> ... I would like to go through this ^
17:08:20 <rhiaro> ... 16 items to discuss and/or agree or debate
17:08:36 <rhiaro> ... 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 <rhiaro> ... that list contains a number of things Orie said as well as other detailed things
17:08:53 <rhiaro> ... Clarifying questions?
17:09:24 <rhiaro> ... 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 <manu> q?
17:09:25 <selfissued> I'm going to use https://www.iana.org/assignments/jose/jose.xhtml as an example when I speak
17:09:31 <rhiaro> Orie: I think your issue is a better place to start
17:09:32 <manu> q+ to go through #13
17:09:54 <rhiaro> selfissued: one foundational thing is we need to start using terminology the same way
17:10:07 <manu> yes, this is a set of registries.
17:10:08 <rhiaro> ... referring to 'the registry' is misleading because per example the example I just put in the chat, the jose registries document
17:10:13 <rhiaro> ... take 5 seconds to see that
17:10:33 <rhiaro> ... 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 <rhiaro> ... 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 <rhiaro> ... 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 <rhiaro> ... we should start using that terminology
17:11:26 <rhiaro> ... 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 <burn> q+
17:11:39 <burn> ack selfissued
17:11:51 <rhiaro> 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 <Orie> yes, thats the intention
17:11:54 <manu> q- later
17:12:12 <rhiaro> burn: I agree with mike, I want to point out something a little strange about our conversation
17:12:34 <rhiaro> ... 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 <rhiaro> ... 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 <rhiaro> ... I agree with you mike, we are going to have multiple registries becasue there will be different types of information
17:13:12 <rhiaro> ... how they're represented may be confusing in the end
17:13:24 <rhiaro> ... there may be one document that contains multiple registries that themselves contain entries
17:13:39 <rhiaro> ... 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 <rhiaro> selfissued: that's fine, I jsut want us to use consistent terminology
17:13:55 <manu> q?
17:13:58 <manu> ack burn
17:14:02 <rhiaro> manu: with that, if there are no objections to what mike and dan just said, let's get into the list
17:14:04 <manu> https://github.com/w3c/did-core-registry/issues/13
17:14:08 <rhiaro> ... I'm going to read through the list
17:14:20 <rhiaro> ... there are going to be multiple people objecting to multiple items on this list
17:14:30 <rhiaro> ... I want to explain why each item is there and then we can go back through and determine any objections
17:14:44 <rhiaro> ... The first 3 are checked, we had consensus at the f2f to do at least these things
17:14:56 <rhiaro> ... 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 <rhiaro> ... it says DID core registry, but read that as DID core registries
17:15:16 <rhiaro> ... read registry as registries
17:15:33 <rhiaro> ... There are a set of things we need to agree to, and then a set of things we need to *do*
17:15:38 <rhiaro> ... first list is agree to, second is to do
17:15:48 <rhiaro> ... First item is something I believe we got consnesus on at the f2f
17:15:55 <rhiaro> ... 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 <rhiaro> ... the latter part might be controversial
17:16:08 <rhiaro> ... second: Any addition to the DID Core Registry MUST specify a machine readable JSON-LD Context for the property.
17:16:20 <rhiaro> ... 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 <burn> q+
17:16:35 <rhiaro> ... this is a best practice and people assume it, but I thought it'd be best if we state it explicitly
17:16:38 <rhiaro> ... next: Any addition to the DID Core Registry MUST specify a non-normative JSON Schema for the property.
17:16:56 <rhiaro> ... this is something that orie raised at the beginning of the call, it allows some level machine verification of the json
17:17:02 <rhiaro> ... lets us automate some of the checking instead of relying on humans
17:17:09 <rhiaro> ... 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 <rhiaro> ... this has to do with did methods and how they might expand upon the registry
17:17:28 <rhiaro> ... we could do it in a variety of ways
17:17:39 <rhiaro> ... kitchen sink approach like schema.org, has a number of downsides
17:17:48 <rhiaro> ... we want to enable did methods to operate independantly but still have a place to register all of those items
17:17:53 <rhiaro> ... next item is Properties in the DID Core Registry MUST NOT be removed, only deprecated.
17:17:53 <selfissued> q+
17:18:14 <rhiaro> ... 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 <rhiaro> ... next: JSON-LD Contexts MUST NOT be date stamped. The Verifiable Credentials will need to be fixed.
17:18:34 <rhiaro> ... goes back to a decision made previously in the did wg, trying to apply something consistent to all of these
17:18:43 <rhiaro> ... definitely not what the VC spec did. We may want to revisit that decision
17:18:58 <rhiaro> ... 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 <rhiaro> ... next: JSON-LD Contexts MUST use scoped terms and the @protected feature to eliminate the possibility of term conflicts.
17:19:19 <rhiaro> ... this is to ensure that people don't step on each others toes and create some machine level enforcement of that
17:19:25 <rhiaro> ... works in concert with the json schema stuff
17:19:31 <rhiaro> ... the last one is: The DID Method registry will be included in this registry.
17:19:41 <rhiaro> ... the DID method registry is maintained by the CCG
17:19:57 <rhiaro> ... 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 <dlongley> q?
17:20:08 <rhiaro> ... The subsequent list depends on us agreeing on a subset of these items
17:20:09 <manu> ack manu
17:20:09 <Zakim> manu, you wanted to go through #13
17:20:36 <rhiaro> 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 <rhiaro> ... 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 <rhiaro> ... 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 <manu> ack burn
17:21:30 <manu> ack selfissued
17:21:39 <rhiaro> selfissued: one of them uses terminology that's not understood by me
17:21:48 <rhiaro> ... What do you mean by MUST be place in a sub namespace? Must be at a URL?
17:22:04 <rhiaro> manu: Yes. There's an example there
17:22:13 <rhiaro> ...  https://www.w3.org/ns/did/btcr/ and https://www.w3.org/ns/did/btcr/(v1|v2|v3).
17:22:16 <markus_sabadello> q+
17:22:23 <rhiaro> ... BTCR may be doing things other DID methods don't do so it gets its own context file
17:22:33 <rhiaro> ... a sub namespace via a URL that contains the BTCR only properties as well
17:22:52 <rhiaro> 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 <rhiaro> ... These are just URLs that have to be distinct
17:23:05 <manu> q?
17:23:07 <jonathan_holt> q+ to add URI
17:23:14 <rhiaro> selfissued: asking people to put these at w3c namespaces is onerous
17:23:44 <manu> q+ to respond to selfissued -- URLs don't have to be at W3C
17:23:54 <markus_sabadello> sorry audio problem, go ahead in the queue
17:23:56 <markus_sabadello> q-
17:24:08 <rhiaro> jonathan_holt: I think a URI rather than a URL..
17:24:12 <dlongley> 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 <rhiaro> 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 <Orie> I prefer URL.
17:25:08 <Orie> some echo...
17:25:10 <rhiaro> ... 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 <rhiaro> ... 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 <rhiaro> ... 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 <rhiaro> 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 <rhiaro> ... that's normal. Any healthy registry is going to have entries made by other organisations if the technology is vibrant
17:27:31 <rhiaro> ... 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 <rhiaro> ... the only thing that's centralised is presentation
17:27:43 <rhiaro> ... references to the definitions
17:27:43 <dlongley> q-
17:27:45 <manu> ack jonathan_holt
17:27:45 <Zakim> jonathan_holt, you wanted to add URI
17:27:48 <manu> q+ markus_sabadello
17:28:03 <manu> q- later
17:28:05 <manu> ack markus_sabadello
17:28:06 <Orie> I agree that the did-core-registries will link to external sources, including IETF, W3C, etc....
17:28:38 <rhiaro> 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 <rhiaro> manu: those are all very good questions
17:28:50 <rhiaro> ... since the queue is exhausted if we want to go through each one of these items one by one now?
17:28:57 <rhiaro> ... any objections?
17:29:21 <rhiaro> 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 <dlongley> instead of "objections" just say you want discussion
17:29:48 <rhiaro> 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 <rhiaro> ... if you object please be ready to say how you'd change it
17:30:18 <rhiaro> ... First one; human readable description of property and point to appropriate spec
17:30:31 <rhiaro> selfissued: i object to the wrong terminology. Needs to be changed to plural
17:30:40 <rhiaro> manu: going to go in and modify to say registries really quickly
17:31:21 <rhiaro> ... and I expect we need an item to rename the title of the repo to say registries
17:31:24 <burn> 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 <rhiaro> ... First item: title should be changed to DID Core Registries. Any objections?
17:31:59 <rhiaro> ... Nope, checked the box
17:32:08 <rhiaro> ... Next, human readable description and poitn to spec. Any objections?
17:32:10 <rhiaro> jonathan_holt: define point?
17:32:15 <rhiaro> manu: a link, a URL
17:32:20 <rhiaro> jonathan_holt: I object
17:32:25 <rhiaro> ... a URI would be fine
17:32:38 <JoeAndrieu> q+
17:32:44 <rhiaro> ... you're specifying a protocol, there are plenty of other identifiers that satisfy the same functionalty
17:32:44 <manu> ack manu
17:32:44 <Zakim> manu, you wanted to respond to selfissued -- URLs don't have to be at W3C
17:32:47 <manu> ack JoeAndrieu
17:32:48 <selfissued> q+
17:33:18 <rhiaro> 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 <burn> q+
17:33:28 <rhiaro> jonathan_holt: defining resolvable is the next thing.. not just points, point and resolve
17:33:35 <rhiaro> ... you can do that with oids
17:33:40 <selfissued> q+
17:33:48 <manu> ack selfissued
17:33:49 <rhiaro> manu: I updated it to break this out and make the second item simpler
17:33:55 <rhiaro> selfissued: the link that programmers use to go read the spec
17:34:01 <Orie> Lets not bring other protocols into world wide web consortium registry.... it needs to be something that works in a browser
17:34:05 <rhiaro> ... if you can't follow the link the programmer doens't know how to implement the registry entry
17:34:16 <rhiaro> ... 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 <rhiaro> ... 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 <rhiaro> ... this is for programmers
17:34:44 <manu> ack burn
17:34:45 <Orie> Feel free to use a gateway: https://example-gateway.com/ipfs/QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy
17:35:07 <rhiaro> 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 <rhiaro> manu: +1. In this case i've split it into two where we agree one and not the other
17:35:26 <rhiaro> ... the second item is now, must specify human readable. Any objection?
17:35:35 <rhiaro> ... that's checked. Skipping the URL one.
17:35:52 <rhiaro> ... 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 <rhiaro> jonathan_holt: I have reservations, not objections
17:36:00 <rhiaro> manu: that's remaining checked
17:36:17 <rhiaro> ... Any addition must link the machine readable context to the human readable description. This is best practice, and agreed at f2f
17:36:20 <rhiaro> ... objections?
17:36:26 <rhiaro> ... hearing none, staying checked
17:36:37 <rhiaro> ... Any addition must specify a non-normative json schema for the properties
17:36:39 <rhiaro> ... objections?
17:36:43 <rhiaro> selfissued: why non normative?
17:37:01 <Orie> because the the registry is a note not a specification.
17:37:05 <rhiaro> 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 <rhiaro> selfissued: I'm okay with the language provided you put in a parenthetical saying it's the spec that is normative
17:37:23 <rhiaro> manu: any objections to the parenthetical?
17:37:38 <rhiaro> ... the specific text is "(the specification is normative)"
17:37:40 <rhiaro> selfissued: sure
17:37:56 <rhiaro> 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 <rhiaro> ... checking
17:38:10 <rhiaro> ... Any addition must be placed in a sub namespace if it isn't in the DID core registry
17:38:17 <Orie> this applies to ethereum and bitcoin
17:38:21 <Orie> and also sidetree
17:38:22 <rhiaro> selfissued: the last bit is confusing and not actionable
17:38:33 <rhiaro> manu: next - properties must not be removed, only deprecated. Objections?
17:38:41 <rhiaro> ... checking that.
17:38:48 <rhiaro> ... JSON-LD contexts must not be datestamped
17:39:02 <rhiaro> selfissued: I object to the second sentence because it's out of scope
17:39:09 <rhiaro> manu: striking that, any objections to striking that?
17:39:18 <rhiaro> ... any objections to the first part?
17:39:24 <rhiaro> ... checking that
17:39:35 <rhiaro> ... JSON-LD contexts must use scope terms and the @protected feature. Objections?
17:39:54 <rhiaro> markus_sabadello: This would preclude the use of JSON-LD 1.0
17:40:04 <rhiaro> selfissued: I don't understand this well enough to evaluate it
17:40:20 <rhiaro> 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 <rhiaro> selfissued: is this all to prevent name conflicts at the json level?
17:40:44 <Orie> JSON Schema is used to protect "Pure JSON"
17:40:46 <dlongley> i think the use of scoped terms should be a SHOULD not a MUST
17:40:48 <rhiaro> manu: at the JSON-LD level. The JSON level will probably be enforced by json schema
17:41:02 <rhiaro> ... this is a mechanism for the json-ld only people to ensure that won't happen
17:41:21 <rhiaro> 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 <rhiaro> manu: this is for machine processing, not human processing
17:41:38 <rhiaro> ... the goal is to make this stuff machine enforceable and this assures that it's machien enforceable in json-ld
17:41:40 <manu> q?
17:41:41 <dlongley> q+
17:42:11 <dlongley> q-
17:42:20 <rhiaro> manu: okay, skipping this one, needs more discussion
17:42:27 <rhiaro> ... last one, the DID Method Registry will be included
17:42:36 <markus_sabadello> q+
17:42:40 <rhiaro> ... right now the CCG has it as a separate document. We should include it in the DID Core Registries
17:42:43 <dlongley> "in the DID core registries"
17:42:43 <rhiaro> ... objections?
17:42:48 <rhiaro> selfissued: into this "set of registries"
17:43:08 <rhiaro> manu: "The DID Method registry will be included into this set of registries." objections?
17:43:10 <rhiaro> ... checking that
17:43:23 <rhiaro> ... Let's try to address the easiest things
17:43:41 <rhiaro> markus_sabadello: can we propose to add things to the list?
17:44:02 <rhiaro> ... 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 <rhiaro> manu: to be clear, the DID parameters, one way of expressing them is through matrix parameters?
17:44:41 <rhiaro> 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 <rhiaro> manu: added to the list. objections?
17:45:08 <rhiaro> ... Now the remaining 3
17:45:21 <dlongley> 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 <rhiaro> ... Easiest, the JSON-LD restriction, must use scoped terms and the @protected feature
17:45:39 <manu> ack markus_sabadello
17:45:40 <manu> ack dlongley
17:45:40 <Zakim> 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 <Zakim> ... scoped terms and MUST use the @protected feature to eliminate the possibility of term conflicts."
17:45:48 <burn> 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 <rhiaro> 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 <rhiaro> manu: I've updated it
17:46:14 <rhiaro> dlongley: I agree to that
17:46:20 <rhiaro> manu: any objections or concerns?
17:46:33 <Orie> q+
17:46:35 <rhiaro> 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 <manu> ack Orie
17:46:54 <rhiaro> 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 <rhiaro> ... if we want to be able to ensure what we want, we need to agree to this for JSON-LD
17:47:34 <Orie> q+
17:47:35 <rhiaro> 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 <rhiaro> ... 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 <rhiaro> ... 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 <jonathan_holt> {  "url" : "http://hl7.org/fhir/us/core/ValueSet/us-core-encounter-type",
17:48:22 <jonathan_holt>   "identifier" : [
17:48:22 <jonathan_holt>     {
17:48:22 <jonathan_holt>       "system" : "urn:ietf:rfc:3986",
17:48:23 <jonathan_holt>       "value" : "urn:oid:2.16.840.1.113883.3.88.12.80.32"
17:48:23 <jonathan_holt>     }
17:48:53 <dlongley> q+
17:48:56 <rhiaro> ... 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 <manu> ack Orie
17:49:30 <rhiaro> 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 <manu> rrsagent, make logs public
17:49:35 <selfissued> q+
17:49:35 <manu> rrsagent, draft minutes
17:49:35 <RRSAgent> I have made the request to generate https://www.w3.org/2020/03/05-did-minutes.html manu
17:49:42 <rhiaro> ... for cbor we're going to have some differences for how we'll ensure integrity for cbor
17:49:56 <rhiaro> ... 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 <rhiaro> 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 <Orie> we are planning on doing that
17:50:24 <rhiaro> manu: we are planning on doing that
17:50:31 <dlongley> so we don't have a MiTM problem.
17:50:41 <Orie> +1 to integrity mgmt being out of scope'
17:50:48 <rhiaro> 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 <rhiaro> 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 <rhiaro> ... I expect we'll do something similar here, but we need time to figure it out
17:51:24 <rhiaro> ... We need to discuss that in parallel
17:51:33 <rhiaro> ... Now we've had that discussion, does anyone object to this text?
17:51:56 <rhiaro> 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 <dlongley> the onus is on the entity submitting to the registries
17:52:00 <rhiaro> manu: that is true
17:52:04 <dlongley> q+
17:52:10 <dlongley> q- later
17:52:11 <rhiaro> ... we're recommending that as a minimum thing
17:52:22 <manu> ack selfissued
17:52:25 <manu> ack dlongley
17:52:43 <rhiaro> 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 <rhiaro> ... strange to say the onus is on the technology
17:52:53 <rhiaro> ... onus is on maintaner to make sure the rules are enforced
17:53:02 <rhiaro> manu: any further concerns or objections?
17:53:30 <rhiaro> 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 <rhiaro> manu: we're talking specifically about JSON-LD not JSON
17:53:46 <Orie> we need to get through the list.
17:53:51 <Orie> please stop derailing us.
17:54:02 <rhiaro> 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 <rhiaro> manu: we need to have that, but it's not necessarily this discussion
17:54:29 <rhiaro> jonathan_holt: should have protected fields, great way to solve that
17:54:58 <rhiaro> manu: Remaining - link via URL to specification for that property
17:55:01 <rhiaro> ... other one is sub namespace item
17:55:05 <rhiaro> ... not sure which is easier
17:55:12 <rhiaro> ... Let's take the link
17:55:15 <selfissued> q+
17:55:16 <dlongley> 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 <Orie> q+
17:55:36 <manu> ack selfissued
17:55:53 <rhiaro> 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 <rhiaro> Orie: that language I find it useful
17:56:24 <rhiaro> ... 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 <rhiaro> ... 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 <jonathan_holt> 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 <rhiaro> manu: updating to mike's text
17:57:20 <manu> ack Orie
17:57:23 <manu> ack jonathan_holt
17:57:23 <Zakim> 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 <rhiaro> ... "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 <manu> q+ to close the call.
17:57:43 <rhiaro> 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 <rhiaro> ... that solves our problem just allowing URIs
17:58:05 <rhiaro> selfissued: that's not resolvable
17:58:09 <Orie> I object to URIs... it should be a link that works in a browser.
17:58:10 <rhiaro> jonathan_holt: most people would know where you go to download it
17:58:21 <dlongley> 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 <rhiaro> selfissued: there's a url for that rfc, i don't know why you want that URI
17:58:38 <rhiaro> jonathan_holt: you could use a URL too
17:58:48 <rhiaro> manu: we're out of time, thank you for the discussion we got through a lot more than I expected
17:58:52 <rhiaro> ... We have two items to clear off the list
17:58:57 <rhiaro> ... During our next call we'll keep going through this
17:59:08 <rhiaro> ... Try to think of some modifications that you could make that would make you happy
17:59:10 <dlongley> "most people know where to look" <-- then the "most person" submitting to the registries could put the URL in there too :)
17:59:10 <Orie> Thanks!
17:59:13 <rhiaro> ... Thanks everyone for the call
17:59:22 <burn> rrsagent, draft minutes
17:59:22 <RRSAgent> I have made the request to generate https://www.w3.org/2020/03/05-did-minutes.html burn
17:59:26 <charlescunningham> charlescunningham has left #did
17:59:34 <burn> rrsagent, make logs public
18:00:18 <burn> rrsagent, bye
18:00:18 <RRSAgent> I see no action items