14:46:33 RRSAgent has joined #did 14:46:37 logging to https://www.w3.org/2024/10/17-did-irc 14:46:41 rrsagent, draft minutes 14:46:42 I have made the request to generate https://www.w3.org/2024/10/17-did-minutes.html Wip 14:46:48 rrsagent, make logs public 14:47:09 Meeting: Decentralized Identifier Working Group 14:47:17 Chair: Will Abramson 14:47:31 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Oct/0007.html 14:51:07 present+ 14:52:57 TallTed has joined #did 15:00:27 present+ 15:01:42 present+ 15:02:49 present+ 15:02:58 markus_sabadello has joined #did 15:03:59 present+ 15:04:05 scribe+ 15:04:24 Topic: Agenda Review 15:04:25 bigbluehat has joined #did 15:04:25 JoeAndrieu has joined #did 15:04:51 Wip: Agenda review -- announcement about calls, DID Extensions TR space, DID Core Media types, then over to DID Resolution issue/PR processing. Anything else to add? 15:04:57 q? 15:05:09 Topic: DIDWG Call Cancelled 31st of October 15:05:13 present+ 15:05:25 Wip: Announcement, we're canceling October 31st meeting due to IIW. 15:05:48 Wip: Dan is stepping back from being a Chair (which was planned), he won't be showing up to meetings anymore. 15:05:55 Topic: DID Extensions TR Space 15:05:55 JennieM has joined #did 15:06:01 present+ 15:06:13 Wip: DID Extensions and TR space, hoping to hand this over to PA for an overview of the problem and how we might solve them. 15:07:43 pchampin: The new document has a hierarchical structure, DID extensions, which points to other documents in subfolders on Github repository, after checking w/ sysadmins, we can't do that on TR (URL space for Technical Reports), every document is at top-level. What is currently .../TR/did-extensions/methods/ will now become .../TR/did-extensions-methods/ 15:07:44 danpape has joined #did 15:07:54 +present 15:07:58 dmitriz has joined #did 15:08:08 present+ danpape 15:08:11 pchampin: This requires a change in the Editor's change and then I will make a request for publication of those things, since they are "brand new", before we can automate their publication, we need to seed this process by normal request. 15:08:13 present+ 15:08:15 q+ 15:08:21 ack manu 15:08:26 scribe+ 15:08:38 manu: last week we had a resolution to do just that 15:09:01 pchampin: Yes, saw the resolution, before I can take an action, I need the repos to reflect this. 15:09:01 q+ 15:09:05 ack manu 15:09:06 q+ 15:09:17 manu: I can do it. Which repository do you mean? 15:09:39 ack ivan 15:09:52 ivan: Orginally queued to something else, where is the resolution? 15:10:41 ivan: Several documents in same repo, for historical reasons we did this for epub, one repo with 3 TRs and 10 notes all in same repo. You have to generate as many echidna files as there are documents that are automated and it works. You can copy how epub did their thing. 15:11:42 ivan: One thing that was not done is that we have to make a resolution on using Echidna, we can make that a generic resolution. 15:12:08 Wip: We should do that today? 15:12:09 q+ 15:12:22 ack manu 15:12:44 manu: we already did this resolution for Echidna 15:12:47 -> for VC: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-04-12-vcwg#resolution1 15:12:52 q+ 15:13:29 ivan: it lists an explicit set of documents, which might come back a bite us later 15:13:51 Wip: We think we've done it for all documents we have. 15:13:53 ... for example if we change the name of a document 15:13:57 ivan: Remember that we might change names, etc. 15:13:58 ack pchampin 15:14:23 pchampin: I just noticed that my page for listing resolutions is broken... links pasted do not work. 15:15:07 s/... for example if we change the name of a document/ 15:15:20 Wip: Let's move on unless anyone else feels differently? 15:17:19 q+ 15:17:42 pchampin: The links need to be changed, the structure needs to be changed. 15:17:45 ack ivan 15:18:26 ivan: this is required because echidna can not publish the documents in a hierarchy 15:18:55 manu: I can still this work for echidna without changing the structure of the repository 15:19:05 ivan: this would make your life harder 15:19:11 Topic: DID Core Media Types 15:15:39 subtopic: https://github.com/w3c/did-core/issues/863 15:19:34 i/Topic: DID Core/manu: actually, changing the structure would be even harder 15:20:00 manu: during TPAC, the TAG suggested to add some text in the VC documents about JSON-LD, 15:20:06 ... but that also applies to the DID WG. 15:20:37 ... The text is to explain (even more) clearly that downloading JSON-LD contexts from the web is not necessary for complying with the standard. 15:20:58 ... And that processing a VC or DID document as JSON is equivalent to processing it as JSON-LD. 15:21:28 ... The proposal was to add some text saying "any difference in the behaviour between JSON and JSON-LD would be a bug of this spec" 15:21:56 ... We have some text to this effect in VC. 15:22:50 ... In the Controller Document spec, we got to a point where there is no difference between JSON and JSON-LD processing. 15:23:00 ... As a side effect, we can have a single media-type. 15:23:28 -> VC's version on the JSON(-LD) that Manu was talking about: https://github.com/w3c/controller-document/pull/106 15:23:46 ... We never picked a media-type because of 5-year long debate at IETF about multiple suffixes in media-types. 15:24:12 ... The proposal to this group is to do the same for did: would people be happy with a media-type like application/did ? 15:24:22 q+ 15:24:26 ... We haven't heard any pushback so far. Should be take a resolution? 15:24:30 ack markus_sabadello 15:24:56 markus_sabadello: A CBOR representation would have a different media type, but there would be no difference between JSON and JSON-LD? 15:25:04 manu: correct 15:25:16 markus_sabadello: I think that would be fine, sounds like a good idea, one thing I'm wondering, separate media type for DID Resolution result. 15:25:16 q+ 15:25:48 markus_sabadello: Separate media type for that, I think that's fine, sounds like a separate question we can discuss separately, but don't think there would be any implications/problems, sounds good. 15:25:49 ack manu 15:26:04 manu: I agree, we should have a separate media-type for DID Resolution results. 15:26:26 ... Another thing we did in VC is tell people "use the most accurate media-type when you serve these documents". 15:26:47 ... Many people get media-types wrong, so often that people are encouraged to not rely on media-types. 15:27:34 ... For a JSON(-LD) prepresentation, this would be application/did ; for a CBOR representation, this would be something like application/did+cbor . 15:27:52 ... Serving a DID document as application/ld+json or application/json is not wrong, but not optimal. 15:28:20 ... A text to this effect has reached consensus in the VC WG, I will do something similar for DID. 15:28:29 q+ 15:28:33 ack Wip 15:28:45 ... Developers should be ready to deal with less-precise media-types. 15:28:54 Wip: Quick comment, this text is in the controller document, will we rely on that? Controller document has its own media type? 15:28:54 q+ 15:28:59 ack manu 15:29:13 manu: good question. I think the Controller Document will have its own media-type. 15:29:35 ... We don't want to duplicate content. I try to get a sense of what the group wants. 15:30:40 ... We fist need a decision on the DID document media-type, then we can discuss the rest. 15:31:27 q+ 15:31:49 smccown has joined #did 15:32:01 s/less-precise/lower fidelity 15:32:18 ack pchampin 15:32:26 Wip: Any comments on the draft proposals? 15:32:56 pchampin: Without being too pedantic, the spec makes a clear disctinction between a DID and a DID Document, application/did might be a bit confusing since a DID is an identifier? 15:33:03 q+ 15:33:06 ack manu 15:33:18 manu: I take your point. I'm wondering if it matters all that much? 15:33:27 +1 manu 15:33:35 ... I don't think we would ever serve a pure DID with a media-type. 15:33:46 ... It feels nicer to have a short compact media-type. 15:33:51 q? 15:34:04 dmitriz has joined #did 15:34:10 PROPOSAL: The media type for the JSON and JSON-LD expression of a DID Document will be application/did. 15:34:18 +1 15:34:18 +1 15:34:19 +1 15:34:19 +1 15:34:19 +1 15:34:23 +1 15:34:24 +0.5 15:34:27 +1 15:34:30 +1 15:34:54 RESOLVED: The media type for the JSON and JSON-LD expression of a DID Document will be application/did. 15:34:59 present+ 15:35:17 q? 15:35:26 PROPOSAL: The specification should warn that it is possible to use lower fidelity media types like application/json or application/ld+json to serve DID Documents and that implementations should be aware of this fact and use the highest precision media type in their applications. 15:35:37 +1 15:35:37 +1 15:35:39 +1 15:35:42 +1 15:35:44 +1 15:35:46 +1 15:36:02 +1 15:36:03 +1 15:36:16 +1 15:36:21 RESOLVED: The specification should warn that it is possible to use lower fidelity media types like application/json or application/ld+json to serve DID Documents and that implementations should be aware of this fact and use the highest precision media type in their applications. 15:36:39 TOPIC: DID Resolution Issue/PR Processing 15:37:46 subtopic: https://github.com/w3c/did-resolution/pull/89 15:38:01 markus_sabadello: This is about primary and secondary resource, come up with better names, we mentioned that Joe and myself would try to propose better terminology, hasn't happened yet. Marked it as "do not merge", we don't want to use "primary/secondary" resource terminology. We will just keep this open. 15:38:01 q+ 15:38:10 ack manu 15:39:15 manu: I thought we discussed this previously? 15:40:01 markus_sabadello: We did discuss it on the last call and you're right, but we need a better term, we need a term for ... what is the term when you dereference a URL... what's that thing, not a primary resource... we could just call it "first part dereferencing" and then "fragment dereferencing"... what is the thing when you dereference a DID URL w/o path and fragment? 15:40:13 markus_sabadello: Just a reminder for people to think more about this. 15:40:25 Wip: Yes, Markus and Joe are going to propose something. 15:40:47 subtopic: https://github.com/w3c/did-resolution/pull/88 15:40:52 markus_sabadello: I can merge this, right? 15:40:55 Wip: Yes. 15:41:23 subtopic: https://github.com/w3c/did-resolution/issues/23 15:41:40 markus_sabadello: I'll close this at end of meeting, marked it pending close last week, no further comment/objection, closing at end of this call. 15:42:05 https://github.com/w3c/did-resolution/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc 15:42:25 markus_sabadello: There are a number of older issues, one with the latest input was 22 15:42:31 subtopic: https://github.com/w3c/did-resolution/issues/22 15:43:03 markus_sabadello: This is about signing a DID Document, feel like it's covered by DID Core... section on signing DID Documents. 15:43:23 q+ 15:43:38 markus_sabadello: I asked them for further input through CCG, don't really know what it's asking from DID Resolution. 15:43:38 ack manu 15:44:13 manu: I don't remember anything about signing. Where is it? 15:44:30 ... Found it. There is a note. 15:44:31 https://www.w3.org/TR/did-core/#proving-control-of-a-did-and-or-did-document 15:44:51 ... I agree with you. I don't know what's expected from Resolution for this. 15:45:15 ... A future DID methods WG would look into that. 15:45:49 ... Some canadian people are working on multi-factor authentication. 15:46:02 q+ 15:46:16 ack Wip 15:46:28 ... We need to put something in DID Resolution, but something generic, as this is very method specific. 15:47:04 Wip: I put myself on the queue to respond to something you said, Manu -- some DID Methods might be signing their DID Documents, but it's only for their DID Method resolution processes which require those signatures. DID Resolution could probably only say "if there are signatures you should verify them". 15:47:30 markus_sabadello: Then add a comment to the issue to what we just discussed and leave it open, at some point DID Resolution could do something w/ signed DID Documents. 15:47:58 subtopic: https://github.com/w3c/did-resolution/issues/35 15:49:32 markus_sabadello: I opened this a five years ago, there was an issue in the DID spec about potential privacy concerns associated with data in the DID Document itself, like service endpoints, idea was that if you include service endpoints, endpoints could be sensitive or correlatable, idea was to introduce a proxy service type where you could look up what is normally in the DID Document but use a remote service for looking up parts of the DID Document to not 15:49:33 include correlatable information in the DID DOcument itself. Wonder what we should do with this? 15:49:34 q+ 15:49:51 markus_sabadello: We can mark this an enhancement for now... in five years, no one has worked on this, or had a real life need for this. 15:49:54 ack manu 15:49:58 s/include correlatable/...include correlatable 15:51:12 manu: Dave Longley wrote something about this, I don't think we have anyone working on that right now. 15:52:03 ... We have a number of DIDs floating on the Web, and people use those DIDs to discover how to interact with the DID controller. 15:52:26 ... But this is not how things operate now; DID controllers identify with their DID, then use some web service to start an interaction. 15:52:46 q+ 15:53:02 markus_sabadello: I agree, if anyone ever specifies/implements this, it's a service type so just like defining a different service type like DIDComm or OpenID, so probably be in a separate spec anyway and registered as an extension. Doesn't feel like something that needs to be in DID Resolution itself. 15:53:02 ack Wip 15:53:42 Wip: How do we process this issue? "lacks interest"? 15:54:02 markus_sabadello: I opened this, could add comment -- this could be useful as an extension, but doesn't need to be in DID Resolution. 15:54:19 RRSAgent, make minutes 15:54:20 I have made the request to generate https://www.w3.org/2024/10/17-did-minutes.html pchampin 15:54:28 Wip: That's all we have time for today, any particular issues that could deal with some attention next week? 15:54:37 markus_sabadello: Not sure right now, I'll look. 15:55:32 rrsagent, make minutes 15:55:34 I have made the request to generate https://www.w3.org/2024/10/17-did-minutes.html Wip