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|