15:01:30 <RRSAgent> RRSAgent has joined #did
15:01:34 <RRSAgent> logging to https://www.w3.org/2024/09/19-did-irc
15:01:34 <Zakim> RRSAgent, make logs Public
15:01:35 <Zakim> please title this meeting ("meeting: ..."), ivan
15:01:46 <ivan> Meeting: DID WG Weekly Telco
15:02:11 <Wip> Wip has joined #did
15:02:11 <decentralgabe> decentralgabe has joined #did
15:02:15 <decentralgabe> present+
15:02:18 <Wip> present+
15:02:54 <TallTed> TallTed has changed the topic to: DID WG Agenda 2024-09-19: https://www.w3.org/events/meetings/2d6cdae9-7c4f-4fb7-93ce-35e2f579edc7/20240919T080000/
15:03:05 <swcurran> swcurran has joined #did
15:03:12 <pchampin> present+
15:03:14 <swcurran> present+
15:03:24 <decentralgabe> decentralgabe has changed the topic to: DID WG Agenda 2024-09-19 https://lists.w3.org/Archives/Public/public-did-wg/2024Sep/0012.html
15:03:36 <decentralgabe> Chair: Gabe Cohen
15:03:47 <decentralgabe> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Sep/0012.html
15:03:59 <m2gbot> m2gbot has joined #did
15:04:53 <Wip> scribe+
15:05:01 <decentralgabe> Topic: Agenda Review, Introductions
15:05:34 <dmitriz> dmitriz has joined #did
15:05:36 <markus_sabadello> markus_sabadello has joined #did
15:05:38 <dmitriz> present+
15:05:42 <Wip> decentralgabe: agenda is a process announcement, TPAC, did-core and did-resolution issue and pr processing
15:05:54 <decentralgabe> Topic: DID WG Process Announcement
15:05:58 <decentralgabe> scribe+
15:06:13 <markus_sabadello> present+
15:06:21 <andres> present+
15:06:50 <decentralgabe> wip: we will announce pending close issues for the week in the agenda. after the thursday call (either APAC/regular), those issues will be able to be closed
15:07:04 <decentralgabe> ... every week you will have a chance to challenge a pending close issue. unless you have concerns
15:07:25 <decentralgabe> Topic: TPAC Preparation
15:07:31 <Wip> decentralgabe: any concerns? Hearing none, moving on
15:07:40 <decentralgabe> https://docs.google.com/presentation/d/1s6tf0VOKdIr3Gf_t7ROypyeg07Lk_myoOFby6AL4I7g/edit?usp=sharing
15:07:59 <Wip> decentralgabe: This is the link to our TPAC slides. Please add your slides by this Friday if possible
15:08:20 <Wip> ... We have discussed COVID policy as chairs. Masking is optional, but not required. Let us know if there are any concerns
15:08:24 <Wip> q+
15:08:31 <decentralgabe> ack Wip
15:08:37 <Wip> https://docs.google.com/spreadsheets/d/1rhgWEgT_H98PwAMhBUBcRDNNVT28QPxuefP9U2cpBbY/edit?gid=179611341#gid=179611341
15:09:04 <bigbluehat> bigbluehat has joined #did
15:09:26 <bigbluehat> present+
15:09:26 <decentralgabe> wip: please add yourself to the attendance sheet. and get slides in by Friday.
15:09:34 <decentralgabe> Topic: DID Core Issue/PR Processing
15:09:53 <Wip> decentralgabe: Editors have any issues / PRs that need attention?
15:09:55 <manu> q+
15:09:55 <decentralgabe> Subtopic: https://github.com/w3c/did-core/pull/852
15:09:59 <decentralgabe> ack manu
15:10:24 <Wip> manu: This one is waiting on merge conflict resolution
15:10:47 <smccown> smccown has joined #did
15:10:52 <smccown> present+
15:11:12 <Wip> ... We might have to do a more complete fix with this one. Or pull the PR in and make the fix later
15:11:16 <ivan> q+
15:11:31 <Wip> decentralgabe: I noticed you tagged the author. If manu you can take it over that would be great
15:11:32 <burn> burn has joined #did
15:11:41 <Wip> manu: Sure, I can take it over.
15:11:42 <decentralgabe> ack Ivan
15:12:07 <manu> q+
15:12:09 <Wip> ivan: Why do you think it is aclass 2 change? I think it is a class 3
15:12:22 <Wip> ... using public key multibase effects implementations
15:12:22 <decentralgabe> ack manu
15:12:35 <Wip> manu: It effects the examples, this is non-normative
15:12:47 <Wip> ivan: Okay, yep its a class 2
15:13:01 <Wip> manu: There is a separate issue that discusses upgrading to publicKeyMultibase
15:13:18 <manu> q+
15:13:23 <decentralgabe> ack manu
15:13:26 <decentralgabe> https://github.com/w3c/did-core/issues
15:13:48 <decentralgabe> Subtopic: https://github.com/w3c/did-core/issues/863 application/did+ld+json should be revisited
15:13:55 <Wip> manu: Strategy to discuss the big rocks first. Class 3, then 2 then 1
15:14:20 <Wip> ... 863 is about the media type. In did-core we said application/did+ld+json
15:14:35 <Wip> ... open question what the media type should be. Cannot have did+ld+json
15:14:46 <Wip> ... some implementors want to use json serialization others jsonld
15:15:00 <Wip> ... Looking at potentially 2 media types
15:15:09 <Wip> ... we could try application/did as the media type
15:15:50 <Wip> ... with the new controller document which supports context injection. We can parse as json if it doesnt have a json if it does have a @context you can parse as jsonld
15:16:02 <Wip> ... if you want to parse as jsonld but it doesn't have a context you can inject one
15:16:40 <ivan> -> Controller document context injection section https://www.w3.org/TR/controller-document/#context-injection
15:16:43 <Wip> ... Strongly suggesting we just do application/did to keep it simple
15:17:14 <Wip> ... Need to be clear we are not allowing two different processing models
15:17:21 <Wip> ... thoughts concerns about application/did
15:17:21 <bigbluehat> +1 to `application/did`
15:17:31 <markus_sabadello> q+
15:17:32 <dmitriz> q+
15:17:35 <decentralgabe> ack markus_sabadello
15:17:37 <ivan> q+
15:17:58 <manu> q+ to go into polyglot response if it becomes an issue.
15:18:03 <dmitriz> my vote would be for application/did+json.  To enable the eventual (and inevitable?) application/did+cbor
15:18:06 <Wip> markus_sabadello: What does this mean for the abstract data model, if the controller document allows context injection
15:18:16 <decentralgabe> ack manu
15:18:16 <Zakim> manu, you wanted to go into polyglot response if it becomes an issue.
15:18:57 <Wip> manu: Still have the abstract data model. You would still be able to use JSON. Or you can use jsonld. Fundamentally these are interpretted the same. The meaning is the same
15:19:47 <Wip> markus_sabadello: I want to do this. Seems like we don't need the different representations anymore.
15:19:51 <decentralgabe> ack dmitriz
15:19:57 <manu> q+ to note that we could have CBOR in the future.
15:20:26 <Wip> dmitriz: In JSON vs JSONLD we loose track of other things like CBOR and YAML. My vote is for application/did+json
15:20:33 <Wip> ... implementations need to know how to parse the document
15:20:35 <decentralgabe> ack ivan
15:21:03 <manu> q+ to ask if it's "application/json", then what do we do for JSON-LD?
15:21:03 <Wip> ivan: Understand dmitriz opinion. But, the VCWG has decided to use application/vc for verifiable credentials
15:21:10 <decentralgabe> ack manu
15:21:10 <Zakim> manu, you wanted to note that we could have CBOR in the future. and to ask if it's "application/json", then what do we do for JSON-LD?
15:21:58 <Wip> manu: Not closed the door on CBOR or YAML. Could have did+cbor or did+yaml. But what do we do about jsonld. We could say application/did is jsonld
15:22:16 <Wip> ... Or we would have to get a new suffix through the jsonld working group
15:22:41 <Wip> ... Markus, the reason we would have different representations is to support CBOR and YAML
15:23:02 <Wip> ... One more option, for JSONLD DID documents we could use application/jsonld
15:23:20 <decentralgabe> q?
15:23:22 <dmitriz> s/we could use application/jsonld/we could use application/ld+json/
15:24:23 <Wip> decentralgabe: encourage people to consider discussion on an issue
15:24:35 <markus_sabadello> markus_sabadello has joined #did
15:24:41 <markus_sabadello> present+
15:24:43 <Wip> decentralgabe: time for one or two more
15:25:21 <decentralgabe> Subtopic: https://github.com/w3c/did-core/issues/842 Request for Guidance on Normalization Rules Enforcement
15:25:36 <Wip> manu: This is someone asking what the normalization rules are for URLs
15:25:58 <Wip> ... Letting implementors decide what level of normalization they support
15:26:16 <Wip> ... A response is the normalization rules for URLs is clear and exists in the WHATWG
15:26:35 <Wip> ... We would need to check these apply cleanly to DID URLs
15:26:46 <Wip> ... We could say we are using the WHATWG normalization rules
15:27:26 <Wip> ... Others state on the issue that people in the field are normalizing in different ways. Very few specs say anything about this.
15:27:32 <Wip> dmitriz: What is URL normalization?
15:28:04 <manu> These are the URL serialization rules in WHAT WG URL spec: https://url.spec.whatwg.org/#concept-url-serializer
15:28:07 <Wip> manu: This is about percent encoding. Having dots in the URL path. There is a concept called URL serialization
15:28:11 <Wip> ... See the link above
15:28:50 <Wip> ... apply a series of rules to get to a normalized URL
15:29:08 <Wip> ... problem is DIDs don't have hosts. So we need to analyze this more deeply
15:29:27 <Wip> ... This group needs to see if these rules negatively impact DIDs
15:29:30 <markus_sabadello> q+
15:29:39 <decentralgabe> ack markus_sabadello
15:29:47 <Wip> ... If they don't we should normatively state the WHATWG are the normalization rules we follow
15:30:37 <manu> q+
15:30:41 <Wip> markus_sabadello: Not looked at this in detail. But in the context of DID URL dereferencing. If we also have a path, query string on DID  URLs in the same way as on http URLs. Then my intuition is we should use the WHATWG rules
15:30:52 <decentralgabe> ack manu
15:30:59 <manu> https://www.w3.org/TR/did-core/#dfn-serviceendpoint
15:31:24 <Wip> manu: This is the location in the spec the issue is concerned with.
15:31:34 <dmitriz> we COULD sidestep the normalization of service endpoints issue. and require fully qualified URLs
15:31:46 <dmitriz> or not say anything about it.
15:31:51 <ivan> q+
15:31:52 <dmitriz> (which would mean removing the normalization requirement)
15:31:54 <Wip> ... Web browsers URL normalization rules are different from the RFC3936 rules
15:33:11 <Wip> ... options are 1) remove it and not say anything about normalization. 2) Leave it as is and people have to do it, knowing the libraries they will likely use will do something different. 3) Or state that we use the WHATWG rules used by web browsers
15:33:26 <Wip> ... I don't have a strong feeling about the direction
15:33:31 <decentralgabe> ack ivan
15:33:53 <Wip> ivan: removing the text is a problem for interoperability. We should not consider this
15:34:11 <Wip> ... I would see what is implemented in various programming environments
15:34:27 <Wip> ... As far as I know all of these use the WHATWG rules
15:34:44 <decentralgabe> q?
15:34:44 <manu> +1 to what ivan said.
15:35:45 <Wip> manu: I agree with ivan, lets look at the libraries and see what they do
15:36:03 <Wip> ... We should also generalize the spec text to say that any URLs should be normalized
15:36:24 <Wip> ... We will have to see what happens in specific DID URLs
15:37:16 <Wip> ... Unfortunately there are no tests/examples that show the differences between normalization rules
15:37:30 <markus_sabadello> markus_sabadello has joined #did
15:37:32 <Wip> ... We would also need our own tests against some fairly advanced DID URLs
15:37:48 <Wip> decentralgabe: Lets continue this at TPAC
15:37:52 <decentralgabe> Subtopic: DID Resolution PR 88 / 89
15:37:58 <decentralgabe> "https://github.com/w3c/did-resolution/pull/88
15:37:58 <decentralgabe> https://github.com/w3c/did-resolution/pull/89"
15:38:07 <Wip> q+
15:38:13 <decentralgabe> Simplify dereferencing of the DID fragment based on the media type
15:38:18 <decentralgabe> ack Wip
15:38:21 <markus_sabadello> q+
15:39:11 <decentralgabe> Wip: I put this on the agenda. We talked about it last week. Should the primary resource be the DID Document? it says 'first you get the DID Document in resolution, then primary resource...'
15:39:24 <swcurran> +1 to WIP about primary document
15:39:25 <decentralgabe> ack markus_sabadello
15:39:59 <Wip> markus_sabadello: agree, lets not have a big discussion about the naming of primary and secondary resource. I have been using the terms as introduced in original rfc3936
15:40:27 <Wip> ... PR 88 is an attempt to remove language related to processing the fragment. This depends on the media type
15:40:47 <Wip> ... Currently the text is specific to a JSONLD document. The intent of the PR is to simplify and remove this part
15:40:53 <manu> q+
15:41:22 <Wip> ... regarding the discussion of primary and secondary resource lets have a special topic about it. It effects a lot of things
15:41:36 <decentralgabe> ack manu
15:42:22 <Wip> manu: Fine with 88 being merged. Agree there was confusion with primary and secondary resource. I also found the current spec text clear on that
15:42:31 <Wip> ... not blocking 88
15:43:25 <Wip> decentralgabe: We will plan on a special topic call for 88 and 80 around this resource discussion
15:43:27 <decentralgabe> Topic: DID Resolution Issue/PR Processing
15:43:54 <Wip> decentralgabe: Any specific PRs / Issues to discuss
15:44:09 <decentralgabe> Subtopic: https://github.com/w3c/did-resolution/pull/49 Issue#48 fix Capitalization fix for DID spec
15:44:17 <Wip> q+
15:44:23 <decentralgabe> ack Wip
15:44:58 <markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3Apending-close
15:45:26 <Wip> markus_sabadello: Closing the above issues after this call.
15:45:35 <markus_sabadello> https://github.com/w3c/did-resolution/issues/29
15:45:36 <Wip> ... A couple of other issues I would like to mark pending close
15:45:53 <Wip> ... issue 29 about the term DID resolver being defined correctly
15:46:01 <Wip> ... I think this is addressed in the spec
15:46:03 <manu> +1 to closing this one
15:46:04 <Wip> +1 to closing
15:46:07 <markus_sabadello> https://github.com/w3c/did-resolution/issues/30
15:46:38 <Wip> ... Also issue 30 that can be marked pending close. It is about dereferencing and whose responsibility it is
15:46:45 <Wip> ... The spec also addresses this
15:46:51 <smccown> smccown has joined #did
15:47:11 <manu> +1 to closing this one as well
15:47:35 <Wip> q?
15:47:59 <Wip> ... I marked a couple of issues as good first issues. COntributions welcome.
15:48:05 <decentralgabe> https://github.com/w3c/did-resolution/issues/17, https://github.com/w3c/did-resolution/issues/18
15:48:25 <Wip> ... These issues are about the relationship between DID core and DID resolution
15:48:42 <Wip> ... It would be good to clarify this relationship in the spec with a couple of sentences
15:49:09 <manu> +1 to explaining relationships
15:49:10 <decentralgabe> Subtopic: good first issues -- https://github.com/w3c/did-resolution/issues/17, https://github.com/w3c/did-resolution/issues/18
15:49:11 <Wip> ... Explaining that DID resolution happens against DID core etc
15:49:21 <Wip> ... Anyone want to write about this?
15:49:36 <Wip> decentralgabe: Be great to get these issues assigned
15:50:09 <smccown> I'm happy to write some text for 17 & 18
15:50:23 <Wip> decentralgabe: Thanks for volunteering smccown
15:51:26 <Wip> markus_sabadello: Quite a few issues are labelled enhancement to the did-resolution spec
15:51:48 <Wip> ... Important to figure out the fundamentals and get common understanding across the WG
15:52:02 <Wip> ... Would rather focus on these big fundamental topics
15:52:09 <manu> +1 to focus on big issues first
15:52:39 <TallTed> i/Agenda Review, Introductions/present+ TallTed
15:52:53 <Wip> Kim: Did you mention the first DID method Wg
15:53:05 <Wip> ... We want to do a DID Method Wg kick off before TPAC
15:53:22 <ivan> q+
15:53:31 <Wip> ... This is an ad hoc meeting to settle some of the details for how the group will function
15:53:43 <Wip> ... I have more information here: https://blog.identity.foundation/did-method-standardization-initiative-progress-update-and-next-steps/
15:53:44 <decentralgabe> more info: https://blog.identity.foundation/did-method-standardization-initiative-progress-update-and-next-steps/
15:53:56 <decentralgabe> ack ivan
15:54:13 <Wip> ivan: For the minutes, this is not a W3C Working Group
15:54:47 <Wip> Kim: This is a DIF working group that includes a sharing agreement with the W3C. There is some followup work happening at TPAC to launch a W3C WG focused on DID Methods
15:55:05 <Wip> ... Idea would be to hand over work from the DIF Wg to the W3C Wg eventually
15:55:35 <Wip> decentralgabe: There is a meeting on this at TPAC on the DID Method standardization
15:55:40 <pchampin> RRSAgent, make minutes
15:55:42 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/19-did-minutes.html pchampin
15:55:51 <Wip> ... Thanks all, see you next week at TPAC
15:55:59 <manu> present+
15:58:05 <pchampin> RRSAgent, make minutes
15:58:06 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/19-did-minutes.html pchampin
15:58:15 <pchampin> m2gbot, debug
15:58:16 <m2gbot> comment would have been created for: https://github.com/w3c/did-core/pull/852
15:58:17 <m2gbot> comment would have been created for: https://github.com/w3c/did-core/issues/863
15:58:18 <m2gbot> comment would have been created for: https://github.com/w3c/did-core/issues/842
15:58:19 <m2gbot> comment would have been created for: https://github.com/w3c/did-resolution/pull/88
15:58:20 <m2gbot> comment would have been created for: https://github.com/w3c/did-resolution/pull/89
15:58:21 <m2gbot> comment would have been created for: https://github.com/w3c/did-resolution/pull/49
15:58:22 <m2gbot> Something wrong happened: GitHub
19:35:10 <Zakim> Zakim has left #did
23:09:35 <dmitriz> dmitriz has joined #did