14:49:58 <RRSAgent> RRSAgent has joined #did
14:50:02 <RRSAgent> logging to https://www.w3.org/2024/09/12-did-irc
14:50:04 <Wip> rrsagent, draft minutes
14:50:05 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/12-did-minutes.html Wip
14:50:11 <Wip> rrsagent, make logs public
14:50:28 <Wip> Meeting: Decentralized Identifier Working Group
14:50:35 <Wip> Chair: Will Abramson
14:50:43 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Sep/0009.html
14:54:26 <Wip> present+
14:56:41 <pchampin> present+
14:56:54 <m2gbot> m2gbot has joined #did
15:00:18 <TallTed> TallTed has joined #did
15:02:27 <markus_sabadello> markus_sabadello has joined #did
15:02:31 <TylerM> TylerM has joined #did
15:02:42 <TylerM> present+
15:03:13 <ivan> present+
15:03:26 <TallTed> present+
15:03:55 <KevinDean> KevinDean has joined #did
15:03:57 <KevinDean> present+
15:03:59 <KevinDean> https://w3c.github.io/scribe2/scribedoc.html
15:04:01 <markus_sabadello> present+
15:04:27 <swcurran> swcurran has joined #did
15:04:31 <bigbluehat> bigbluehat has joined #did
15:04:33 <swcurran> +present
15:04:36 <KevinDean> KevinDean has joined #did
15:04:40 <JoeAndrieu> JoeAndrieu has joined #did
15:04:55 <swcurran> present+
15:04:56 <pchampin> scribe+
15:05:02 <bigbluehat> present+
15:05:03 <JoeAndrieu> present+
15:05:10 <KevinDean> present+
15:05:13 <KevinDean> https://w3c.github.io/scribe2/scribedoc.html
15:05:13 <manu> present+
15:05:34 <Wip> Topic: Agenda Review. Introductions
15:06:05 <pchampin> Wip: simple agenda, we are goint to touch on TPAC, then talk about what happened on DID core and DID resolution
15:06:12 <pchampin> ... any amendment to the agenda?
15:06:12 <Wip> q?
15:06:30 <pchampin> ... Stephen, do you want to introduce yourself?
15:06:40 <manu> q+ to note upcoming DID Standardization meeting next week (agenda+, sorry I'm late!)
15:06:55 <pchampin> swcurran: consultant, working with the government. Been working with DIDs for a while.
15:07:18 <pchampin> ... did:trust, did:web, did:tdw (for which I have a meeting just after this one)
15:07:43 <pchampin> ... We will discuss how to integrate features of did:tdw into did:web.
15:07:50 <Wip> ack manu
15:07:50 <Zakim> manu, you wanted to note upcoming DID Standardization meeting next week (agenda+, sorry I'm late!)
15:07:53 <pchampin> ... Just joined this group as an IE a week ago.
15:08:10 <pchampin> manu: I would like to add an agenda item about what Stephen just mentioned.
15:08:16 <JennieM> JennieM has joined #did
15:08:30 <danpape> danpape has joined #did
15:08:38 <pchampin> Wip: before we open this subject, other introductions?
15:08:43 <danpape> present+
15:08:54 <Wip> ack manu
15:08:59 <pchampin> TylerM: I'm with Digital Bazaar.
15:09:02 <Wip> Topic: DID Method Standardization
15:09:25 <swcurran> present-
15:09:26 <pchampin> manu: as Stephen mentioned, we are working on did:tdw.
15:09:45 <swcurran3> swcurran3 has joined #did
15:10:01 <pchampin> ... We can't  standardize DID method in this WG, but we are having joint meetings with the CCG, DIF, and others, about DID method standardization.
15:10:08 <pchampin> ... Anyone interested is welcome.
15:10:41 <pchampin> ... We'll let everyone know when this happen. We want to have at least one meeting before TPAC, as we will be presenting the status of the work in a TPAC breakout session.
15:10:56 <Wip> q?
15:11:10 <Wip> Topic: TPAC Preparation
15:11:24 <Wip> https://docs.google.com/spreadsheets/d/1rhgWEgT_H98PwAMhBUBcRDNNVT28QPxuefP9U2cpBbY/edit?pli=1&gid=179611341#gid=179611341
15:11:40 <pchampin> Wip: firsrt thing: has any one signed up on the attendees sstylesheet (link above)?
15:11:45 <brent> brent has joined #did
15:11:55 <pchampin> ... This is useful for us to know who will attend when, as well as dietary constraints.
15:12:05 <swcurran0> swcurran0 has joined #did
15:12:07 <Wip> https://docs.google.com/presentation/d/1s6tf0VOKdIr3Gf_t7ROypyeg07Lk_myoOFby6AL4I7g/edit#slide=id.p
15:12:17 <pchampin> ... Second: Dan has seen a slide deck that we will use for the two days (link above).
15:12:33 <pchampin> ... In here you can find the agenda for the days (maybe subject to change).
15:12:43 <swcurran0> present+
15:12:57 <pchampin> ... An email was sent to people who are expected to present: please put your material in the deck.
15:13:36 <Wip> https://www.w3.org/events/meetings/456057ed-2184-4870-86a4-f01c8158d3c0/
15:13:37 <KevinDean> q+
15:13:48 <Wip> https://www.w3.org/events/meetings/47b69f98-794f-4aa4-9aa5-b8a9f0c1473e/
15:13:54 <pchampin> ... Finally, PA flagged to me that on Monday, some people might be interested in conflicting meetings (2 links above).
15:14:04 <manu> q+
15:14:06 <Wip> ack KevinDean
15:14:21 <ivan> q+
15:14:24 <pchampin> ... Maybe we can have chat to have a sense of how much trouble this will be.
15:15:13 <pchampin> KevinDean: is it possible for non-participants to attend WG meetings during TPAC?
15:15:33 <pchampin> pchampin: yes, any TPAC participant can attend WG meetinds as observers.
15:15:33 <Wip> ack manu
15:15:50 <ivan> q-
15:16:01 <pchampin> manu: about the Digital Credential API meeting, it would be nice to be able to attend it. It is directly relevant to what we are doing.
15:16:34 <pchampin> ... It would be good to attend that meeting and signaling DID as a possible part of DIgital Credential API.
15:17:25 <pchampin> ... The Web payement work is also about Credentials, so it would be relevant, although the Web Payement group has taken a very different and specific route. IMO, less important but maybe interesting.
15:18:01 <pchampin> ... All that being said, it is challenging if it takes time away from our WG meeting.
15:18:09 <pchampin> Wip: thanks for this input
15:18:11 <Wip> Topic: DID Core Issue & PR Processing
15:18:12 <manu> q+
15:18:23 <Wip> ack manu
15:18:48 <pchampin> manu: I'm going through our class 3 issues that are not ready to PR, then class 2 time permitting, and so on.
15:18:49 <manu> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3A%22class+3%22
15:19:01 <manu> subtopic: https://github.com/w3c/did-core/issues/836
15:19:18 <pchampin> manu: this input was received 3 years ago by Travis, from Microsoft
15:19:36 <pchampin> ... they would like to see one foundation key representation.
15:19:52 <pchampin> ... It means that we need to pick a single key representation, caused a lot of argument.
15:20:17 <pchampin> ... It is now clear that people have expressed keys in various different formats.
15:21:02 <pchampin> ... JWT, multikey (as used in did:key), ...
15:21:36 <pchampin> ... At the California DMV, we have been using DID to express keys, starting with did:jwk, to actually express an X509 key.
15:21:59 <pchampin> ... Our implementation experience has been pretty terrible. Most libraries on the marker don't check certificate chains.
15:22:22 <pchampin> ... So they would report that a signature is fine, even if the chain is broken.
15:22:53 <ivan> q+
15:23:10 <pchampin> ... All that said, the suggestion that we would have: yes, one key representation would be ideal, but the best we can do is to be explicit about what format is used.
15:23:13 <Wip> ack ivan
15:23:36 <pchampin> ivan: I'm not an expert, but on a specification issue:
15:24:03 <pchampin> ... not sure if we have a resolution to use the Controller Document, but it seems to me that this is the direction of the WG.
15:24:13 <manu> q+
15:24:15 <Wip> ack manu
15:24:24 <pchampin> ... The Controller Document mentions JWK and multikey as the two possible format, so we would inherit these two.
15:24:35 <pchampin> manu: I agree.
15:24:47 <pchampin> ... Another thing that's maybe a little more controversial:
15:24:53 <ivan> q+
15:25:05 <pchampin> ... I don't believe that we will ever have a unified key format.
15:25:17 <JoeAndrieu> +1 for key format flexibility
15:25:25 <ivan> q-
15:25:45 <pchampin> ... SSH key formats have had their own format for 10 years. HEM and JWK exist and are widely used.
15:25:52 <Wip> q+
15:25:54 <pchampin> ... Multikey is gaining adoption.
15:26:18 <pchampin> ... The current language says "to improve interop, we are supporting only 2 formats."
15:26:21 <markus_sabadello> q+
15:26:28 <pchampin> ... I'm questionning whether we should revise that language.
15:26:36 <Wip> ack Wip
15:26:36 <KevinDean> +1 to removing AND acknowledging multiple key formats
15:26:56 <pchampin> Wip: I'm in favor of flexible key representation.
15:27:06 <Wip> ack markus_sabadello
15:27:11 <manu> q+ to note "your key format" is supported via DID extension mechanism.
15:27:21 <pchampin> ... Say I have my own key representation, how do I get it in the Controller Document?
15:27:46 <pchampin> markus_sabadello: some people say that standards are about making choices, so we should pick one format,
15:28:00 <pchampin> ... but I don't think this is practical. We need an extensibility method.
15:28:17 <pchampin> ... Some DID methods may have preference for certain key representation.
15:28:31 <Wip> ack manu
15:28:31 <Zakim> manu, you wanted to note "your key format" is supported via DID extension mechanism.
15:28:37 <pchampin> ... In the spec, we should give examples of the most common ones, but also explain how to extend.
15:28:48 <pchampin> manu: the spec already supports that through the extension mechanism.
15:29:33 <pchampin> ... If you want to use PublicKeyHex or PublicKeyHem for example, the vocabulary terms exist. You could put them in your JSON-LD context.
15:30:30 <pchampin> ... You can register your own properties, requires a JSON-LD context. We have always supported this.
15:30:35 <manu> q+
15:30:38 <Wip> ack manu
15:30:55 <pchampin> Wip: we need some text explaining this.
15:31:19 <KevinDean> q+
15:31:29 <ivan> +1 to the drafty content of Manu...
15:31:37 <pchampin> manu: I can give it a try: saying "it would be great if we had a unified key format, but here are the ones that exist" + advising against adding more
15:31:37 <Wip> ack KevinDean
15:32:05 <pchampin> KevinDean: I support the idea of flexibility and the ability to support additional key formats.
15:32:33 <pchampin> ... For a minimum implementations, it is useful to know which subset are most likely to be supported.
15:32:50 <Wip> Topic: DID Resolution PR and Issue Processing
15:32:51 <dmitriz> dmitriz has joined #did
15:33:10 <markus_sabadello> https://github.com/w3c/did-resolution/pull/49
15:33:25 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/49
15:33:57 <pchampin> markus_sabadello: this is a very old PR.
15:33:59 <manu> +1 to close
15:34:32 <pchampin> ... Just an editorial thing, no need to spend much time. Will marke it as "pending close"?
15:34:32 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/88
15:34:43 <pchampin> s/"pending close"?/"pending close"
15:35:42 <pchampin> markus_sabadello: this remove the part about dereferencing secondary resource. This is covered by the media-type.
15:35:46 <JoeAndrieu> q+
15:35:49 <Wip> ack JoeAndrieu
15:36:09 <pchampin> JoeAndrieu: last time we talked about primary/secondary resources, I found it confusing.
15:36:29 <pchampin> ... My understanding is that the primary resource of a DID URL or DID is the DID document.
15:36:44 <pchampin> ... Secondary resources are the ones that the DID document tells you how to reach.
15:37:17 <pchampin> markus_sabadello: the other PR is a bit about that.
15:37:29 <pchampin> ... In my view, the primary resource can be the DID document, but can be something else.
15:37:30 <Wip> https://github.com/w3c/did-resolution/pull/89
15:37:50 <pchampin> ... The primary resource is what you get when you retrieve the DID URL minus the fragment.
15:37:56 <JoeAndrieu> q+ what else can it be? That's my concern.
15:38:02 <JoeAndrieu> q+ to ask what else can it be? That's my concern.
15:38:07 <pchampin> ... The secondary resource is what you get when you include the fragment.
15:38:10 <Wip> ack JoeAndrieu
15:38:10 <Zakim> JoeAndrieu, you wanted to ask what else can it be? That's my concern.
15:38:13 <pchampin> ... That's what the URI RFC says.
15:38:16 <ivan> q+
15:38:24 <pchampin> JoeAndrieu: what other resource is it going to be?
15:38:28 <manu> q+ to ask about "what if it is not a JSON-LD document"?
15:39:14 <JoeAndrieu> q+ my point is the DID URL refers to a secondary resource
15:39:18 <JoeAndrieu> q+ to say my point is the DID URL refers to a secondary resource
15:39:18 <pchampin> ... I think the primary resource of a DID is what you defef the DID. This would be the DID document, and this is consistent with the RFC.
15:39:36 <pchampin> markus_sabadello: if the DID URL does not have any additional path or query part, then I agree.
15:39:47 <Wip> ack ivan
15:39:50 <pchampin> ... But if you add query strings or parameters, the result might be different.
15:39:57 <pchampin> ivan: I was always bothered by this earlier.
15:40:16 <pchampin> ... I understand what markus_sabadello says, up to the point where you talk about fragments.
15:40:31 <pchampin> ... In my understanding, fragments talk about a part of the document, as in HTML.
15:40:44 <markus_sabadello> q+
15:40:46 <Wip> ack manu
15:40:46 <Zakim> manu, you wanted to ask about "what if it is not a JSON-LD document"?
15:41:59 <pchampin> manu: what you say is that fragment processing is up to the media-type, full stop.
15:42:12 <pchampin> ... Is that what effectively what this PR is saying?
15:42:13 <Wip> ack JoeAndrieu
15:42:13 <Zakim> JoeAndrieu, you wanted to say my point is the DID URL refers to a secondary resource
15:42:38 <pchampin> JoeAndrieu: I understand what markus_sabadello is saying, but I don't agree.
15:42:58 <Wip> ack markus_sabadello
15:43:03 <manu> I agree with Joe's more coherent framing, FWIW.
15:43:07 <pchampin> ... Saying that a DID URL identifies a secondary resource of the DID document is confusing.
15:43:31 <ivan> q+
15:43:43 <JoeAndrieu> q+ to yes. we DO need to get the DID Document
15:44:00 <bigbluehat> fragment identifier's are "client side" only
15:44:01 <pchampin> markus_sabadello: what you say is like saying: when I have an HTTP URL, you would first need to fetch the root of this URL before getting the document.
15:44:38 <pchampin> ... in did:tdw, if you dereference the /whosis, you don't get the DID document.
15:44:46 <pchampin> s|fragment identifier's are "client side" only|
15:44:57 <Wip> ack ivan
15:45:13 <pchampin> ivan: I think it would be better to separate two things:
15:45:51 <pchampin> ... 1 the path and query string, for which I agree with markus_sabadello, it may deference to something different that the "root" URL
15:46:12 <pchampin> q+ to talk about "fragment"
15:46:24 <pchampin> ... 2 fragments, for which the client needs to do something with the whole content
15:46:24 <KevinDean> https://datatracker.ietf.org/doc/html/rfc3986#section-3.5
15:46:26 <Wip> ack JoeAndrieu
15:46:26 <Zakim> JoeAndrieu, you wanted to yes. we DO need to get the DID Document
15:46:26 <KevinDean> q+
15:46:29 <markus_sabadello> q+
15:46:35 <pchampin> ... those are different things, we need to treat them separately
15:46:46 <pchampin> JoeAndrieu: markus_sabadello, we are talking past each other
15:47:09 <pchampin> ... to use the /whois  URL, you need the DID document. This is different from how HTTP URIs work.
15:47:24 <swcurran0> q+
15:47:28 <Wip> ack pchampin
15:47:28 <Zakim> pchampin, you wanted to talk about "fragment"
15:47:33 <manu> scribe+
15:47:56 <swcurran0> q-
15:48:24 <manu> pchampin: I disagree with Ivan, looked up RFC for URIs. Fragment identifiers don't identify "fragments". The spec talks about secondary resources as the things that are identified by fragments, not bound to parts of whole representation ... and can be entirely different e.g., used in RDF to refer to things "outside" the document.
15:49:12 <swcurran0> +1
15:49:18 <Wip> ack KevinDean
15:49:18 <manu> pchampin: With respect to what Joe said, not an expert in DID Resolution, what you're saying is you need DID Document, that makes the DID DOcument "primary", but not in the sense of the RFC. The second one is "primary", agree with markus, maybe we need another term to not clash w/ RFC terminology.
15:49:53 <pchampin> KevinDean: link above to the definition of fragments / secondary document
15:49:59 <Wip> ack markus_sabadello
15:50:16 <pchampin> ... we must be careful when we refer to terminology.
15:50:25 <pchampin> Wip: we need to move forward.
15:50:30 <bigbluehat> From RFC3985#section-3.5
15:50:30 <bigbluehat> > The identified secondary resource may be some portion or subset of the primary    resource, some view on representations of the primary resource, or  some other resource defined or described by those representations.
15:50:51 <Wip> See issues here - https://github.com/w3c/did-resolution/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
15:51:35 <pchampin> markus_sabadello: the section about dereferencing tries to stay really close to RFC3986
15:52:23 <pchampin> ... the primary resource is what you get when you dereference the URL with the path and query string, but without the fragment.
15:52:35 <JoeAndrieu> q+ to say it seems like we won't reach consensus on the meaning of primary and secondary resource. We should find other language.
15:52:40 <pchampin> ... again, see the example of /whois.
15:52:41 <swcurran0> +1 to Markus that the primary resource may not be a DIDDoc -- significantly opens up the power of DID URLs
15:52:44 <Wip> ack JoeAndrieu
15:52:44 <Zakim> JoeAndrieu, you wanted to say it seems like we won't reach consensus on the meaning of primary and secondary resource. We should find other language.
15:53:09 <manu> q+
15:53:09 <pchampin> JoeAndrieu: we probably are not going to get consensus on "primary/secondary document"
15:53:11 <Wip> ack manu
15:53:20 <pchampin> ... we need to coin new terms and be clear about what we mean by that.
15:53:26 <markus_sabadello> q+
15:53:30 <swcurran0> -1 to new language.
15:53:42 <Wip> ack markus_sabadello
15:53:45 <pchampin> manu: if we use new language, it may confuse people even more. We will need to map it to existing language, explain why we came up with our own...
15:54:25 <manu> That was clear, markus_sabadello
15:54:25 <Wip> ack JoeAndrieu
15:54:36 <pchampin> markus_sabadello: if you look at the resolution spec, it has 3 steps: 1. resolve the DID, 2. resolve the primary resource, 3. resolve the secondary resource
15:55:04 <markus_sabadello> https://w3c.github.io/did-resolution/#dereferencing-algorithm
15:55:11 <pchampin> JoeAndrieu: in 4.3 the first step is "getting the primary resource"; may be that requires a re-indexing of the section
15:55:33 <pchampin> Wip: I'll try to read that section; maybe others can review it
15:55:51 <pchampin> ... markus_sabadello, which of the two PRs we mentioned is the best place to continue the discussion?
15:56:16 <pchampin> markus_sabadello: both are relevant, 88 and 89
15:56:45 <markus_sabadello> 4.3 says: "it consists of the following steps: Resolving the DID, dereferencing the primary resource, and dereferencing the secondary resource "
15:56:50 <swcurran0> About the did:tdw meeting -- agenda with Zoom link is: https://hackmd.io/k4cIK9vQSlaeg2pdHE51IQ. Meeting starts now.
15:56:58 <pchampin> Wip: markus_sabadello marked a number of issues and pending_close, chime in if that concerns you
15:57:05 <pchampin> RRSAgent, make minutes
15:57:07 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/12-did-minutes.html pchampin
18:01:53 <Zakim> Zakim has left #did
18:12:08 <dlehn2> dlehn2 has joined #did
20:21:25 <dmitriz> dmitriz has joined #did
20:26:38 <dmitriz> dmitriz has joined #did