14:48:27 <RRSAgent> RRSAgent has joined #did
14:48:31 <RRSAgent> logging to https://www.w3.org/2025/03/13-did-irc
14:48:33 <Wip> rrsagent, draft minutes
14:48:35 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/13-did-minutes.html Wip
14:48:43 <Wip> rrsagent, make logs public
14:48:55 <Wip> Meeting: Decentralized Identifier Working Group
14:49:00 <Wip> Chair: Will Abramson
14:49:04 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Mar/0004.html
14:58:34 <Wip> present+
15:00:31 <pchampin> present+
15:00:49 <ivan> present+
15:01:12 <markus_sabadello> markus_sabadello has joined #did
15:03:23 <ChristopherA> ChristopherA has joined #did
15:03:29 <ChristopherA> present+
15:03:43 <manu> manu has joined #did
15:03:55 <manu> present+
15:04:05 <JoeAndrieu> JoeAndrieu has joined #did
15:04:12 <JoeAndrieu> scribe+
15:04:15 <JoeAndrieu> present+
15:04:27 <JoeAndrieu> Wip: welcome
15:04:46 <JoeAndrieu> ... DID Resolution architecture is our topic today
15:05:05 <Wip> Topic: DIDWG Chair Update
15:05:28 <JoeAndrieu> pchampin: Gabe has had to step down.
15:05:50 <JoeAndrieu> ... Dan Burnett has been helping, but also needs to step down. We are looking for another chair. Otto has agreed to help.
15:05:57 <JoeAndrieu> ... This should be official in a couple days
15:06:14 <JoeAndrieu> ottomorac: Thank you. I'm here to help out.
15:06:19 <manu> \o/ Woo! Welcome Otto, great to have you here -- wonderful to have you as the new Co-Chair of the DID WG!
15:06:29 <markus_sabadello> Thanks Otto!!
15:06:45 <JoeAndrieu> Wip: Thanks, Otto.
15:06:45 <Wip> q?
15:07:01 <Wip> Topic: Global Digital Collaboration around Wallets
15:07:14 <JoeAndrieu> ... brief announcement: the OWF is in touch with W3C to host conference around wallets
15:07:39 <JoeAndrieu> ... Nothing formally announced, but perhaps the first or second of July in Geneva.
15:07:45 <JoeAndrieu> ... Currently in planning.
15:08:05 <ChristopherA> link to that event? I'm a L0
15:08:06 <JoeAndrieu> ... I think we should be in that conversation. I was surprised that wallets was more about credentials than keys.
15:08:11 <manu> q+
15:08:14 <Wip> ack manu
15:08:27 <JoeAndrieu> manu: I'm interested in what the event is going to be about.
15:08:46 <JoeAndrieu> ... There's been a push in the EU against DIDs by some of the folks in the EUDI initiatives.
15:08:59 <ivan> q+
15:09:10 <JoeAndrieu> ... It would be good for some of us to show up, but at the same time, It's not clear how closely the OWF is associated with EUDI or not.
15:09:18 <ChristopherA> q+
15:09:33 <smccown> smccown has joined #did
15:09:33 <Wip> ack ivan
15:09:46 <JoeAndrieu> ivan: I was part of some of the discussion with EU folks. More on VCs than DID.
15:10:00 <JoeAndrieu> ... the discussions were very useful. We could give them good arguments for why VCs should be used.
15:10:17 <JoeAndrieu> ... They seem to be much more positive with VCs now
15:10:49 <JoeAndrieu> ... The event in Geneva grew out of a panel that was held in Davos where director of W3C was present and talked about W3C technologies VCs and DIDs, etc.
15:10:51 <bigbluehat> bigbluehat has joined #did
15:11:09 <pchampin> s/director of W3C/Seth Dobbs, CEO of W3C/
15:11:14 <JoeAndrieu> ... The goals appear to be a bit vague, but its more like bringing together all possible partners together to see where the work should go
15:11:34 <JoeAndrieu> ... It's more a general architecture than about DIDs or VCs.
15:11:54 <JoeAndrieu> ... This is not a W3C event. We were invited.
15:11:57 <JoeAndrieu> ... Seems that W3C is the main promoter in terms of privacy.
15:12:14 <JoeAndrieu> ... At least in Davos, privacy was discussed
15:12:38 <JoeAndrieu> ... For the time being its worth being present
15:12:38 <JennieM> JennieM has joined #did
15:12:38 <Wip> ack ChristopherA
15:12:49 <JoeAndrieu> ChristopherA: I have the same reservations that Manu has.
15:13:02 <JoeAndrieu> ... Plus there is an entire class of participants, e.g., in the hardware level
15:13:13 <JoeAndrieu> ... who are totally not represented. I have some concerns there.
15:13:19 <JoeAndrieu> ... Joe, maybe you can find the document
15:13:48 <JoeAndrieu> ... A RWOT SICPA paper comparing wallet flows for blockchains with financial, compared to similar flows for identity wallets.
15:14:00 <JoeAndrieu> ... I don't know that I can go.
15:14:13 <Wip> Topic: Overview of the DID Resolution Architecture Section
15:14:19 <bigbluehat> present+
15:14:28 <JennieM> present+
15:14:31 <JoeAndrieu> wip: What changes should we consider?
15:15:14 <JoeAndrieu> markus_sabadello: we are defining resolution function in Section 4
15:15:27 <JoeAndrieu> ... we are about to remove the resolveRepresentation function
15:15:37 <JoeAndrieu> ... We've already talked quite a bit about options and metadata and algorithm
15:15:55 <JoeAndrieu> ... This is described as an abstract function. No particular protocol
15:16:19 <JoeAndrieu> ... We define inputs and outputs, but how it is implemented and deployed
15:16:46 <JoeAndrieu> ... DID resolvers could come in different forms. Remotely overy HTTP, or just a local library that doesn't communicate with any external systems.
15:17:08 <JoeAndrieu> ... Section 7 is about DID Resolution Architecture to discuss this
15:17:37 <JoeAndrieu> ... The way the section is now, it's divided into two sections, method architectures and resolver architectures.
15:17:53 <JoeAndrieu> ... The section on method architectures tries to cover how a resolver reads information from the VDR
15:18:13 <JoeAndrieu> ... When you invoke a resolver, it reads data according to the DID method spec. This section covers how that is done.
15:18:38 <JoeAndrieu> ...For example, no assumption should be made that a blockchain is being used or that interaction with remote networks are required.
15:19:16 <JoeAndrieu> ... We discuss verifiable read and unverifiable read. Depending on the DID method, this could be done in a way that has some sort of cryptographic verifiability or not.
15:19:53 <JoeAndrieu> ... For example, a resolver resolving a bitcoin method might do that by using an explorer api (and not really know if the answer is correct)
15:20:02 <ChristopherA> (I found the link to the RWOT paper on wallet architectures "What’s in Your Wallet?" https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/whats-wallet.md
15:20:06 <JoeAndrieu> ... Or it could run its own bitcoin node with full cryptographic verifiability
15:20:32 <JoeAndrieu> ... What is verifiable and what are the trust characteristics.
15:20:47 <JoeAndrieu> ... Then the Resolver Architecture section talks about the other side of the resolver.
15:20:58 <JoeAndrieu> ... How a client using a resolver interacts with the resolver.
15:21:12 <JoeAndrieu> ... Similar considerations about local and remote bindiing.
15:21:27 <JoeAndrieu> ... Not about how the resolver gets the DID document, but about how the client invokes the resolver.
15:21:40 <JoeAndrieu> ... This binding could just be a local library that's a resolver.
15:21:58 <JoeAndrieu> ... Or you could use a remote service.
15:22:16 <JoeAndrieu> ... We discuss a bunch of considerations when using those architecutres
15:22:46 <JoeAndrieu> ... Then additional considerations about proxies, with resolvers calling other resolvers.
15:23:07 <JoeAndrieu> ... And  subsection about different parts of the process handled by different resolvers
15:23:40 <ChristopherA> q+
15:24:13 <JoeAndrieu> ... There are several issues addressing different topics for this area
15:24:32 <JoeAndrieu> ... What kinds of things do we want in the spec?
15:24:39 <ottomorac> Thanks Markus great overview!
15:24:52 <JoeAndrieu> wip: This section already exists. Has a bunch of issue tags that need help.
15:25:08 <JoeAndrieu> ... ChristopherA can you share your ideas in these issues?
15:25:09 <Wip> ack ChristopherA
15:25:35 <JoeAndrieu> ChristopherA: There is a lot more richness going on than what is even in this simplified proxy model
15:25:43 <JoeAndrieu> ... You have some complicated relationships.
15:26:20 <JoeAndrieu> ... You might trust code in the browser. Or there might be a "trust zone" or SSH-capable FIDO keys, an airgapped connection to a hardware device where they don't trust the bluetooth chip.
15:26:51 <JoeAndrieu> ... There's also richness at the other end: the resolver that you speak to may be able to do a measure of trust, not just in that particular resolver, but also what that resolver can do.
15:27:12 <JoeAndrieu> ... like with BTCR where there are multiple phases ... you might have initial resolver that does initial work
15:27:32 <JoeAndrieu> ... but then when you want the other parts, you might need to talk to another resolver with more capability
15:27:58 <JoeAndrieu> ... For example, most bitocin nodes are pruned, but you can run a full now (and need to for full history)
15:28:19 <JoeAndrieu> ... Also you might want to check via multiple explorers, even randomized to make sure you aren't relying on any particular one.
15:28:40 <JoeAndrieu> ... This allows "broad internet consensus" to help
15:28:55 <JoeAndrieu> wip: Thanks, Christopher
15:28:56 <markus_sabadello> q+
15:28:57 <TallTed> TallTed has joined #did
15:29:06 <Wip> ack markus_sabadello
15:29:08 <JoeAndrieu> ... What actual things should we add to the diagram?
15:29:25 <ottomorac> Or should we jump into issue 79?
15:29:52 <JoeAndrieu> ... I read this section before the call. It's definitely a work in progress, but those flags... some are really good
15:30:25 <JoeAndrieu> ... Some things that came out: the best case is a local resolver running verifiable reads on specific methods, clear that each method's "reads" are going to have different levels of confidence.
15:30:54 <JoeAndrieu> ... Markus?
15:31:02 <manu> q+
15:31:13 <JoeAndrieu> markus_sabadello: Thanks, Christopher. A lot of what you said is possible on a high level with the language we have already.
15:31:41 <ChristopherA> Here is 6-year old diagram: https://github.com/WebOfTrustInfo/rwot9-prague/raw/master/topics-and-advance-readings/media/ExpandedDecentralizedIdentityNetworkComponents.png
15:31:44 <JoeAndrieu> ... For example, "browsers have certain trusted ways of executing code", I think that is what these subsections are trying to explain.
15:31:54 <JoeAndrieu> ... Local/remote binding, verified/unverified read
15:32:07 <TallTed> present+
15:32:11 <JoeAndrieu> ... Points about multiple resolvers are all ways of making the read operation more verifiable
15:32:19 <ottomorac> present+
15:32:22 <ChristopherA> q?
15:32:25 <JoeAndrieu> ... We could add these as examples. They'd fit right in.
15:32:27 <Wip> ack manu
15:33:01 <ChristopherA> q+
15:33:05 <JoeAndrieu> manu: Looking at #79. There are valid concerns. And noting Markus's concerns. But I don't know if the current text doesn't strike the right balance.
15:33:20 <JoeAndrieu> ... the sections Markus put in are good, because they establish what people should be thinking about
15:33:44 <JoeAndrieu> ... Also +1 to Christopher's point, we don't want to lock down too far in version 1.0
15:34:02 <JoeAndrieu> ... Maybe there are statements in there locking things down prematurely. I'd support fixing that.
15:34:19 <JoeAndrieu> ... Also, this might be something more for security considerations rather than where it is now.
15:34:30 <Wip> q+
15:34:38 <JoeAndrieu> ... but sometimes it's better to have something in the considerations that you don't want to get lost
15:34:58 <JoeAndrieu> ... I'd rather us write more than less as long as it doesn't lock anything in normatively
15:35:17 <markus_sabadello> q+
15:35:19 <Wip> ack ChristopherA
15:35:19 <JoeAndrieu> ... Some people complain about verbose specifications, but this is a core part of the ecosystem and we should give it the amount of text that explains it clearly
15:35:29 <ChristopherA> https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/media/ExpandedDecentralizedIdentityNetworkComponents.png
15:35:36 <JoeAndrieu> ChristopherA; I don't think we want to have something as complex as this image (in chat)
15:36:01 <JoeAndrieu> ... My point is that "it's a lot richer" and we need to convey that to people A variety of things going on here that they may not be aware of.
15:36:08 <TallTed> s/ChristopherA; I don't/ChristopherA: I don't/
15:36:08 <JoeAndrieu> q+ to mention threat modeling
15:36:35 <JoeAndrieu> ... A lot of newer homomorphic and zk proofs are partially done in hardware.
15:37:02 <JoeAndrieu> ... In the diagram, there's a big dotted line that isn't actually a network connection, it's a secure multi-party computation going on, not a web connection in the classic sense.
15:37:20 <JoeAndrieu> ... What's the right minimal amount explain this complexity and richness.
15:37:23 <ottomorac> this diagram --> https://raw.githubusercontent.com/WebOfTrustInfo/rwot9-prague/refs/heads/master/topics-and-advance-readings/media/ExpandedDecentralizedIdentityNetworkComponents.png
15:37:33 <JoeAndrieu> ... This is all applicable to revocation, which could happen because of a quorum
15:37:34 <Wip> ack Wip
15:37:49 <manu> scribe+
15:38:22 <JoeAndrieu> wip: we should try not to put things in boxes
15:38:41 <JoeAndrieu> ... I agree with Manu, some of this does go in Security considerations, or at least in there as well.
15:38:57 <Wip> ack markus_sabadello
15:38:57 <JoeAndrieu> ... maybe even if those sections just flag ot read the other section
15:39:16 <JoeAndrieu> markus_sabadello: regarding the richness, the current diagrams are completely generic
15:39:19 <ottomorac> q+
15:39:28 <JoeAndrieu> ... I tried to make them so they apply theoretically to all did methods
15:39:51 <JoeAndrieu> ... Should work for did:key where everything is local, as well as did:btcr or did:btc1 where there is more complexity.
15:40:02 <JoeAndrieu> ... I like the idea of some examples
15:40:15 <JoeAndrieu> ... We could do some more specific versions of the different architectures
15:40:43 <Wip> ack JoeAndrieu
15:40:43 <Zakim> JoeAndrieu, you wanted to mention threat modeling
15:40:45 <JoeAndrieu> ... We can illustrate these differences a bit more as they apply to certain DID methods
15:41:00 <manu> JoeAndrieu: What we're nuzzling towards is doing some threat modelling.
15:41:37 <manu> JoeAndrieu: If we do those architecture diagrams with some of the sensibilities in the security group, which are still sort of nascent, Adam Shostack starts with data flow diagrams, analyze threats for that architecture, show difference in the threats that emerge because of different architectures.
15:41:43 <markus_sabadello> q+
15:41:46 <Wip> ack ottomorac
15:41:50 <manu> JoeAndrieu: Not quite ready to kick that off right now, but that might be where we should be going.
15:42:08 <JoeAndrieu> ottomorac: I was wondering: we have this diagram with Chris that shows some architectures.
15:42:23 <Wip> ack markus_sabadello
15:42:23 <JoeAndrieu> ... do we have some examples of different architectures that we could study or describe in the spec?
15:43:01 <JoeAndrieu> markus_sabadello: I wanted to ask some of the open issues we have about authentication, ... , selective disclosure.
15:43:11 <ChristopherA> (related to this specific issue is also https://github.com/w3c/did-resolution/issues/28)
15:43:23 <JoeAndrieu> ... so far we've been talking about trust, but there are also additional features under consideration
15:43:33 <JoeAndrieu> ... should we specify that resolvers can have authentications?
15:43:48 <JoeAndrieu> ... Or there should be ways to selectively disclose parts of a DID document
15:43:57 <ChristopherA> q+
15:44:01 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/79
15:44:20 <JoeAndrieu> wip: I agree with Markus, which of these features do we want to add to the resolution spec
15:44:21 <Wip> ack ChristopherA
15:44:51 <JoeAndrieu> ChristopherA: To add a little richness. There was a mention of how a client trusts a resolver, but there are also situations where a resolver must be able to trust the client.
15:45:17 <JoeAndrieu> ... For example, a resolver might be able to do basic resolution, but elide specific data about specific keys
15:45:30 <JoeAndrieu> ... In a public API you just get the key you need, just what you need
15:45:46 <Wip> q+
15:45:57 <JoeAndrieu> ... but then you might need to authenticate to resolver service or some kind of OCAP authorization from issuer or holder to reveal the elided information
15:46:03 <Wip> ack Wip
15:46:04 <JoeAndrieu> ... The trust CAN go both ways
15:46:29 <JoeAndrieu> wip: I think all of these topics are important, but as I read it, I agree some of these are too big
15:46:46 <JoeAndrieu> ... e.g., DID Resolution enables extensions, so are these really not possible or just not yet extended?
15:46:53 <Wip> https://github.com/w3c/did-resolution/issues/38
15:46:56 <ChristopherA> Maybe a "future work" session?
15:47:05 <JoeAndrieu> ... One thing we might want to add to the spec would be #38 about authorization and authentication
15:47:19 <Wip> q?
15:47:24 <ottomorac> trust in the resolver is interesting for sure
15:47:32 <ottomorac> its almost the same as trusting the issuer
15:47:39 <ottomorac> a fuzzy question to tackle
15:47:50 <markus_sabadello> q+
15:48:00 <JoeAndrieu> wip: this has been an interesting discussion. Are there issues we should be creating? Like adding examples of different architectures.
15:48:06 <JoeAndrieu> ... Maybe one for threat modeling.
15:48:11 <Wip> ack markus_sabadello
15:48:49 <JoeAndrieu> markus_sabadello: I think what Christopher said, I think we should mention/explain is what a client is and how to deal with elided v public components of a DID document.
15:49:07 <ChristopherA> q+
15:49:12 <JoeAndrieu> ... we should talk about it as a possibility, but are we ready to build it into the algorithm.
15:49:31 <JoeAndrieu> ... That feels like a lot of work, so maybe we start in Security considerations that these are possibilities
15:50:03 <JoeAndrieu> ... But it is a pretty fundamental question, saying effectively that the result of the resolution process depends on who the client is and what the client is providing.
15:50:22 <JoeAndrieu> ... We had always been saying we have the DID you get the DID document, no variations.
15:50:22 <Wip> ack ChristopherA
15:50:47 <JoeAndrieu> ChristopherA: I wanted to pop up a level. Tactically, we have a limited scope to do a 1.0 spec. We're focused on the resolver.
15:51:19 <JoeAndrieu> ... We could just do the minimal viable thing. But part of why I'm motivated to talk about these broader issues is a response to what is going on with EUDI wallet and mDL and things of that nature.
15:51:37 <JoeAndrieu> ... we have offered to the world a technology that has superior capabilities to centralized solutions
15:52:04 <JoeAndrieu> ... Somehow conveying that we should use elision with committed, but unrevealed endpoints, and the ability to work with different kinds of hardware, etc.
15:52:29 <JoeAndrieu> ... When someone says DIDs doesn't offer anything to overcome XYZ, we can say, yeah, but you don't do ABC
15:52:30 <ottomorac> Should the did resolution categories maybe follow the did methods beings standardized?
15:52:31 <Wip> q+
15:52:42 <Wip> ack Wip
15:52:47 <ottomorac> after all those would be gaining notoriety in the community...
15:53:02 <JoeAndrieu> q+ to speak against variations on DID document
15:53:12 <manu> q+
15:53:12 <ottomorac> scribe+
15:53:20 <JoeAndrieu> wip: Maybe there's a type that can still resolve to a DID document compatible to the API
15:53:22 <Wip> ack JoeAndrieu
15:53:22 <Zakim> JoeAndrieu, you wanted to speak against variations on DID document
15:53:44 <manu> JoeAndrieu: Standardizing that you might get back different DID Docs on who you are opens the door to widespread late publishing problems.
15:54:18 <ChristopherA> q+
15:54:19 <manu> JoeAndrieu: They might not be able to verify that they're working w/ a particular DID... we've seen use cases where results of the entire DID Document withheld, but to have variations on it introduces a challenging security context.
15:54:20 <Wip> ack manu
15:54:33 <ottomorac> Manu: yes a light +1 to what Joe said...
15:54:38 <JoeAndrieu> manu: Yeah, a light +1 to what Joe said. I think we should explore the space. I have the same concerns.
15:54:45 <ottomorac> scribe-
15:55:09 <ottomorac> q+
15:55:16 <JoeAndrieu> manu: As editor, reminding folks, we can't add new features.
15:55:23 <JoeAndrieu> q+ to challenge the features comment
15:55:24 <Wip> ack ChristopherA
15:55:31 <Wip> zakim, close the queue
15:55:31 <Zakim> ok, Wip, the speaker queue is closed
15:55:47 <JoeAndrieu> ChristopherA: I agree with the concerns if it's just the elided document.
15:55:56 <JoeAndrieu> ... but there is a way to demonstrate they are "the same"
15:56:20 <Wip> +1 I also think it might be possible. Needs experimentation though
15:56:20 <JoeAndrieu> ... It's just the commitments are made, but when you get the more detailed document, you see all the commitments revealed
15:56:31 <JoeAndrieu> ... So they are one document and they can have one trust point.
15:56:35 <Wip> ack ottomorac
15:56:38 <manu> +1 to finding a middle ground
15:57:01 <JoeAndrieu> otto: the other thing I'm wondering. Given we are standarding DID methods, that is itself an endorsement
15:57:19 <JoeAndrieu> q+ to say we are not supposed to be endorsing particular methods
15:57:31 <Wip> ack JoeAndrieu
15:57:31 <Zakim> JoeAndrieu, you wanted to challenge the features comment
15:58:44 <Wip> https://github.com/w3c/did/issues/337
15:59:11 <pchampin> RRSAgent, make minutes
15:59:13 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/13-did-minutes.html pchampin
16:00:02 <pchampin> m2gbot, link issues with transcript
16:00:03 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/79#issuecomment-2721775537
17:31:11 <ottomorac> ottomorac has joined #did
18:02:39 <Zakim> Zakim has left #did
18:04:35 <bkardell_> bkardell_ has joined #did
19:49:19 <jyasskin> jyasskin has joined #did
22:43:48 <dlehn1> dlehn1 has joined #did