15:00:41 <RRSAgent> RRSAgent has joined #did 15:00:45 <RRSAgent> logging to https://www.w3.org/2024/08/15-did-irc 15:00:57 <decentralgabe> Meeting: Decentralized Identifier Working Group 15:01:05 <decentralgabe> Chair: Gabe Cohen 15:01:13 <decentralgabe> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Aug/0015.html 15:01:19 <decentralgabe> present+ 15:01:35 <TallTed> TallTed has joined #did 15:01:48 <decentralgabe> present+ 15:02:18 <decentralgabe> Topic: Agenda Review, Introductions 15:02:19 <ivan> present+ 15:03:01 <Wip> Wip has joined #did 15:03:09 <Wip> present+ 15:04:43 <TallTed> present+ 15:04:58 <stephan> stephan has joined #DID 15:05:53 <bigbluehat> bigbluehat has joined #did 15:06:10 <bigbluehat> present+ 15:06:10 <bigbluehat> scribe+ 15:06:21 <KevinDean> KevinDean has joined #did 15:06:25 <KevinDean> present+ 15:06:31 <bigbluehat> decentralgabe: agenda review 15:06:32 <burn> burn has joined #did 15:06:39 <bigbluehat> ... we'll talk about the controller document 15:06:52 <andres> andres has joined #did 15:06:52 <andres> present+ 15:06:53 <bigbluehat> ... no special topic call next week as we do not have a topic yet 15:07:00 <bigbluehat> ... if you have one, please let us know on the mailing list 15:07:12 <bigbluehat> ... also we'll talk TPAC and doc organizing 15:07:25 <bigbluehat> ... and issue processing toward the end 15:07:26 <bigbluehat> ... anything else? 15:07:56 <bigbluehat> topic: Controller Document 15:08:06 <bigbluehat> decentralgabe: we've talked about this document before 15:08:12 <bigbluehat> ... it's at the VC WG 15:08:19 <bigbluehat> ... we look forward to collaborating with them 15:08:25 <decentralgabe> Topic: APAC Call Announcement 15:08:38 <bigbluehat> decentralgabe: minutes are available from last week. They're approved since no objections. 15:08:44 <burn> burn has joined #did 15:08:46 <decentralgabe> Thursday 5-6 pm US Pacific Time 15:08:46 <decentralgabe> - Thursday 8-9 pm US Eastern Time 15:08:46 <decentralgabe> - Friday 0200-0300 Central European Time 15:08:48 <decentralgabe> - Friday 8-9 am Hong Kong 15:08:52 <bigbluehat> ... we've settled on a Thursday/Friday call 15:08:58 <bigbluehat> ... first Thursday in each month 15:09:08 <bigbluehat> ... hope you can make it 15:09:12 <bigbluehat> ... and we'll send out notifications 15:09:14 <decentralgabe> Topic: TPAC Topic Announcement 15:09:19 <bigbluehat> ... the calendar is already updated 15:09:24 <decentralgabe> https://github.com/w3c/did-wg/issues/57 15:09:30 <bigbluehat> ... TPAC will be here before you know it 15:09:42 <bigbluehat> ... please add to that issue if you have presentations you'd like to make 15:09:54 <bigbluehat> ... even if you just have idea you'd like to see presented, please share 15:10:04 <bigbluehat> ... We're scheduled on Monday and Tuesday 15:10:11 <bigbluehat> ... we plan to do a group dinner Monday evening 15:10:22 <bigbluehat> ... if we have a sponsor, it can be a more formal thing 15:10:34 <manu> present+ 15:10:35 <bigbluehat> ... but even without one, we'll find a place to meet up and pay for our own meals 15:10:50 <decentralgabe> Topic: DID Core update vs. new @context Discussion 15:11:00 <decentralgabe> https://github.com/w3c/did-core/issues/850 15:11:03 <bigbluehat> decentralgabe: one issue that's come up so far... 15:11:13 <bigbluehat> ... there are some terms that we'd like to update 15:11:26 <JoeAndrieu> JoeAndrieu has joined #did 15:11:28 <manu> q+ 15:11:36 <decentralgabe> ack manu 15:11:38 <bigbluehat> ... so do we make a new context to be used instead? add an additional context? or amend the existing one? 15:11:52 <bigbluehat> manu: amending the current context is possible if a bit fraught 15:12:04 <ivan> q+ 15:12:14 <bigbluehat> ... we've been trying to follow a best practice of only amending contexts for security vulnerabilities 15:12:34 <bigbluehat> ... this situation is not a security issue...just establishing new terms from the Controller Document from the VC WG 15:12:44 <bigbluehat> ... we can do this in a non-disruptive way 15:12:52 <bigbluehat> ... by publishing a v1.1 context 15:13:04 <bigbluehat> ... it's arguable if this is a new feature or not 15:13:19 <bigbluehat> ... we do specify a v1 context in the spec 15:13:34 <bigbluehat> ... we would be updating the text to say in future the v1.1 context would be used 15:14:06 <bigbluehat> ... we can do this in a way where everything stays the same--use v1--but if you want the new terms, use the v1.1 context 15:14:44 <bigbluehat> ... if we really wanted to, we could keep all the old stuff in the v1.1 context, so less would need to be changed to upgrade to using it 15:14:52 <bigbluehat> ... I do think this would be a good idea 15:15:07 <bigbluehat> ... we need to see if anyone would object if we did this as a MAY in the spec 15:15:30 <bigbluehat> ... lastly, if we don't do this now...it'll be another 2 years to get these terms into the core context 15:15:33 <decentralgabe> subtopic: https://github.com/w3c/did-core/issues/859 15:15:38 <bigbluehat> ... which seems too long 15:16:06 <bigbluehat> decentralgabe: this is the new issue for it. manu, could I assign you? 15:16:06 <bigbluehat> manu: yes 15:16:06 <decentralgabe> ack ivan 15:16:06 <bigbluehat> ... I'd like to hear from ivan 15:16:26 <bigbluehat> ivan: mainly, I just want to understand... 15:16:35 <bigbluehat> ... the did core context is very small and simple 15:16:43 <JennieM> JennieM has joined #did 15:16:43 <manu> q+ 15:16:50 <bigbluehat> ... most of them already match the Controller Document 15:16:57 <bigbluehat> ... what are the additional terms? 15:17:14 <bigbluehat> ... if we're adding terms to the DID spec, we may have other problems 15:17:17 <decentralgabe> ack manu 15:17:26 <bigbluehat> manu: right. Specifically, we're talking about.... 15:17:51 <bigbluehat> ... the main thing these are used for is listing key material 15:18:06 <bigbluehat> ... when we put the spec together, there was just JSON Web Key 2020 15:18:14 <bigbluehat> ... we've decided to drop the date off the term 15:18:44 <JennieM0> JennieM0 has joined #did 15:18:44 <JennieM0> JennieM0 has left #did 15:18:53 <bigbluehat> ... we'd also switched to using a more consistent format with multikey 15:19:02 <bigbluehat> ... we could make these changes and keep all the old stuff there 15:19:14 <JennieM> JennieM has joined #did 15:19:19 <stephan> stephan has joined #did 15:19:25 <bigbluehat> ... or we could decide to use v1.1 and not bring over the old terms forcing upgrades to the new terms 15:19:32 <bigbluehat> ... there are good arguments either way 15:19:44 <bigbluehat> ... I'd lean toward it being a clean break 15:19:53 <bigbluehat> ... asking people to move to the new key formats 15:20:12 <bigbluehat> ... since it's a MAY, then no one needs to upgrade if they don't want to 15:20:20 <bigbluehat> ... that was the thinking. Mostly around key formats 15:20:36 <bigbluehat> ivan: I'm undecided at this moment. 15:21:13 <bigbluehat> ... the nature of the additions seem to make doing this overkill 15:21:16 <manu> q+ 15:21:18 <bigbluehat> ... so I think we can postpone 15:21:21 <decentralgabe> https://github.com/w3c/did-resolution/issues/78 15:21:27 <bigbluehat> decentralgabe: there is a slightly related issue 15:21:35 <bigbluehat> ... some context issues related to the move 15:21:41 <bigbluehat> ... we need to make sure those are available 15:21:51 <decentralgabe> ack manu 15:21:53 <bigbluehat> ... it may be premature now, but still making a strategy would be best 15:22:12 <bigbluehat> manu: one of the things that we're concerned about are production rollouts that we're doing 15:22:19 <bigbluehat> ... we'd like to use the new key formats 15:22:23 <ivan> q+ 15:22:35 <bigbluehat> ... and we're concerned about being stuck with the old key formats 15:22:46 <bigbluehat> ... we can fold the new ones in by using other contexts 15:22:55 <bigbluehat> ... but ideally, we'd like to use a v1.1 context 15:23:15 <bigbluehat> ... so...that doesn't really help make the decision since we have options either way 15:23:25 <decentralgabe> ack ivan 15:23:27 <bigbluehat> ... but perhaps that explains the importance of the topic for us 15:23:45 <bigbluehat> ivan: if I take the union of DID and VC WGs, then we may be inconsistent 15:23:58 <bigbluehat> ... in the VC WG there are separate context files 15:24:08 <bigbluehat> ... and they are not in the DI context files 15:24:13 <manu> Well, not really :) 15:24:15 <bigbluehat> ... here we are moving toward unifying them 15:24:19 <manu> (or rather, no, we're not doing that) 15:24:28 <manu> The split is (what goes in a VC vs. what goes in a controller doc) 15:24:29 <bigbluehat> ... it's doable, but I'm not keen on the inconsistency 15:24:50 <bigbluehat> manu: the dividing line seems to be what goes in a controller doc 15:25:08 <bigbluehat> ... those are public keys and controller services 15:25:17 <bigbluehat> ... I think we have a controller document context 15:25:31 <bigbluehat> ... in VCs, we have similar terms for proof's 15:25:44 <bigbluehat> ... that may be changing with confidence method 15:26:08 <bigbluehat> ... Main question is around expectations that differ between what would go into a VC vs. a Controller Document 15:26:22 <bigbluehat> ... hopefully that helps explains why things are split up that way 15:26:24 <decentralgabe> Topic: Media Types 15:26:35 <decentralgabe> https://www.w3.org/TR/did-core/#iana-considerations 15:26:40 <bigbluehat> decentralgabe: we have two media types 15:26:49 <decentralgabe> https://github.com/w3c/did-core/issues/838, https://github.com/w3c/did-core/issues/849 15:26:58 <bigbluehat> ... there are issues around when those are unknown 15:27:05 <bigbluehat> ... question is do we want to make adjustments 15:27:13 <manu> q+ 15:27:17 <decentralgabe> ack manu 15:27:17 <bigbluehat> ... are we comfortable with how things are today? 15:27:35 <bigbluehat> manu: this sort of comes in from the VC WG conversations 15:27:46 <bigbluehat> ... we were going to use multiple suffixes 15:27:55 <bigbluehat> ... but at the end of the day there was no consensus at IETF 15:28:03 <bigbluehat> ... and now they don't want multiple suffixes at all 15:28:11 <bigbluehat> ... and they made the decisions, so that is over 15:28:18 <bigbluehat> ... which means we can only have single suffixes 15:28:33 <bigbluehat> ... which then forces everyone else to fix a base subtype 15:28:48 <bigbluehat> ... currently, we wanted did+json and did+ld+json 15:29:05 <bigbluehat> ... we could do did-ld+json, but we can't 15:29:10 <bigbluehat> ... we got bad advice 15:29:27 <bigbluehat> ... so we'd have to get the JSON-LD WG to register a ld-json type 15:29:29 <decentralgabe> q+ 15:29:38 <bigbluehat> ... and all of this will likely be many months of conversations 15:29:57 <bigbluehat> ... so...we will likely have the same conversations around JSON vs. JSON-LD at the media type level 15:30:08 <bigbluehat> ... or we need the JSON-LD WG to change their media type 15:30:18 <ivan> q+ 15:30:24 <decentralgabe> ack decentralgabe 15:30:33 <bigbluehat> decentralgabe: chair hat off 15:30:47 <bigbluehat> ... if there is no concrete core representation, could we have just `did`? 15:30:50 <manu> q+ 15:30:55 <decentralgabe> ack ivan 15:30:59 <bigbluehat> ... or do we have to have several media types that include `did`? 15:31:18 <bigbluehat> ivan: we could use the profiles 15:31:24 <decentralgabe> ack manu 15:31:38 <bigbluehat> manu: that's a third option via parameterized media types 15:31:55 <bigbluehat> ... implementers get it wrong 15:32:05 <bigbluehat> ... but in general, they mostly get ignored 15:32:25 <bigbluehat> ... we can have a media type with a suffix 15:32:46 <bigbluehat> ... `application/did+json` or `application/did+json-ld-something` 15:32:59 <KevinDean> KevinDean has joined #did 15:33:07 <bigbluehat> ... we can talk to the JSON-LD WG to discuss about a new structured suffix 15:33:32 <bigbluehat> ... we would then not have to register `application/did` 15:33:53 <decentralgabe> q? 15:33:53 <bigbluehat> ... but that would drive us into the weeds of the abstract data model discussion 15:33:55 <bigbluehat> q+ 15:34:00 <manu> scribe+ 15:34:03 <decentralgabe> ack bigbluehat 15:34:29 <JoeAndrieu> q+ to support `applicaiton/did` 15:35:20 <manu> bigbluehat: As Chair of the JSON-LD WG, we are re-chartering, it's something we could pick up, because the current media type is so widely deployed, there might not be interest in coming up w/ a structured syntax, and because most JSON-LD is served w/ `application/json` -- there is a lot of discussion we could have around what the media type value is in practice, especially in distinction between JSON and JSON-LD, the media type really doesn't provide 15:35:21 <manu> anything, other than a few processing specialities around HTTP Headers that JSOn-LD spec provides. 15:35:48 <decentralgabe> ack JoeAndrieu 15:35:48 <Zakim> JoeAndrieu, you wanted to support `applicaiton/did` 15:35:50 <manu> bigbluehat: In terms on what could be done w/ the body, nothing is really different wrt. media types -- Media Types seem to be jumping the shark, we shouldn't depend on them too much. 15:36:03 <bigbluehat> JoeAndrieu: I wanted to support `application/did` 15:36:13 <manu> q+ to note that media types are jumping the shark a bit. 15:36:13 <bigbluehat> ... what we are standardizing is what goes over the wire 15:36:25 <decentralgabe> ack manu 15:36:25 <Zakim> manu, you wanted to note that media types are jumping the shark a bit. 15:36:35 <bigbluehat> ... having a media type seems appropriate 15:36:46 <bigbluehat> manu: the amount of stuff in media types is ongoing 15:37:04 <bigbluehat> ... there are arguments that people will do things based on media types 15:37:13 <bigbluehat> ... but people mostly don't depend on them in practice 15:37:28 <bigbluehat> ... even when we're clear, folks mostly just use `application/json` 15:37:37 <bigbluehat> ... JSON-LD processors don't care 15:37:58 <bigbluehat> ... the `application/ld+json` media type doesn't tell a processor much more than that 15:38:21 <bigbluehat> ... and since implementers continue to get things wrong, there's nearly always a fallback mechanism to decide what to do with the payload 15:38:34 <bigbluehat> ... typically there's introspection of some kind 15:38:43 <bigbluehat> ... it is a bit of a mountain out of a mole hill 15:38:51 <bigbluehat> ... we could pick `application/did` and be done with it 15:39:04 <bigbluehat> ... most implementations will use JSON Schema 15:39:26 <bigbluehat> ... and things that want `@context` will reject it or act on the document as if it were there 15:39:34 <bigbluehat> ... we will need some language around the handling 15:39:42 <bigbluehat> ... we could get to a base media type that's JSON 15:39:45 <bigbluehat> ... and go from there 15:40:10 <decentralgabe> Topic: Moving DID Resolution 15:40:18 <bigbluehat> decentralgabe: thanks. please contribute to the media types issue 15:40:18 <decentralgabe> https://github.com/w3c/did-core/issues/857 15:40:31 <bigbluehat> decentralgabe: this one is about moving content 15:40:36 <manu> q+ 15:40:38 <bigbluehat> ... there are 3 different sections 15:40:45 <decentralgabe> ack manu 15:40:56 <bigbluehat> manu: no concerns. this is a good thing to do 15:41:00 <bigbluehat> ... +1 to the PRs. 15:41:11 <JoeAndrieu> +1 These are good 15:41:20 <bigbluehat> decentralgabe: great. 15:41:25 <decentralgabe> Topic: DID Core/Resolution Issue Processing 15:41:28 <bigbluehat> decentralgabe: last up is issue processing 15:41:39 <bigbluehat> ... if you have an issue you want to speak to, let me know 15:41:48 <bigbluehat> ... otherwise, we'll just work through what's open 15:41:57 <bigbluehat> decentralgabe: k. we have 5 open PRs 15:42:05 <bigbluehat> ... on did-core 15:42:16 <andres> andres has joined #did 15:42:23 <decentralgabe> Subtopic: Fix improperly URI Encoded values in DID parameters https://github.com/w3c/did-core/pull/813 15:42:41 <bigbluehat> decentralgabe: this one was opened in 2022 15:42:59 <bigbluehat> manu: there's discussione between TallTed and dlongley 15:43:30 <bigbluehat> TallTed: I don't think there is any more disagreement 15:43:40 <bigbluehat> ... the gist is don't encode things that don't need to be encoded 15:43:51 <bigbluehat> manu: agreed. that means the PR needs to change 15:43:59 <bigbluehat> ... just looking at the PR... 15:44:15 <bigbluehat> ... TallTed could you suggest what doesn't need to be encoded here? 15:44:21 <bigbluehat> TallTed: I'll have to take a look 15:44:34 <bigbluehat> ... the big one is a # that appears 15:44:38 <bigbluehat> ... is that part of the URL? 15:44:43 <bigbluehat> ... or a delinator? 15:44:55 <bigbluehat> manu: it's part of the URL 15:45:10 <bigbluehat> ... that bit would get tacked onto the end of the URL 15:45:29 <bigbluehat> ... I know what you want here, so let's try to work it out on the PR 15:45:34 <bigbluehat> ... change requests would be ideal 15:45:37 <bigbluehat> ... thanks TallTed 15:45:46 <bigbluehat> decentralgabe: thank you both 15:45:47 <decentralgabe> Subtopic: https://github.com/w3c/did-core/pull/813 Fix improperly URI Encoded values in DID parameters. 15:46:06 <decentralgabe> Subtopic: Fix serviceEndpoints maps link https://github.com/w3c/did-core/pull/851 15:46:22 <manu> q+ 15:46:33 <decentralgabe> ack manu 15:46:37 <bigbluehat> decentralgabe: manu mentioned it couldn't be addressed earlier due to recharter, but now it looks done 15:46:42 <bigbluehat> ... so can we close it? 15:46:54 <bigbluehat> manu: yes. just waiting on a response on the PR 15:47:09 <bigbluehat> ... we fixed the core spec. The change was fine in concept, just in the wrong place 15:47:21 <bigbluehat> ... don't close it yet because ivan's robots will be sad 15:47:30 <bigbluehat> ... oh, nevermind...the bots are elsewhere 15:47:40 <bigbluehat> decentralgabe: one day we may have those robots here, but not yet 15:47:45 <decentralgabe> Subtopic: https://github.com/w3c/did-core/pull/852 Use publicKeyMultibase instead of publicKeyBase58 field in all examples 15:47:49 <manu> q+ 15:47:56 <decentralgabe> ack manu 15:47:56 <bigbluehat> decentralgabe: this PR has been opened since March 15:48:05 <bigbluehat> manu: this has to do with v1.1...maybe 15:48:19 <bigbluehat> ... this is related to these new terms 15:48:29 <bigbluehat> ... we could pull in a new context and fix it immediately 15:48:34 <bigbluehat> ... and I think we should just do that 15:48:46 <bigbluehat> ... to upgrade to multibase in that way 15:48:47 <ivan> +1 to Manu 15:48:49 <bigbluehat> ... any objections? 15:49:07 <bigbluehat> decentralgabe: seeing no one on the queue, manu maybe you can take over the PR? 15:49:19 <bigbluehat> ... the author may not be able to continue due to IPR? 15:49:29 <bigbluehat> manu: it's an example, so I think we can clear that 15:49:34 <bigbluehat> ... I'll finish it up 15:49:43 <decentralgabe> Subtopic: https://github.com/w3c/did-core/pull/856 Fix JSON formatting for DID document 15:49:56 <bigbluehat> decentralgabe: this one is a month old and has approvals 15:50:04 <bigbluehat> manu: I can merge it 15:50:23 <decentralgabe> Subtopic: https://github.com/w3c/did-core/pull/858 15:50:38 <bigbluehat> decentralgabe: there are no reviews yet 15:50:47 <bigbluehat> ... please take a look and review it 15:51:10 <bigbluehat> decentralgabe: that concludes our agenda 15:51:17 <bigbluehat> ... join the queue if you have more to say 15:51:30 <bigbluehat> ... k. hearing nothing. thank you for the progress 15:51:39 <bigbluehat> ... next time, we will continue processing issues and prs 15:51:49 <bigbluehat> ... please also join the TPAC conversaion 15:51:55 <bigbluehat> ... have a good week! 15:52:01 <decentralgabe> rrsagent, make minutes 15:52:02 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/15-did-minutes.html decentralgabe 15:52:05 <ivan> rrsagent, draft minutes 15:52:06 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/15-did-minutes.html ivan 15:52:17 <decentralgabe> zakim, end the meeting 15:52:17 <Zakim> As of this point the attendees have been decentralgabe, ivan, Wip, TallTed, bigbluehat, KevinDean, andres, manu 15:52:19 <Zakim> RRSAgent, please draft minutes 15:52:20 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/15-did-minutes.html Zakim 15:52:22 <Zakim> I am happy to have been of service, decentralgabe; please remember to excuse RRSAgent. Goodbye 15:52:26 <Zakim> Zakim has left #did <pchampin> s|Subtopic: https://github.com/w3c/did-core/pull/813 Fix improperly URI Encoded values in DID parameters.| <pchampin> s|into the core context|into the core context, which seems too long <pchampin> s|... which seems too long|