16:37:51 RRSAgent has joined #did-topic 16:37:51 logging to https://www.w3.org/2021/03/11-did-topic-irc 16:37:54 RRSAgent, make logs Public 16:37:54 please title this meeting ("meeting: ..."), ivan__ 16:38:46 Meeting: DID WG Topic Call on did spec registries 16:38:46 Chair: brent 16:38:46 Date: 2021-03-11 16:38:46 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Mar/0002.html 16:51:59 TallTed has joined #did-topic 16:55:23 justin_r has joined #did-topic 16:59:06 cel has joined #did-topic 16:59:47 present+ 17:00:06 present+ 17:00:17 brent has joined #did-topic 17:00:32 present+ 17:01:31 markus_sabadello has joined #did-topic 17:01:36 present+ 17:01:51 present+ 17:01:56 present+ 17:03:01 scribe: cel 17:03:05 scribe+ cel 17:03:11 Topic: DID Spec registries 17:03:15 present+ 17:03:32 brent: my role to run the queue, encourage civility (rarely have need of that). 17:03:41 ... add yourself to the q, and let's get this meeting started. 17:03:43 q+ 17:04:01 brent: will Orie make it? 17:04:13 manu: unsure. ideal if he is here. texting him 17:04:23 jonathan_holt has joined #did-topic 17:04:30 ... will be right back. 17:05:00 ... sent him something. i can try to start a discussion. 17:05:14 https://github.com/w3c/did-spec-registries/pull/260 17:05:23 ... just listing things we need to discuss: one is waiting for us to provide feedback: the did3 did method ^ 17:05:24 present+ 17:05:31 ... the DID Core spec allows this (single-char DID methods). 17:05:41 ... there is mention about being concerned about this kind of stuff 17:05:53 ... their response is they shipped it; it needs to be in 17:06:06 q+ 17:06:06 ... are we going to restrict methods to be at least 2? characters? 17:06:12 ack manu 17:06:21 brent: Topic 1: possible constraints on DID method length 17:06:24 ack ivan 17:06:37 q+ 17:06:42 ivan: not that i like this did:3, but do we want to get into a normative change in the core spec, and reissue a CR? (not published yet, but right after) 17:06:42 q+ to note we could say registration process requires names longer than 2 characters 17:06:51 Orie has joined #did-topic 17:06:54 ... this is a normative change in the core spec. it allows to have one-character method name. 17:06:57 +1 to needing to change core spec in order to say no here 17:07:02 ack markus_sabadello 17:07:13 q+ drummond 17:07:22 drummond_ has joined #did-topic 17:07:24 present+ 17:07:26 q+ 17:07:28 markus_sabadello: i don't think anyone is suggesting a change to the DID Core spec to change the normative syntax of what is allowed or not. but there is a difference of what is allowed in the syntax and what is the policy on what is allowed in method names 17:07:41 There MIGHT be a difference, if the registry refused to accept conformant DIDs... 17:07:50 ... it could be to not change core spec, their did method would continue to function and be compliant, but doesn't mean it has to be accepted and listed in the registries 17:07:53 +1 to Markus's point 17:08:03 ack manu 17:08:03 manu, you wanted to note we could say registration process requires names longer than 2 characters 17:08:04 ... registries meant to help with interoperability, discoverability, etc., but no hard requirement to use it. 17:08:21 q+ 17:08:42 q+ 17:08:49 manu: agreeing with markus. might be talking about a process change to the registries process. strongly advise to use more than one character. registry may/will not list methods with single-characters. but grandfather in did:3. proposal to modify process 17:08:58 ack drummond 17:09:01 ack drummond_ 17:09:02 brent: have to get did:z written fast 17:09:31 drummond_: speaking from direct experience in another namespace. what we saw: single-char methods splattered on fast. 17:09:46 ... we strongly rued the fact that we had not set that policy. i was dismayed to find out about did:3 17:09:56 it does take quite a lot of work to squat a did method 17:10:04 ... just the fact that is out there - i would like to see documentation that it was/is actually in use 17:10:11 q+ to note that they did provide evidence. 17:10:15 q+ 17:10:15 ... could see that if they provide strong enough evidence, we could allow it 17:10:35 ... strongly feel we should set the policy. interestingly enough, ivan, i wasn't even thinking of changing the ABNF. since it would strictly be a registry policy. 17:10:39 ack TallTed 17:10:44 present+ orie 17:10:56 +1 TallTed 17:11:05 TallTed: i don't think we want to discourage people from registering their methods, because that will just encourage collission. it will be easy for other people to do another did:3, and then how do they resolve. 17:11:10 which is worse? squatting or collisions? 17:11:20 strong agreement 17:11:30 q+ 17:11:31 ... there are just too many problems that arise here. we want every did method to be registered. unfortunately, we can't care whether they have single char. 17:11:37 q+ to ask if we can require evidence of not squatting 17:11:38 I strongly disagree with Ted on this point. 17:11:39 ack jonathan_holt 17:11:43 ... to ensure the integrity of the system. discouraged to hear otherwise 17:11:54 ack manu 17:11:54 manu, you wanted to note that they did provide evidence. 17:12:04 jonathan_holt: don't see why it matters, one char, two, chars. don't think is policy needing to be enforced 17:12:32 manu: sounds like we are a bit split on this and maybe shouldn't tie up a bunch of time talking about. have more important things to discuss. i can't think of a proposal at this point that would pass. 17:12:47 PROPOSAL: accept any attempt to register a conformant method on a first come first serve basis 17:12:51 ... seeing objection to limiting it. i think everyone agrees we want people to register their methods. 17:12:58 ack Orie 17:13:04 ... sounds like we should convince people to register their methods 17:14:00 q+ to say we only want to encourage registration of legitimate methods 17:14:01 Orie: this ship sailed when we allowed DID Methods to be one character long and be valid. if not changing in core spec, i can't see attempt to block registering conformant did methods on a first-fcome first-seve basis. either create tremendous bias or allow existing methods to forever have higher ground. did:3 only single-char method: terrible. same for 2-char or other limits. strongly 17:14:03 object to blocking registration of methods conforming. 17:14:17 ... must allow them. there will be a mad dash. welcome to managing a namespace. 17:14:17 ack markus_sabadello 17:14:35 markus_sabadello: like manu's idea to allow this one, not prohibiting, but make a strong warning discouraging them 17:14:42 why discourage a thing that literally everyone will want... everyone wants short names.... 17:15:10 ... regarding opinion must use registry to avoid collision: not how it sohuld be. we should not consider the registry something that must be used. in charter, DID implementations must work without relying on a single registry 17:15:24 ack brent 17:15:24 brent, you wanted to ask if we can require evidence of not squatting 17:15:32 ... registry is utility makingn certain things easier, but DIDs, DID resolution and the ecosystem must also function if you don't use the registry. 17:15:49 brent: could we work it into the reg process to require evidence that they are not just name-squatting? 17:15:53 what brent said is already in the process isn't it? I thought they needed to be fully spec'd at least 17:15:56 ... +1 to running Orie's proposal 17:16:08 drummond_: will wait until after proposal 17:16:21 brent: anyone want to suggest modifications to proposal before formally running it? 17:16:33 ack drummond_ 17:16:33 drummond_, you wanted to say we only want to encourage registration of legitimate methods 17:17:06 +1 drummond... there are other things about trademarks, offensive language, etc aren't there 17:17:18 drummond_: maybe now reading it i'll reverse myself. maybe shoul have rest of call about what are going to be the policies to follow here. first come first serve: very basic, makes sense. but if don't look at in conjunction with rest of policies to apply. assuming orie's not talking about everything going in, should look at other policies to apply. 17:17:29 ... almost feels dangerous to start there. really need to look at the full body of policies 17:17:41 https://w3c.github.io/did-spec-registries/#the-registration-process 17:17:52 ... need to discuss not just each one individually, but all together. as said, welcome to managing a NS. 17:18:18 ... like the president of IBM saying would not be more than 3 computers. i thought there wouldn't be more than a dozen DID methods 17:18:41 PROPOSAL: accept any attempt to register a conformant method on a first come first serve basis 17:18:45 +1 17:18:50 +0.6 17:18:53 -1 17:18:57 0.9 17:19:07 0 17:19:11 0 17:19:12 the reason being that it's not specific enough yet 17:19:13 +0.75 I think we're rather painted into a corner 17:19:13 -1 without caveat about other registration policies also being met 17:19:16 cel: abstain 17:19:28 0 we have that already, we need to talk about policies, not order 17:19:28 q+ 17:19:39 brent: we have underwhelming support plus a couple -1s. 17:19:42 https://w3c.github.io/did-spec-registries/#the-registration-process 17:19:42 ack manu 17:19:51 q+ 17:20:01 manu: remind everyone we have a process. it has been edited a number of times. that is the process, you have to do all those things. a number of MUSTs and MUST NOTs 17:20:03 +1 if meeting the rest of the process is implicit 17:20:22 q- 17:20:30 +1 then 17:20:36 ... only thing we are talking about is that you must... difficult to find wording for this, want to abandon and more on. supposed to be a softball one while waited for Orie to join. sounds like people feel strongly about this. let's come back to it later 17:21:05 q+ 17:21:27 ... i don't think there is any real way we can stop. let's look at immediate decision: are we going to stop did:3 from being registered? i don't think so. there is proof they have been using it. i don't think we can stop it. suggestion is to let PR 260 to go through, as no variation would prevent them to be registered 17:21:28 but they did not register it with the then-registry, correct? 17:21:38 ... can come back to do we want a policy to restrict this stuff 17:21:56 ... proposal to allow PR 260, did:3 to be registered 17:22:15 brent: if anyone would like to speak out in opposition, add to q 17:22:16 ack ivan 17:22:46 +1 to ivan... there is no way to kick this can 17:22:48 or block it 17:22:59 ivan: going a bit further, i don't think there is any reason why we would not register that one. but once we do that, we have created a precedent. no real reason to allow this one and not something else. sortof too late. should forget about this question altogether 17:23:09 q+ 17:23:16 ... There may be some other discussions about the registration policy more generally, probably more important ones. 17:23:16 ack TallTed 17:23:47 TallTed: there was some statement that because DIDs should not be reliant on any central registry, there should not be reliance on this registry. i think registering methods is different from registering DIDs per-se. 17:24:08 ... part of the point of registering the method is so that people [...] can figure out which one satisfies their needs. 17:24:14 https://www.w3.org/2019/09/did-wg-charter.html - "These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, ..." 17:24:14 I'm afraid that is true - and sad - but I will point out that the did:3 people did not actually register with the then-registry... 17:24:17 q+ 17:24:20 ... not the same as reliance on a centralized registry that we try to prevent. 17:24:27 PROPOSAL: Allow did:3 to be registered in the DID Spec Registries -- pull in PR 260. 17:24:28 ack manu 17:24:30 +1 17:24:31 brent: manu dropped draft proposal 17:24:31 +1 17:24:33 +1 17:24:33 +1 17:24:33 +1 17:24:36 +1 17:24:39 +0.5 17:24:39 0 17:24:49 +1 17:25:06 0 17:25:18 RESOLVED: Allow did:3 to be registered in the DID Spec Registries -- pull in PR 260. 17:25:26 q+ to ask Orie what's next :) 17:25:33 ack manu 17:25:33 manu, you wanted to ask Orie what's next :) 17:25:53 manu: Orie, what do you feel is the next big set of decisions we need to make? i know there is one around the process. there is the new CDDL requirement. 17:26:08 The Registration Process currently states: "Properties defined in the DID Core Registries MUST include a Concise Data Definition Language (CDDL) [RFC8610] of the Property and its Abstract Data Model structure." 17:26:17 q+ to comment on registeration requirements 17:26:48 ... ^ that got in a while ago. now to register things, we require you to do a JSON-LD context and CDDL. we don't say anything about JSON Schema. My concern is that there are many more people who know JSON Schema than CDDL. 17:26:58 ... do we even want to require CDDL. anything higher priority? 17:27:00 q+ 17:27:04 Orie: i don't think so; that is the biggest one 17:27:04 ack Orie 17:27:04 Orie, you wanted to comment on registeration requirements 17:27:58 ... This issue comes up as we think about why do we register things. we register things because we want interoperability, to see it is registered, so that people don't invent new ways of doing the same thing. we want people to register stuff so they don't do slight variations of the same functionality. massively redundant. if difficult, they won't do it. 17:28:27 ... The purpose of registration is to help with the representations. because we have multiple representations. we needed a way to register things so we could see how your new registered feature works with those representations 17:28:49 ... JSON-LD context is not helpful for representations other than JSON-LD 17:29:07 ... problem where we can make the bar increase for each representation. increase the number of examples required 17:29:13 ... would block people from registering anything 17:29:39 ... if don't want people to register stuff, asking them to support all representations in their registrations is a good way. problem since beginning of WG, need to address it. 17:30:25 ... Proposal: for every registered representation that is defined in the core representation, you must provide some evidence to show that new properties work. only need to require examples. structural. non-core representations not required to support. 17:30:34 q? 17:30:41 q+ 17:30:44 ... willing to hear other proposals 17:30:50 ack jonathan_holt 17:31:06 q+ 17:31:10 jonathan_holt: if people want to chime in with other proposals, i can wait 17:31:20 q? 17:31:22 brent: can you give us the headline of the topic and we will come back to it 17:31:24 benefits of cddl 17:31:37 ack ivan 17:31:43 q+ to amplify Orie's thesis 17:32:16 q+ to note that any sort of schema language is representation specific to a degree -- and JSON-LD showing /one/ context may not be right. 17:33:02 ivan: want to separate two things. i think i understand and agree with what Orie said. for rep not defined in core spec, we sortof put them aside in terms of the reg process. question: how high is the bar today, and will it become a problem that any new properties that i introduce requires me to have JSON-LD and CDDL (and JSON Schema?) to become a registration? see reason, to give 17:33:03 ack manu 17:33:03 manu, you wanted to note that any sort of schema language is representation specific to a degree -- and JSON-LD showing /one/ context may not be right. 17:33:04 interoperability, but don't know if this will become an obstacle for people to register properties. 17:33:10 https://w3c.github.io/did-spec-registries/#controller 17:33:36 manu: looking at the registries right now. for every propery, we have three properties. the normative definition. strongly defensible. where do you define it. makes sense. 17:33:53 ... JSON-LD context: kindof makes sense. nice to have a context. but JSON folks might not really care. an argument for that. 17:34:03 ... where the WG got to is that they are so class, might as well have it 17:34:42 ... when it comes to schema languages: they are largely representation-specific. if have a json schema, say DIDs must be strings. if you try to apply against a CBOR-LD encoded DID document, it would fail. because CBOR-LD does semantic compression. would not pass CDDL for pure CBOR. 17:34:45 q+ 17:35:10 ... now into a position where we are saying that people have to provide schema checks against potentially every representation - at least the ones they care about. that is a very high bar 17:35:25 ... number of people who can right JSON-LD: less than JSON. CDDL: even less 17:36:09 ... My argument to not include any schema checking in the registries. that's not their purpose. in the registration, could have a see also section where people can list the schemas. or have it associated with the normative definition. purely optional, not required for registration 17:36:20 ... because we are trying to get people to register stuff. low bar. 17:36:22 ack drummond_ 17:36:22 drummond_, you wanted to amplify Orie's thesis 17:36:22 +1 manu 17:36:43 drummond_: i want to second the idea of both orie and manu that a registration should supply the appropriate schema 17:37:27 ... to support representations should supply the necessary detail in the associatd spec. must have spec and it must meet certain requirements. but agree it shouldn't be a requirement to produce a mapping that you have no interest in. should be encouraged. 17:37:28 +1 to what Drummond just said. 17:37:30 ack jonathan_holt 17:37:31 +1 17:37:46 q+ 17:38:23 jonathan_holt: to tote benefits of CDDL. too much credit that i learned it overnight, it's not that hard. it is a concise data definition language. json schema version 7 still draft. not normative yet. CDDL is a normatively described extension of ABNF rules. can right ABNF in CDDL. phenomenally expressive, and normative. 17:38:56 ... I understand the bar. having written JSON Schema for the VC spec, chasing my tail, it was moving so quickly, to figure out what was in or not in. JSON Schema was not the right approach there. 17:39:04 ... CDDL a superset of JSON 17:39:30 ... both JSON-LD as well as CBOR-LD are an expansion algorithm. taking the external dictionary of CBOR-LD, expanding it as you would in JSON-LD 17:39:38 ... get an RDF expansion. that is what needs to be modelled 17:39:55 Just to be clear, I am a big CDDL fan. I just don't think we need to *require* all new registry entries to provide mappings to all representations. We need to *encourage* that. 17:40:05 ... substitute the external dictionary, to get the same #1 means controller in the registry 17:40:19 ... how to get the expressitivity of the registry 17:40:21 Agree, CDDL is great -- if you have a community that knows how to use it and a representation that uses it -- we're not in that position. 17:40:28 q? 17:40:34 ack ivan 17:41:33 +1 to ivan 17:41:37 ivan: first of all, to react directly to what jonathan said. i don't think the issue here is whether CDDL is a good thing or bad thing. i think it is a good thing. but that is a different point. in the registry, the big difference between the context and the JSON-LD is that for JSON-LD to work with a given property, ou must have a way to say that this property maps onto that URL, because 17:41:39 this is what JSON-LD context is all about. essentially the only thing it does is tell you what thing maps to what URL. 17:41:57 +1 to ivan.. context is for semantic interop, not schema validation 17:42:03 +1 ivan 17:42:22 q+ 17:42:23 ... all the other things, are good things to have, help implementors. good citizen may want to do that as part of specification of property. but there have to draw line at what we require, and what recommend for good citizens to do 17:42:25 +1 to what Ivan just said. 17:42:27 ack markus_sabadello 17:43:06 It is true that we agreed in Amsterdam that a JSON-LD context must be provided. 17:43:06 markus_sabadello: +1. also what we said when decied to introduce the ADM and different representations, i thought that was the reason we had the resolution to introduce those things at the same time, and any newly registered property must provide a JSON-LD context, for the reasons ivan mentioned. 17:43:13 q+ 17:43:23 ack drummond_ 17:43:43 drummond_: i do think ivan has a good point. it also feels to me like the lightest of all the requirements, to just make sure that there is a mapping to unambiguous URLs for anything being proposed. 17:43:50 ... want to ask, is that a proposal we are making here? 17:44:01 ivan: can try 17:44:50 drummond_: asking for clarification. thought ivan was saying should still have JSON-LD requirement 17:44:55 ivan: JSON-LD is not a schema language 17:44:57 drummond_: ok 17:45:14 ivan: that is the mistake that was done in earlier discussion. schema language is [...] 17:45:39 s/[...]/shacl or shex for rdf 17:45:50 drummond_: want to make modification that we encourage ... 17:45:56 ... authors to do that 17:46:19 PROPOSAL: Remove the requirement in DID Spec Registries process to register any schema language (e.g., JSON Schema, SHACL, SHeX, CDDL) as a part of property registrations. The process will encourage providing schema languages for appropriate representations. 17:46:22 +1 17:46:22 +1 17:46:23 +1 17:46:24 +1 17:46:24 +1 17:46:26 +1 17:46:26 +.08 17:46:29 +1 17:46:32 +1 17:46:34 +1 17:47:09 "relevent" representations 17:47:20 manu: appropriate representations: for the languages for which they are appropriate 17:47:39 RESOLVED: Remove the requirement in DID Spec Registries process to register any schema language (e.g., JSON Schema, SHACL, SHeX, CDDL) as a part of property registrations. The process will encourage providing schema languages for appropriate representations. 17:47:51 q+ 17:47:57 ack drummond_ 17:47:59 brent: always good to make our editors happy 17:48:06 q+ to note rule 17:48:13 drummond_: reading through it... what is the rule around JSON-LD contexts, or do we need one? 17:48:14 https://w3c.github.io/did-spec-registries/#the-registration-process 17:48:21 q- 17:48:25 ivan: that stays, is not changed 17:48:34 See: https://github.com/w3c/did-spec-registries/issues/264 17:48:39 drummond_: editorial change: we should always number all the way down the list 17:48:54 brent: 12 minutes left on call 17:49:06 drummond_: proposal Orie editor-in-chief for life 17:49:10 q+ to throw the context bomb into the room. 17:49:16 brent: topics to bring up? 17:49:24 ack manu 17:49:24 manu, you wanted to throw the context bomb into the room. 17:49:49 q+ 17:49:52 q+ 17:50:00 manu: what goes into the v1 DID context. just stuff in the core spec, the things to make 80% of people's lives using it easier (crypto suites, linked domain stuff)? where do we draw the line? 17:50:12 ... We do need to define the context and what goes in it and what doesn't. 17:50:22 ivan: issue with minutes to get this recorded 17:50:30 https://github.com/w3c/did-spec-registries/issues/184 17:50:39 q+ to say the simplest line is just the things in did core 17:50:42 ack Orie 17:51:00 Orie: big one: i think we've learned a lot since the VC spec happened. i think the one thing i feel the strongest about is: you have to plan for v2 when you do v1. 17:51:06 +1 to plan for v2 when you do v1 17:51:12 ... We have to think about when will v2 exist; what will people do in the years between v1 and v2 17:51:24 ... How are we going to make that not super painful so that they feel the spec is usable 17:51:41 ... VC Data Model terrible in this regard. didn't have spec registries to float an unstable version number 17:51:58 I am actually serious that I have to drop a few mins early. Besides the topic Manu is raising, the other one we should focus on is determining what additional policies are needed for managing DID Spec Registries on an ongoing basis. 17:52:16 ... Proposal that we have a context that only represents DID Core terms, and a second one floated with version process, regularly cut releases as part of registry maintenance 17:52:18 q+ to note what we're doing w/ LD Cryptosuites 17:52:22 ack markus_sabadello 17:52:55 markus_sabadello: should crypto suites be in security vocab rather than did core? 17:53:12 ... like VCs to make VC context just about VC data model, have crypto suites, key types in the separate security context 17:53:29 ... wonder if also do that with DID core context. more a question than opinion 17:53:30 ack brent 17:53:30 brent, you wanted to say the simplest line is just the things in did core 17:53:43 q+ to note the issues with sec / vs suites /vs registry 17:53:47 q+ 17:53:49 brent: +1, simplest line to draw: this is what is in DID Core 17:53:58 ack manu 17:53:58 manu, you wanted to note what we're doing w/ LD Cryptosuites 17:54:01 ... extensibility to ease pain of maintaining VC spec 17:54:17 manu: the vc v1 context: we did not do a good job there. need to learn from mistakes made there. 17:54:31 ... glad to hear Orie say let's make this easier. trying to move away from kitchen sink contexts. 17:54:44 ... tried to do that in VC and it blew up 17:54:57 ... need to understand how people will use the DID Context. 17:55:18 ... some DID methods will use the base context and will layer their own context on it. leave it to the DID methods to specify what to include. 17:55:29 examples: https://w3id.org/security/bbs/v1 - https://w3id.org/security/jws/v1 - https://w3id.org/security/pgp/v1 17:55:32 ... presume they will have their own DID method context to layer on top. feels like a good middle ground. 17:56:01 ... Another extreme: we could make it so that every tiny little crypto suite is split into two things: the crypto suite stuff you would put in the DID document, and what you would put in the credential 17:56:15 q+ 17:56:16 ... context entry becomes 4,6,8+ entries deep. don't like that 17:56:28 ... would like a base DID context, and one up to the DID method that they can iterate at their own pace. 17:56:38 ack Orie 17:56:38 Orie, you wanted to note the issues with sec / vs suites /vs registry 17:57:32 ack ivan 17:57:38 Orie: +1 to what manu said, i think, the best way is to have the base context only thing in did core, method-specific context things the method has added, and any third ones specific to controller if allowed, other extensions, etc. probably should only have 2 or 3 urls in that list if you are doing it right. we should explain and recommend that as a best practice 17:57:39 +1 to what Orie just said. 17:57:55 This would be best : "https://www.w3.org/ns/did/v1" - "https://method.example/ns/did/v1" - "https://w3id.org/security/pgp/v1" 17:58:05 ivan: want to understand exactly what we say. base context: the v1 currently in our examples. what you mean is that that includes the properties and things only defined in the core document. is this what you mean? 17:58:12 q+ to reply 17:58:17 ... or it includes those and the registered properties? 17:58:38 ... for the time being, there are a bunch of things neither in core or registry - the security things. makes me more nervous 17:58:40 ack markus_sabadello 17:58:58 ack Orie 17:58:58 Orie, you wanted to reply 17:58:58 NOOOOOO do not nest contexts 17:59:05 markus_sabadello: another question for those who know this better: would we consider including other contexts in the did core context, e.g. the security context? 17:59:25 Orie: markus_sabadello: definitely not. one of my least favorite thing is waiting for deeply nested contexts to resolve 17:59:45 method extension contexts, currently seen in security vocab. after that, things not currently registered anywhere 17:59:46 q+ 17:59:59 ack ivan 18:00:07 ... context to include things in did core, things not defined in did core might be defined in method or seucirt vocab or somewhere else, and that is it 18:00:11 Which one of the three contexts above defines Ed25519VerificationKey2018? 18:00:47 I believe that this is what is being proposed: 18:00:47 "@context": [ 18:00:47 "https://www.w3.org/ns/did/v1", 18:00:47 "https://w3id.org/did-method-example/v2.1", 18:00:47 "https://w3id.org/some-extension-example/v3.4" 18:00:48 ] 18:01:00 ivan: one more issue. some of us will hopefully [...] working group for linked data signature. issue of security-related terms will come up there. we may end up with a context there. don't want them to end up in the core context of this WG. one more consideration to remember 18:01:08 markus_sabadello, the second one would deifne Ed25519VerificatioNKey2018 18:01:09 brent: closing the meeting. 18:01:21 ... thank you for your contributions 18:01:27 rrsagent, draft minutes 18:01:27 I have made the request to generate https://www.w3.org/2021/03/11-did-topic-minutes.html ivan 18:01:47 zakim, end meeting 18:01:47 As of this point the attendees have been ivan, cel, brent, markus_sabadello, rhiaro, TallTed, manu, jonathan_holt, drummond_, orie, .08 18:01:49 RRSAgent, please draft minutes 18:01:49 I have made the request to generate https://www.w3.org/2021/03/11-did-topic-minutes.html Zakim 18:01:52 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 18:01:56 Zakim has left #did-topic 18:02:27 rrsagent, bye 18:02:27 I see no action items