15:48:48 <RRSAgent> RRSAgent has joined #did
15:48:52 <RRSAgent> logging to https://www.w3.org/2025/01/23-did-irc
15:48:58 <Wip> rrsagent, draft minutes
15:48:59 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/23-did-minutes.html Wip
15:49:07 <Wip> rrsagent, make logs public
15:49:16 <Wip> Meeting Decentralized Identifier Working Group
15:49:25 <Wip> Meeting: Decentralized Identifier Working Group
15:49:35 <Wip> Chair: Will Abramson
15:49:42 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Jan/0009.html
15:58:51 <TallTed> TallTed has joined #did
16:01:37 <markus_sabadello> markus_sabadello has joined #did
16:01:44 <swcurran> swcurran has joined #did
16:01:46 <manu> present+
16:03:01 <swcurran> present+
16:04:04 <ivan> present+
16:04:05 <JoeAndrieu> JoeAndrieu has joined #did
16:04:49 <bigbluehat> bigbluehat has joined #did
16:04:55 <Wip> Topic: agenda review
16:04:55 <TallTed> present+
16:05:03 <swcurran> scribe: swcurran
16:05:29 <swcurran> Chair: Wip
16:05:37 <manu> q+
16:05:40 <Wip> ack manu
16:05:47 <swcurran> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Jan/0009.html
16:07:31 <swcurran> manu: Would like to get a DID Methods standardization working group chartered at W3C. Any ideas on the timing of establishing such a group, and who would like to know who the staff would be.  Not being done here, so would like to cover the process that most of us will be involved in.
16:07:45 <JennieM> JennieM has joined #did
16:07:47 <dmitriz> dmitriz has joined #did
16:08:07 <swcurran> ... one of the chairs is here.  Would like to discuss to move it forward.
16:08:08 <pchampin> q+
16:08:12 <Wip> ack pchampin
16:08:20 <JennieM> present+
16:08:33 <swcurran> Topic:  DID Methods standardization Working Group
16:09:02 <manu> q+
16:09:17 <Wip> q+
16:09:31 <Wip> ack manu
16:09:43 <swcurran> pchampin: I have too much on plate to take it, but am default so will help. Can help starting on moving it forward.
16:10:15 <swcurran> manu: Happy to move draft charter forward. Need a place to work on that. Will work with Marcus, but need W3C to provide a place to do this.
16:10:56 <Wip> ack Wip
16:11:11 <swcurran> ... Can the repo be made so that we can create a PR into the Draft Charter.  Marcus as one of the DIF DID Method Standardization chairs can help coordinate with that group.
16:11:42 <swcurran> wip: Adds another working group for the same people.  Seems like it might be a lot on people's plates.
16:11:43 <manu> It is a concern :)
16:11:49 <Wip> Topic: DID Core
16:11:58 <manu> q+
16:12:02 <Wip> ack manu
16:12:07 <bigbluehat> present+
16:12:17 <manu> subtopic: https://github.com/w3c/did-core/pull/877
16:12:38 <swcurran> manu: Nothing a lot has changed -- the big PR that rationalizes DID Core to depend on the CID spec.
16:12:51 <Wip> q+
16:12:59 <smccown> smccown has joined #did
16:13:06 <smccown> present+
16:13:09 <swcurran> s/Nothing/Not/
16:13:21 <Wip> ack Wip
16:13:41 <swcurran> ... A tricky one -- hard to get it easily aligned.
16:13:58 <manu> q+
16:14:13 <swcurran> Wip: In some places there seems to be normative changes. Notably around "id"s.  Changing to URL.
16:14:32 <Wip> ack manu
16:14:35 <swcurran> ... "identifiers used in verification methods can be changed to URLs"
16:15:04 <PDL-ASU> PDL-ASU has joined #did
16:15:21 <PDL-ASU> present+
16:15:43 <swcurran> manu: There is the use case that a DID Method points to a URL.  Only change was made to the top most id (root). For all other IDs, noted that DID syntax is allowed -- although CID allows URLs.
16:16:12 <Wip> q+
16:16:22 <swcurran> ... For service endpoints -- most of them are URLs -- but that has always been allowed.
16:16:23 <Wip> q-
16:16:57 <swcurran> ... This PR allows for verificationMethods to be URLs on the web.  If we don't have that, we lose the ability to do that.
16:17:15 <swcurran> Wip: This is a change.  Is it a concern for others?
16:17:18 <smccown> q+
16:17:19 <JoeAndrieu> q+
16:17:22 <Wip> ack smccown
16:18:25 <Wip> ack JoeAndrieu
16:18:34 <swcurran> smccown: Not a problem. Does come back to a concern with LinkedData, as you can't verify it.  You can't sign it and verify it and so it could change. We have accepted that in the past but its on ongoing concern.
16:19:38 <manu> q+
16:19:41 <Wip> ack manu
16:19:44 <swcurran> JoeAndrieu: There has not been a use for URLs verificationMethods. There is no definition of how the VM is secured when it is a URL, unlike for a DID.
16:20:02 <JoeAndrieu> q+ to say it is not EVERYTHING must be a DID
16:20:11 <markus_sabadello> q+
16:20:42 <Wip> ack JoeAndrieu
16:20:42 <Zakim> JoeAndrieu, you wanted to say it is not EVERYTHING must be a DID
16:20:43 <swcurran> manu: Could make it that it has to be a DID. If we say it has to be a DID, and they use did:web, we have the same issue.  Entirely dependent on the DID Method. There is no protection in the base version of DID Web.
16:21:20 <manu> q+ to suggest I just keep it at MUST be a DID.
16:21:32 <Wip> ack markus_sabadello
16:21:38 <manu> q+ to suggest SHOULD :P
16:21:38 <dmitriz> +1 joe
16:21:49 <swcurran> JoeAndrieu: The difference is that did:web is a published method and it is available for discussion, weaknesses etc. If you just put a URL, you have not of that.  Maybe SHOULD be a DID, and talk about the issues.
16:22:00 <dmitriz> (re SHOULD, and mentioning the issues in the spec)
16:22:14 <Wip> ack manu
16:22:14 <Zakim> manu, you wanted to suggest I just keep it at MUST be a DID. and to suggest SHOULD :P
16:22:20 <swcurran> markus_sabadello: Missed the comment.
16:23:19 <swcurran> manu: Reviewing the spec...its in the table about IDs and notably that a VM is a DID or a map.
16:23:19 <Wip> https://github.com/w3c/did-core/pull/877/files#r1920318242
16:23:24 <manu> q?
16:23:28 <PDL-ASU> q+
16:24:47 <swcurran> manu: trying to decide on SHOULD or MUST.  Since did:web could be used, then URL is the same.  Maybe put it back to MUST, and then a separate discussion on backing off that.
16:24:57 <Wip> ack PDL-ASU
16:25:23 <manu> q+
16:25:39 <swcurran> PDL-ASU: Specs often talk about the securing and the issues.  If the URL was a hashlink doesn't that give the security.
16:25:45 <Wip> ack manu
16:27:36 <JoeAndrieu> q+ to ask how hashlink helps with dynamic documents?
16:27:37 <swcurran> manu: Will open an issue to deal with this point separately.  Re: PDL-ASU point -- there is not a way to make the hashlink of a fragment (as this is likely to be).  So hard to handle via an HL. Could be ways to do that, but hard to do.
16:27:57 <PDL-ASU> Agreed that's the point Joe was raising. Sounds like we should write that down. :-)
16:28:01 <Wip> Topic: DID Extensions
16:28:05 <Wip> https://github.com/w3c/did-extensions/issues
16:28:34 <swcurran> Wip: Please take some time to review the issues.  There are pending close issues. Any comments now on those?
16:28:44 <Wip> q?
16:28:44 <manu> q+
16:28:49 <swcurran> ... There are some fun issues, so please take a look.
16:28:54 <Wip> q- JoeAndrieu
16:28:57 <Wip> ack manu
16:29:43 <swcurran> manu: Heads up that Wip found that the DID Extensions build is not working properly, but it has now been fixed, and the auto-publishing to TR-space is working.
16:29:51 <Wip> Topic: DID Resolution
16:30:16 <Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3Aenhancement%20%20sort%3Aupdated-asc
16:30:27 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/51
16:30:27 <swcurran> Wip: We'll go through the issues.
16:30:57 <swcurran> Wip: Do we want to define a way for a resolver to say what it supports?
16:31:33 <swcurran> Wip: Goal -- go through these issues to identify ones that need to go in the spec -- and looking for volunteers.
16:31:35 <Wip> q?
16:31:45 <markus_sabadello> q+
16:31:48 <Wip> ack markus_sabadello
16:31:49 <manu> q+
16:32:28 <dmitriz> q+
16:32:29 <Wip> ack manu
16:32:51 <swcurran> markus_sabadello: Lean not, but could help with the practicality argument -- a standard way to ask a resolver supports.
16:32:55 <dmitriz> q-
16:33:09 <swcurran> manu: Can just ask to resolve a DID of a type, and it either does or doesn't.
16:33:14 <dmitriz> q+
16:33:46 <JoeAndrieu> q+ to avoid programmatic discovery because trust should not be automated
16:34:08 <swcurran> manu: That said -- we would not encourage anyone to use a resolver blindly -- it would be done at coding time and the human trust (and features) would be evaluated at that time. Not need dynamically.
16:35:01 <swcurran> ... Gets into the /whois capability that allows a DID to express information about itself. Don't put in the spec, but incubated in practice/other spec, and then see if we want to add it into the core spec.
16:35:08 <Wip> ack dmitriz
16:35:29 <Wip> ack JoeAndrieu
16:35:29 <Zakim> JoeAndrieu, you wanted to avoid programmatic discovery because trust should not be automated
16:35:32 <swcurran> dmitriz: Another vote for not in the core spec. Echo Manu's comments.
16:36:01 <swcurran> JoeAndrieu: +1 to evaluating why to trust a resolver -- not just a what it supports.
16:36:09 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/39
16:36:12 <swcurran> Wip: Resolution? Enough to close?
16:36:28 <markus_sabadello> q+
16:36:33 <Wip> ack markus_sabadello
16:36:45 <PDL-ASU> note the concerns in issue 51 and close it - my view
16:37:13 <swcurran> markus_sabadello: Can be solved with a new parameter or resolution option. Do we want them in the spec or in the extension?  In this case, feels like more for an extension.
16:37:24 <manu> q+ extension spec
16:37:29 <Wip> ack manu
16:37:34 <swcurran> Wip: Anyone want to carry it in the main spec?
16:37:34 <manu> q- extension
16:37:37 <manu> q- spec
16:37:40 <swcurran> manu: Make it an extension.
16:37:48 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/40
16:38:02 <markus_sabadello> q+
16:38:04 <Wip> ack markus_sabadello
16:38:15 <JoeAndrieu> q+ to ask about expansion
16:38:34 <swcurran> markus_sabadello: This is an extension. Makes them easier to consume but could be an extension.
16:38:36 <manu> q+ to support expansion in core spec.
16:38:42 <Wip> ack JoeAndrieu
16:38:42 <Zakim> JoeAndrieu, you wanted to ask about expansion
16:39:30 <markus_sabadello> q+
16:39:36 <Wip> ack manu
16:39:36 <Zakim> manu, you wanted to support expansion in core spec.
16:39:42 <swcurran> JoeAndrieu: Not sure of the idea of extension -- DID Method specific.  Can't verify the DIDDoc if there are extensions.
16:40:09 <JoeAndrieu> q+ to say it still doesn't apply to did:btc1
16:40:52 <swcurran> manu: Feature is only for a DID URLs -- fragments.  "#key-1" -- should use automatically mean that the DID is prepended.
16:41:20 <Wip> ack markus_sabadello
16:41:28 <swcurran> manu: Should be in the core, so there is no need to repeat the DID everywhere and creates opportunity for errors.
16:42:01 <swcurran> markus_sabadello: Not DID Method specific. You get the DIDDoc as is, and then could do transformations.
16:42:02 <Wip> ack JoeAndrieu
16:42:02 <Zakim> JoeAndrieu, you wanted to say it still doesn't apply to did:btc1
16:42:18 <manu> q+
16:42:34 <Wip> ack manu
16:42:45 <swcurran> JoeAndrieu: You lose independent verification if the resolver gives something back other than the DIDDoc.
16:43:07 <swcurran> manu: Presumed it to be a flag so not needed.
16:43:15 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/46
16:43:42 <markus_sabadello> q+
16:43:46 <Wip> ack markus_sabadello
16:44:12 <manu> q+
16:44:35 <ivan> q+
16:44:55 <swcurran> markus_sabadello: Could be supported by an optional flag.  Would not be a DIDDoc, and the resolver would not return a DIDDoc. Flag could result in a JWK set in the dereferencing.  Use cases in OpenID.
16:44:59 <JoeAndrieu> q+ to say its easy to have a DID URL to return JWKs, but they cannot be canonical
16:45:01 <Wip> ack manu
16:45:52 <Wip> ack ivan
16:45:56 <swcurran> manu: +1 to providing an option. Resolvers may support it or not. Extension - not in the core spec. Having to define transformational algorithms would be needed.
16:46:25 <swcurran> ivan: Not sure why saying not a DID. A DID is a CID, and the CID allows you to do that. Should be valid DIDDoc.
16:46:31 <Wip> ack JoeAndrieu
16:46:31 <Zakim> JoeAndrieu, you wanted to say its easy to have a DID URL to return JWKs, but they cannot be canonical
16:47:30 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/52
16:47:31 <swcurran> JoeAndrieu: Think it is out of scope. DIDDoc is about getting the canonical DIDDoc. Can get other things already. What you can't infer is that the JWKS are canonical. Going to confuse the security model.
16:47:49 <markus_sabadello> q+
16:48:01 <manu> q+
16:48:02 <swcurran> Wip: Could be an extension.
16:48:04 <Wip> ack markus_sabadello
16:49:20 <Wip> ack manu
16:49:22 <swcurran> markus_sabadello: Could be useful as metadata properties. Concept of "network" (namespaces within a method) is not in the DID Core -- is used by some Methods.  Could be useful to return other information.  I think this is an extension.
16:49:30 <swcurran> manu: +1 to extension.
16:49:35 <JoeAndrieu> +1 to extension. seems useful for some methods
16:49:44 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/69
16:49:45 <swcurran> ... Not clear what a network is.  No examples.
16:50:58 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/87
16:51:00 <swcurran> markus_sabadello: This has been addressed -- exists. We have resolution and dereferencing result. Pen ding closed.
16:51:11 <swcurran> s/Pen ding/Pending/
16:51:29 <manu> q+
16:51:34 <Wip> ack manu
16:52:22 <ivan> q+
16:52:24 <swcurran> manu: Good idea to settle on Problem Details. Handled in other specs and works well. Nice if the DID Resolution spec so there was consistency across the specs (DI, DID, others)/.
16:52:26 <Wip> ack ivan
16:52:48 <swcurran> ivan: Formerly -- if have a DID error, inherits the CID error, so that covers it.
16:53:06 <swcurran> Wip: Argument to put it in the spec.  Any takers to put it in?
16:53:07 <manu> q+
16:53:10 <Wip> ack manu
16:53:21 <swcurran> manu: I'll volunteer.
16:53:44 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/10
16:53:57 <markus_sabadello> q+
16:54:01 <Wip> ack markus_sabadello
16:55:11 <swcurran> markus_sabadello: This is a bigger topic around caching.  Could be a mix of TTL and other metadata parameters.  Similar to DNS -- could follow that model, with a set of parameters.
16:55:15 <manu> q+
16:55:29 <Wip> ack manu
16:55:29 <swcurran> ... In the core spec.
16:56:03 <JoeAndrieu> q+ to say did-core, yes. controller-specified
16:56:07 <Wip> ack JoeAndrieu
16:56:07 <Zakim> JoeAndrieu, you wanted to say did-core, yes. controller-specified
16:56:07 <swcurran> manu: +1 for core spec. Multiple levels here. Speak to HTTP caching.  Avoid discussions like TTL within verificationMethods.  Can of worms there.
16:56:26 <manu> q+
16:56:52 <Wip> ack manu
16:56:57 <swcurran> JoeAndrieu: Should be in DID Core, and that the DID Controller can set. Needs to be based on what the Controller sets -- not at the DID Method level.
16:57:11 <swcurran> swcurran +1 to DID Controller.
16:57:25 <JoeAndrieu> Could be an extension for did-core (not in did-core itself)
16:58:05 <swcurran> manu: DID Method spec would say how to expose/caching.  DID Core would say how to express this.
16:58:07 <JoeAndrieu> q+ to say just a property
16:58:13 <Wip> ack JoeAndrieu
16:58:13 <Zakim> JoeAndrieu, you wanted to say just a property
16:58:45 <manu> concerned about it being a property -- worried about security concerns there -- controllers might do something that is not supported by the DID Method (creating security vulns)
16:59:11 <swcurran> Wip: One issue to go in. Most others are extensions.
16:59:12 <JoeAndrieu> present+
16:59:18 <pchampin> present+
16:59:35 <Wip> rrsagent, make minutes
16:59:36 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/23-did-minutes.html Wip
16:59:44 <Wip> zakim, end the meeting
16:59:44 <Zakim> As of this point the attendees have been manu, swcurran, ivan, TallTed, JennieM, bigbluehat, smccown, PDL-ASU, JoeAndrieu, pchampin
16:59:46 <Zakim> RRSAgent, please draft minutes
16:59:47 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/23-did-minutes.html Zakim
16:59:52 <Zakim> I am happy to have been of service, Wip; please remember to excuse RRSAgent.  Goodbye
16:59:54 <Zakim> Zakim has left #did