15:10:00 RRSAgent has joined #did 15:10:00 logging to https://www.w3.org/2020/12/08-did-irc 15:10:02 RRSAgent, make logs Public 15:10:03 please title this meeting ("meeting: ..."), ivan 15:10:07 Meeting: DID WG Telco 15:10:07 Chair: brent 15:10:07 Date: 2020-12-08 15:10:07 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020Dec/0003.html 15:10:07 ivan has changed the topic to: Meeting Agenda 2020-12-08: https://lists.w3.org/Archives/Public/public-did-wg/2020Dec/0003.html 15:39:06 TallTed has joined #did 15:58:16 justin_r has joined #did 15:58:44 present+ 15:58:49 present+ 15:59:15 present+ 16:00:11 present+ 16:00:45 markus_sabadello has joined #did 16:01:36 present+ 16:02:03 present+ 16:02:05 present+ 16:02:12 present+ 16:02:18 present+ drummond, manu, adrian, selfissued 16:02:18 selfissued has joined #did 16:02:21 agropper has joined #did 16:02:22 dmitriz has joined #did 16:02:28 present+ 16:02:30 present+ 16:02:34 present+ 16:02:43 regrets+ burn 16:03:34 present+ 16:03:35 present+ orie 16:03:39 scribe: manu 16:03:41 Orie has joined #did 16:03:42 scribe+ 16:03:44 present+ 16:03:56 drummond has joined #did 16:04:05 present+ 16:04:06 brent: Agenda today -- special topic call, issue 199, jump into issue processing P1 then P2 issues. 16:04:11 brent: Any additions to the agenda? 16:04:16 rrsagent, make logs public 16:04:20 rrsagent, draft minutes 16:04:20 I have made the request to generate https://www.w3.org/2020/12/08-did-minutes.html manu 16:04:37 Topic: Introductions and Reintroductions 16:04:58 brent: No new members, skipping introductions we all know each other 16:04:59 present+ 16:05:01 Topic: Special Topic Call 16:05:29 brent: Goal of call today is to finish up security/privacy questionnaire -- last session was very productive, please join if you feel that you can help us move forward and get that done. 16:05:35 https://github.com/w3c/did-core/issues/199 16:05:36 Eugeniu_Rusu has joined #did 16:05:36 jonathan_holt has joined #did 16:05:40 Topic: Issue 199 16:05:43 JoeAndrieu has joined #did 16:05:45 scribejs, issue 199 16:05:45 https://github.com/w3c/did-core/issues/199 16:06:05 Possibly last of the issues that need to be discussed -- at this point there are a few changes on how we could move forward 16:06:09 present+ jonathan 16:06:10 https://github.com/w3c/did-core/issues/199#issuecomment-738333023 16:06:11 present+ jonathan_holt 16:06:19 present+ JoeAndrieu 16:06:19 s/Possibly last/brent: Possibly last/ 16:06:31 present+ Eugeniu_Rusu 16:06:34 brent: Let's time box to 10 minutes to briefly discuss the issue -- clarification of what DIDs might identify 16:07:11 present+ identitywoman 16:07:13 brent: I feel awkward about talking about this -- I raised it, but doing my best to not do it w/ my Chair and/or company hat on. 16:07:27 identitywoman has joined #did 16:08:08 brent: This issue is about how to express information resources as part of information resource -- there are four possible ways of doing this -- define DID Document property to contain DID Subject, define new metadata category to return DID Subject, or define DID Resolution input metadata property to indicate that when DID is resolved, DID Subject should be returned rather than DID Document, or new DID Parameter. 16:08:17 brent: Jump on queue if you have suggestions/thoughts. 16:08:20 q? 16:08:30 q+ 16:08:31 q+ 16:08:36 scribe+ 16:08:38 ack manu 16:08:57 manu: could you outline a concrete use case? I believe it is something like you have a schema that has a DID associated with it and you want to return the schema and not the DID document, but I might be misunderstanding? 16:09:11 q+ 16:09:42 q+ 16:09:53 brent: Yes, we have an information resource that is a schema identified by DID -- it is the DID Subject, resolution of DID would like DID Subject returned in addition to information returned in DID Document... important to see who controls the subject, and that is information representation in DID Document... initial attempt was content property, which then turned into representation, then type, which turned into a bad idea... how can we do this? 16:09:54 ack agropper 16:10:19 agropper: I see this as a pure authorization problem. I know there's been discussion about this over the weekend... see this entirely as an authorization issue. 16:10:26 ack jonathan_holt 16:10:47 q+ to mention resolution w/o dereferencing 16:10:58 q+ to ask why this is an authorization issue? 16:11:04 jonathan_holt: How do we do this w/ authorization? In IPID method, create submethod name, schema, same thing when you resolve DID Document, you can also resolve schema... ipid:schema: ... that's how we were going to handle it -- how can we do this w/ authorization? 16:11:05 ack markus_sabadello 16:11:28 markus_sabadello: I'd be opposed to allowing resolution of a DID -- resolutin not dereferencing, when you resolve a DID you can't get anything other than a DID Document. 16:11:51 +1 to markus 16:11:55 by_caballero has joined #did 16:12:04 present+ 16:12:09 markus_sabadello: I would be open to saying that you resolve the DID and you get a DID Document, and that has a property that contains the subject... when you dereference a DID, you could get something other than the DID Document... we shouldn't change basic assumption, when you resolve a DID you get a DID Document. 16:12:11 ack JoeAndrieu 16:12:11 JoeAndrieu, you wanted to mention resolution w/o dereferencing 16:12:51 JoeAndrieu: It's important to be able to resolve w/o dereferencing -- this property wouldn't allow that when it's used... that seems to be a layer violation... could have impact on herd privacy. We should allow resolution as a distinct step from dereferencing. 16:12:54 ack drummond 16:12:54 drummond, you wanted to ask why this is an authorization issue? 16:12:55 brent: good feedback 16:12:59 q+ 16:13:14 drummond: I was going to ask why Adrian thought this was an authorization problem? 16:13:45 q+ 16:14:37 brent: It sounds like, of the options we went through -- Joe is uncomfortable w/ option #1... wondering now about option 3 - as part of resolution input metadata, the entity resolving DID -- also give me Information Resource identified by it, option 4, did parameter that is a URL that could be dereferenced to retrieve DID subject. 16:14:43 ack brent 16:14:45 Q+ 16:14:46 ack agropper 16:15:11 q+ 16:15:17 q+ to talk about the parameter for dereferencing and to mention that DID doc should NOT be considered public 16:15:28 ack markus_sabadello 16:15:30 agropper: the explanation is -- entirely consistent w/ resolution should be separate from dereferencing... DID Document is a public document in general... as far as spec is concerned, we should consider it to be public -- therefore, distinction between derefrencing needs to be protected by authorization step. 16:16:23 q+ 16:16:23 markus_sabadello: Small modification about option 3- input metadata property to request DID Document or DID Subject... if we could chang ethat to "dereferencing input metadata" resolving never returns anything other than DID Document... parameters or metadata properties --- derefrence the did, metadata property, could return something other than DID Document... not mutualy exclusive w/ option #4. 16:16:24 q+ 16:16:32 ack ivan 16:16:36 ivan: Listening to that, I don't understand the use case. 16:17:15 ivan: When you say it returns the schema... the method has the schema somehow in it's own database and it returns file containing schema, or does it return URL of schema which is somewhere on the Web, or does the method have reference to somewhere on Internet and returns that... 16:17:22 brent: #1 -- return the file. 16:17:30 ivan: Sounds like a narrow use case. 16:17:38 brent: A large community cares about this use case. 16:17:44 ack drummond 16:17:44 drummond, you wanted to talk about the parameter for dereferencing and to mention that DID doc should NOT be considered public 16:18:30 q+ to defend herd privacy as a principle 16:18:32 drummond: Two quick points - as an editor, huge mistake to assume DID Document is public... we should make sure we cover that case, but there are thousands of use cases for DID Documents that are private -- shared between peers... so to impose on the spec taht all DID DOcuments would be public. 16:18:41 Is it true that the desire to support schemas and did documents in the same system is to support certain ZKP credential formats such as Indy Credentials? 16:19:00 drummond: Interested parameter for requesting dereferencing -- all for resolution, but if you want for efficiencies sake, compose URL that ask for derefrencing -- that's option #4. 16:19:04 present+ 16:19:10 q? 16:19:22 brent: We have a minute left and then we need to move on... Excellent feedback so far. 16:19:25 ack brent 16:19:28 ack manu 16:19:54 manu: veres one has a use case where we store capabilities on ledger, in veres one the DID doc is a capability itself. We have explored other things being storedin DID docs that are kind of like the use case brent outlined 16:20:08 ... one workable thing would be why don't we create a narrow property called schema if you want to put a schema in a DID doc, adn we create other narrow properties 16:20:10 q+ 16:20:13 ... we may be trying to overgeneralize this feature 16:20:18 ... we need to be very specific about what we want 16:20:41 ... keeping dereferencing separate from resolution is a good thing to do architecturally but it may confuse this because other parts of internet infrastructure may work that way so it may be a weird thing for people to understand 16:20:57 ... trying to figure out the simplest way to address the issue, putting a specific property in a DID doc might be the first easiest way 16:21:05 I'm worried that we're going to end up with a growing list of properties being added to DID Spec Registries for all the different types of content that might want to be included in a DID document. 16:21:10 ... we can talk about the more complex things like resolution and deferenerncing giving back different things 16:21:18 if you had a URL like this: "did:method:1234#representation" and it resolves to the DID Document "did:method:1234" and when dereferenced, you get whatever it says about "did:method:1234#representation" you get a technical separation of resolution/dereferencing 16:21:20 q? 16:21:28 ack JoeAndrieu 16:21:28 JoeAndrieu, you wanted to defend herd privacy as a principle 16:21:29 ... there's a use case in veres one that's sort of interested in figuring out the answer to this quesiton but i'd like the group to pick the simplest thing that is nto going to create more cognitive overhead for developers 16:21:40 dbuc has joined #did 16:21:42 Agree with Dave 16:21:42 (not unlike dereferencing verification methods) 16:21:43 present+ 16:21:47 that narrow property sounds like an extension / for the registries rather than a core property 16:22:16 JoeAndrieu: regarding Drummond's comments -- public vs. private -- important thing isn't "all did documents ar epublic"... rather, "herd privacy requires they be indistinguishable"... properties unique to subject can cause problems w/ herd privacy. 16:22:23 +1 to the importance of herd privacy 16:22:26 ack ivan 16:23:18 q+ 16:23:40 ivan: I understand the use case and accept it -- maybe this is what Joe was saying -- there is a layering issue... the method, as far as DID is concerned, method does resolution and returns DID Document... but there is DID URL, which is different thing... method stores something other than DID DOcument, so you want to give separate acces sto other information -- thsoe two things are very separate... I'd use a different ... DID URL might be different... I 16:23:40 don't resolve now, I use other functionality, these two things shouldnt be mixed. 16:23:41 +1 to ivan 16:23:47 ack markus_sabadello 16:24:10 markus_sabadello: we already have scenarios where dereferencing a DID URL returns something other than DID DOcument, service selection, for example -- not a new idea. 16:24:41 https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p1+sort%3Aupdated-asc 16:24:44 brent: Ok, that helps, will move on to issue processing 16:24:50 Topic: Priority 1 Issues 16:24:54 https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p1+sort%3Aupdated-asc 16:25:07 brent: 118 -- WCAG - we know that, we'll make those changes before CR 16:25:15 brent: 292 is staying open to keep tracking going 16:25:33 brent: 119 - TAG review is waiting on completion of security/privacy questionnaire, will be hopefully done by this evening. 16:25:40 https://github.com/w3c/did-core/issues/361 16:25:49 brent: 361 - define serializations for numbers, dates, other properties 16:25:50 q+ 16:26:01 ack manu 16:26:04 manu: there are PRs in flight to address this 16:26:11 ... one last PR i need to do to the cbor section to bring it in line 16:26:19 ... once they go in this issue will be addressed. Please review the PRs 16:26:37 https://github.com/w3c/did-core/pull/476 16:27:07 https://github.com/w3c/did-core/issues/384 16:27:07 brent: 384 - noramtive statements review 16:27:26 s/noramtive/normative/ 16:27:27 brent: List of all of normative statements -- we need to review these. 16:27:28 q+ 16:27:34 ack manu 16:27:39 q+ to ask about tests 16:27:44 manu: what we really need for the list is 1) the editors to go in and check but it's really going to be driven by people writing tests 16:27:52 ... I expect this will float out there until the tests start getting written 16:27:57 q+ 16:27:59 ... ideally we have good test coverage before we go into CR 16:28:03 ... but there's a ? over that right now 16:28:11 ... if we're not writing tests we're not going to have good coveerage 16:28:19 ... the companies that have stepped forward to do the tests have not been writing tests 16:28:20 ack Orie 16:28:20 Orie, you wanted to ask about tests 16:28:21 please see 16:28:22 https://github.com/w3c/did-test-suite/issues/17 16:28:24 s/?/question/ 16:28:28 I will write at least two more to help 16:29:07 Orie: Yeah, I spent some time this weekend taking another stab at test infrastructure in another WGs test suite... got some major refactoring/structural changes and make it easier to write tests... would require changes... test suite, please review issue I raised. 16:29:26 Orie: The teaser is -- what if we could have a button that we could click that could test vendor conformance automatically -- run the tests via website... 16:29:37 q+ 16:29:41 brent: Chair call out for tests uite --- any orgs who have not committed, we'd love commitments there. 16:29:50 ack selfissued 16:29:57 phila_ has joined #did 16:30:14 selfissued: Skimming statements... actually list of statements made in RFC... *audio dropping* 16:30:24 please also review https://github.com/w3c/did-test-suite/pull/16 16:30:48 selfissued: for example, if second column... JSON object... as opposed to saying... value foo... *breaking audio* via JSON Object... have to use 19... language for... 16:30:57 selfissued: again... *roboting audio* 16:31:35 brent: We'll go back to that if Mike is able to fix his audio. 16:31:45 You don't have to use RFC 2119 language for a statement to be normative 16:31:58 For instance, saying that "The value of foo is a JSON object" is just as normative as "The value of foo MUST be a JSON object" 16:32:00 brent: Last open issue -- 199, clarification on what DIDs might identify, we've already identified some next steps to move that one forward. Those are the P1 issues. 16:32:12 The list in the issue appears to only be a list of statements using 2119 language - not all the normative statements 16:32:12 brent: Now on to P2 issues. 16:32:33 q+ 16:32:52 ack jonathan_holt 16:32:53 Do people agree or disagree? 16:33:03 jonathan_holt: Just to clarify the test suite -- what are testing for completeness of specification. 16:33:05 q+ to summarize what we arer testing 16:33:11 manu: Mike, I disagree wrt. testability 16:33:17 q+ to say the "is a " statements should all be captured by a prior "MUST be according to following:" statement that makes them normative (no mic, just read this) 16:33:20 q+ 16:33:39 jonathan_holt: Constraints on DID DOcument, confused on how we're writing these tests in a way that is abstracted wrt. abstract data model 16:33:39 ack manu 16:34:02 All language is normative unless marked non-normative 16:34:03 manu: mike, I think your right in a handwavey way, the only thing that we're going to translate into test suite tests are MUST statements 16:34:15 ... saying that you don't need to use rfc2119 language to be normative, I think i'ts misleading 16:34:23 ... the only thing we are going to be testing are the MUST statements in the specification 16:34:36 ... anything else that seems normative will be asserted that it is not normative if you don't have a MUST or a SHOULD or a MAY 16:34:37 "The value of foo is a JSON object" is normative 16:34:46 ... if we don't do it that way it is very difficult to say what a normative statement is 16:34:54 ... to be crystal clear, without rfc2119 language it is not a normative statement 16:35:12 ... the example in IRC is not a normative statement. the value of foo MUST be a json object. We would reword the statement to have the MUST in there 16:35:13 Completely disagree 16:35:15 ack Orie 16:35:15 Orie, you wanted to summarize what we arer testing 16:35:33 Orie: Agree with everything Manu just said, trying to answer jonathan_holt directly -- purpose of tests is to cover normative statements. 16:35:43 Then why would we say that "The value of foo is a JSON object" if it has no meaning? 16:35:47 +1 to manu's point. There's a subtle difference between "normative" and "declarative" 16:36:22 "declarative" statements are testable 16:36:23 Orie: We should kick things out from the list that are not normative - we want things to be testable... do different DID Methods conform to test suite? We would like test suite to solve for both, but let's get things testable and make sure list is accurate and a thing we want to write tests around. 16:36:29 "if not worded with RFC2119 language, we didn't intend it to be normative" is a meaningful statement. It would be great to get a list of normative statements that don't use RFC2119 language, so they can be reworded, whether into 2119 or out of non-2119 normativity. 16:36:47 +1 to TallTed 16:36:47 ack rhiaro 16:36:47 rhiaro, you wanted to say the "is a " statements should all be captured by a prior "MUST be according to following:" statement that makes them normative (no mic, just read this) 16:36:47 Orie: As someone that signed up to write tests, list needs to be clear and definitive. 16:36:53 q+ 16:36:55 manu: +1 to TallTed 16:36:58 brent ^ sorry typed it 16:37:14 I don't see a way to do that with technology, so volunteers would be welcome. (I cannot volunteer to do this.) 16:37:14 rhiaro: is a " statements should all be captured by a prior "MUST be according to following: 16:37:21 I agree that if a statement should be normative but doesn't use rfc2119 language it should be found and fixed 16:37:27 ack selfissued 16:37:56 selfissued: At least in the IETF, it's 100 percent ... is statements are normative... you don't have to use RFC2119 language for a statement to be normative. 16:38:20 selfissued: I could find that... when we wrote WebAuthn... we did the same... the "RFC2119 language" wasn't necessary... 16:38:22 selfissued - we get a few words, then a asdfasf, then a few words 16:38:50 brent: hopefully Mike can add his comments in IRC 16:38:56 s/selfissued - we get a few words, then a asdfasf, then a few words// 16:39:14 q+ 16:39:18 brent: This is a valuable conversation, I'd like to come to some sort of agreement about it. 16:39:22 ack TallTed 16:39:38 In the IETF, it's 100% clear that declarative sentences not using 2119 language are normative and testable 16:39:49 Yes - ever statement is normative 16:39:57 TallTed: I think what Mike is trying to say is that in IETF, they recognize that everything they say is meant to be authoritive and spec text, they don't force themselves to use 2119... 16:40:05 That was true when we wrote WebAuthn and WebCrypto as well 16:40:24 There's no reason to use 2119 language when a declarative statement means the same. That's just spec bloat. 16:40:27 TallTed: This is my opinion - what we're doing here is different -- we are trying to say everything said in 2119 language is normative, everything else is plain english. 16:40:46 Plain English is testable 16:41:11 manu: there's respec boilerplate that states everything in rfc2119 is normatiave 16:41:30 Adding 2119 keywords is unnecessary 16:41:41 q? 16:41:47 TallTed: Yes, plain english is testable, please go through the spec to pick those things out -- requires a lot of effort and we want something definitive. 16:41:53 https://www.w3.org/TR/did-core/#conformance 16:42:29 Good - everything is normative 16:42:36 That supports my point 16:42:45 I am pretty strongly against "lets test all the english language in the spec" 16:42:50 :) 16:42:59 I sat down and did this in CDDL for the entire DID spec see: https://github.com/w3c/did-spec-registries/tree/master/cddl 16:42:59 brent: We do say everything is normative -- if there is a normative statement that we want to test, that doesn't have 2119 language, it seems like there are folks in the group that want to add that language. 16:43:11 Most of the plain meaning of the spec doesn't use MUSTs - because you don't have to 16:43:19 https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p2+sort%3Aupdated-asc 16:43:20 We should still test all the normative statements 16:43:33 brent: Moving on to P2 issues -- issue 170 16:43:42 https://github.com/w3c/did-core/issues/170 16:43:46 Topic: P2 issues 16:43:48 brent: Public key ID and type members duplicate kid and kty members. 16:43:58 q+ to recommend closing 16:44:06 brent: raised by mike jones, good conversation, assigned to Mike Jones... can you give us a status update on this issue. 16:44:57 selfissued: I don't think this has been resolved -- no statement in spec between different fields that they must be equivalent or that you shouldn't use one or the other. 16:45:23 q- 16:45:30 brent: ok, next step for this is for Mike to raise a PR that adds the language the spec sould have or removes language you feel spec shouldn't. 16:45:44 Testing all normative statements is one of our goals. Automated tools help in that, and have revealed some hundred+ such statements needing tests. After those are addressed, someone might be able to remove those statements from the doc, and read over the resulting output for normative statements that still need tests or rewording. 16:45:47 https://github.com/w3c/did-core/issues/58 16:45:50 brent: Moving on to 58 -- registry handling. 16:46:35 wayne: 58, registry handling -- depending on where folks want registry -- if you want it at CCG or not, fine either way, can facilitate either way -- can try to decide now or continue discussion on thread, up to folks here. 16:46:58 brent: we could have a special topic call on this at some point.. kinda wish process 2020 had incorporated registry plans. 16:47:24 brent: I am "preaching to the choir" -- will add to special topic call considerations, thanks for update wayne. 16:47:33 https://github.com/w3c/did-core/issues/367 16:47:34 brent: Next issue is 367 16:47:58 brent: Move issues from spec registries to DID Core, assigned to kyle, manu do you have an update? 16:47:59 manu: Nope 16:48:03 afaik its only https://github.com/w3c/did-spec-registries/issues/102 16:48:05 brent: I'll ping Kyle in the issue. 16:48:25 https://github.com/w3c/did-core/issues/363 16:48:27 brent: issue 363 -- clarify authorization requirements -- 16:48:33 brent: raised by community member... 16:48:46 manu: I believe I need to write spec text and have not done that yet 16:49:27 ... there might not be, it's on my list. Maybe I'll remove the ready for PR flag and re-review and it will be closed if we don't hear back and the editors don't feel like more text is necessary 16:49:39 manu: Issue 439 - remove JSOn representaiton from DID Core 16:49:40 https://github.com/w3c/did-core/issues/439 16:50:02 q+ 16:50:03 Orie: We are waiting for at risk issues to annotate the spec, then expect issue to be closed once we've marked it as at risk 16:50:12 ack selfissued 16:50:31 selfissued: There is no reason for JSON to be marked as at risk because there are multiple implementations. 16:50:32 q+ 16:50:35 FYI, I'm adding one at risk annotation as soon as I can resolve a GitHub issue I'm having. 16:50:37 ack manu 16:50:40 manu: what are those implementations? 16:51:08 selfissued: I don't have the list in front of me, but in conversations... heard of multiple ones. 16:51:15 IPID can be represented in JSON 16:51:17 I have seen no evidence of mikes assertions, and i am one of the editors of the registry that records implementations 16:51:20 ivan: We need to document these. 16:51:31 selfissued: This is a red herring, unproductive to mark something as at risk that's a core feature. 16:52:04 q+ 16:52:05 brent: If two or more known implementations of a JSON-only representation exists and we can identify them, we don't need to mark it as at risk and we don't need to mark it... but don't know if two have been brought forward. 16:52:09 also if the at-risk features get implementations during CR there's no problem.. not a big deal? 16:52:22 https://github.com/w3c/did-core/issues/425 16:52:33 brent: 425 -- did spec registries needs terminological criteria.... this is an issue assigned to Joe Andrieu -- update Joe? 16:53:19 JoeAndrieu: This is over my head, related to trademark disputes related to IANA -- and we haven't figured it out... risk of liability for registry editors and W3C for problems for registered terms and methods... we need to figure out how we're going to resolve that. 16:53:34 q+ 16:53:41 ivan: Example? 16:53:44 ack jonathan_holt 16:53:49 JoeAndrieu: We don't have guidance on trademarks.... 16:54:02 q+ 16:54:03 jonathan_holt: IPID can be represented as JSON -- CBOR, multiple implementations using CBOR as well as JSON. 16:54:06 ack drummond 16:54:29 drummond: I didn't realize it was this issue -- revisit registry governance rules, can add that to my list as one person contributing to that. 16:54:35 ack ivan 16:54:54 ivan: I am not a lawyer, can't comment in name of W3C... if problem/issue is clearly described, then we should ask W3C legal staff to look at this. 16:55:06 ivan: I don't think any one of us knows that. 16:55:08 q+ 16:55:14 ivan: I have to go back to Wendy with something more specific. 16:55:16 ack drummond 16:55:30 drummond: I've worked w/ a number of lawyers on this issue - can help, yes it would be great to have W3C legal counsel input. 16:55:35 ivan: If you prepare something, I can ask Wendy. 16:55:43 brent: Is more needed than what's in Issue 425 16:56:03 drummond: I'll take a look at it. 16:56:13 ivan: I'll send this to Wendy and she can tell us if she needs more information or not. 16:56:18 brent: Issue 240 16:56:20 I think the gist is clear in 425. W3 needs boilerplate for registries handled by all WGs/CGs/etc. 16:56:23 https://github.com/w3c/did-core/issues/240 16:56:28 Perfect, thanks Ivan! 16:56:37 brent: Should DID Core restrict use of JWK? raised by Orie, assigned to Orie, Manu and Mike 16:57:32 Orie: We had a number of special topic calls where we discussed this, primary consensus on calls was -- no private information of any type should be in DID Documents, already have language in DID Core spec on that, not sure how much mroe specific we should get on JWK... other issues related to removing key representation specifics imply that these details should be in suite definitions, not in DID Core. 16:57:43 Orie: As an engineer, I don't want to redefine what JWK is in this spec. 16:58:05 brent: Issue 163 16:58:11 https://github.com/w3c/did-core/issues/163 16:58:28 brent: use of terms defined in specifications -- we know we're going to do it. 16:58:32 brent: Issue 325 16:58:40 https://github.com/w3c/did-core/issues/325 16:58:50 brent: Rawsec 32 bytes -- this is resolevd by same things that Orie talked about earlier. 16:59:01 manu: proposal is to move those specifics into the linked data cryptosuite, what orie said 16:59:53 brent: Thanks all for coming, thanks manu and amy for scribing, made good progress, bulk of work happens outside these meetings, move issues forward, if you feel need to contribute -- ready for PR, people can grab, submit PRs for, feel free to do that... it's an underrated thrill, dare I say 17:00:00 brent: Special topic call later today - 6pm ET. 17:00:06 brent: Thanks all! 17:00:20 rrsagent, draft minutes 17:00:20 I have made the request to generate https://www.w3.org/2020/12/08-did-minutes.html manu 17:00:28 agropper has left #did 17:00:29 zakim, end meeting 17:00:29 As of this point the attendees have been ivan, justin_r, shigeya, rhiaro, markus_sabadello, wayne, manu, brent, drummond, adrian, selfissued, agropper, dmitriz, TallTed, orie, 17:00:32 ... dlongley, jonathan, jonathan_holt, JoeAndrieu, Eugeniu_Rusu, identitywoman, by_caballero, dbuc 17:00:32 RRSAgent, please draft minutes 17:00:32 I have made the request to generate https://www.w3.org/2020/12/08-did-minutes.html Zakim 17:00:34 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 17:00:38 Zakim has left #did 17:05:32 shigeya has joined #did 17:52:26 markus_sabadello has joined #did 18:13:35 markus_sabadello has joined #did 18:28:47 markus_sabadello has joined #did 19:51:11 markus_sabadello has joined #did 21:00:13 markus_sabadello has joined #did 23:06:21 JoeAndrieu has joined #did 23:12:39 identitywoman has joined #did 23:18:59 TallTed has joined #did