- From: Harrison <harrison@spokeo.com>
- Date: Tue, 15 Apr 2025 16:43:34 -0700
- To: meetings@w3c-ccg.org, Manu Sporny <msporny@digitalbazaar.com>
- Cc: public-credentials@w3.org
- Message-ID: <CAFYh=43KFDVbmtNcDMgddy55K6HSRB=UjKJ4cbTuJUOj_eK8WA@mail.gmail.com>
This is amazing 😍 Thanks @Manu Sporny <msporny@digitalbazaar.com> for setting this up 👏 And thanks to AI/LLM for a great summary. Sincerely, *Harrison Tang* CEO LinkedIn <https://www.linkedin.com/company/spokeo/> • Instagram <https://www.instagram.com/spokeo/> • Youtube <https://bit.ly/2oh8YPv> On Tue, Apr 15, 2025 at 3:10 PM <meetings@w3c-ccg.org> wrote: > CCG Weekly Meeting Summary - 2025/04/15 > > *Topics Covered:* > > - > > *Google Meet Infrastructure Transition:* The meeting marked the first > use of the new Google Meet infrastructure for CCG meetings, highlighting > improved automation for transcription and recording. Manu Sporny was > thanked for his work in facilitating the transition. > - > > *Verifiable Credential 2025 Vote:* Manu Sporny reminded attendees of > the ongoing verifiable credential 2025 vote, urging participation before > the Thursday deadline. > - > > *IIW 2025 Experiences:* Attendees shared their experiences from the > International Internet Week, noting a sense of urgency around AI > capabilities and authorization, particularly concerning the Model Context > Protocol (MCP). The need for better agent identification and authorization > delegation was emphasized. > - > > *CCG Work Item Updates:* Manu Sporny provided updates on various > specifications nearing completion in the incubation phase, including > verifiable credential barcodes and the VC API. Progress on post-quantum > data integrity crypto suites and pseudonymization was also discussed. > - > > *LWS (Linked Web Storage) and Solid Update:* Aaron Coburn and Hadrian > Zbarcea presented an update on the LWS working group, focusing on: > - *Portable Persistent Identifiers:* Discussion centered on the > challenges and potential solutions for portable identifiers, considering > HTTP URIs alongside other DID methods. > - *Authentication:* The need for secure and efficient > authentication mechanisms beyond browser-based OpenID Connect was > highlighted, mentioning client credentials and DIDComm. > - *Authorization:* The group explored authorization models, > considering the potential of ZCAPs (Zero-Knowledge Capabilities) but noting > the need for careful consideration of maturity and W3C standards. The group > invited input on how LWS could accommodate ZCAPs or similar systems. > - > > *ZCAPs and Authorization:* A significant portion of the discussion > focused on ZCAPs, their maturity, and their suitability for authorization. > The advantages of ZCAPs over verifiable credentials for authorization were > debated extensively, highlighting the built-in delegation capabilities and > differences in revocation mechanisms. GANAP (Grant Negotiation and > Authorization Protocol) was also mentioned as a relevant standard. > - > > *Use Cases:* The importance of realistic and complex use cases was > emphasized to avoid overly simplified scenarios that may not capture > real-world challenges and risks of authorization and delegation, especially > in high-risk or enterprise settings. > > *Key Points:* > > - The transition to the new Google Meet infrastructure significantly > improved meeting automation. > - The verifiable credential 2025 vote is nearing its deadline. > - There's growing interest and urgency around AI capabilities and > authorization. > - Several LWS specifications are approaching completion and transition > to the standards track. > - The LWS working group is actively seeking input on portable > identifiers, authentication beyond OpenID Connect, and authorization > models, particularly considering ZCAPs. > - ZCAPs were presented as a superior alternative to verifiable > credentials for authorization due to built-in delegation and more efficient > revocation mechanisms. > - The importance of using realistic and complex use cases in designing > authorization systems was repeatedly stressed. > > Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-04-15.md > > Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-04-15.mp4 > *CCG Weekly - 2025/04/15 11:51 EDT - Transcript* *Attendees* > > Aaron Coburn, Alan Karp, Alex Higuera, Benjamin Young, Dave Lehn, Dmitri > Zagidulin, Drummond Reed, Erica Connell, Greg Bernstein, Hadrian Zbarcea, > Harrison Tang, Hiroyuki Sano, James Chartrand, Jennie Meier, Jesse Wright, > Joe Andrieu, Kaliya Identity Woman, Kayode Ezike, Mahmoud Alkhraishi, Manu > Sporny, Nate Otto, Phillip Long, Rob Padula, Ted Thibodeau Jr, Vanessa Xu, > Will Abramson > *Transcript* > > Alan Karp: Good morning, Harrison. Nice to meet you at IIW. > > Harrison Tang: Good morning. Sorry, I was trying to run around. > > Alan Karp: I don't know why I'm not here today. I'm going to try rejoining. > > Harrison Tang: Nice to meet you at IW as well. Yeah, great. > > Alan Karp: Can you hear me? > > Harrison Tang: Y nice to meet you as well. > > Alan Karp: Yeah, you're talking. > > Harrison Tang: This is a … > > Alan Karp: I can't hear you. > > Harrison Tang: you cannot hear me. > > Alan Karp: Nothing. I tried rejoining. > > Harrison Tang: Hi,… > > Alan Karp: It didn't help. Let's wait for somebody else to join and we'll > see if they have the problem, too. Yeah,… > > Aaron Coburn: Hey, how are you? > > Harrison Tang: can you hear me? Okay. Yes. > > Aaron Coburn: I do. Can you hear me? > > Harrison Tang: Yes. Great. It's good. > > Alan Karp: I'm not hearing anything. > > Harrison Tang: You're not hearing anything? > > Aaron Coburn: Harrison, do you usually IRC chat going Okay,… > > Harrison Tang: No, that's actually a legacy. > > Aaron Coburn: I wasn't sure from the invite whether that was legacy or if > that was actually a thing. Okay. > > Harrison Tang: So yeah, I actually forgot to remove it. So, this is our > first time using the new Google Meet infrastructure. > > Harrison Tang: Yeah. great. > > Aaron Coburn: We'll see how it goes. > > Alan Karp: And my audio is fixed. > > Alan Karp: I switched speakers and came back and everything's working. It > was > > Harrison Tang: Yeah, it's our first time. So, hopefully this works. > > Aaron Coburn: I've been using Google Meet for a while. I'm generally > pretty happy with it. > > Harrison Tang: Yeah. Yeah. I like Google Meet. > > Harrison Tang: just because Manu helped us build the new infrastructure, > The recordings and all that stuff. So, this is the first time I've been > kind of using Jity to host these meetings for a long time. So, this is my > first time. > > Aaron Coburn: In the past, isn't it the case that Jity had there was some > sort of a bot that would join and do all of the transcription? Okay. > > Harrison Tang: Yes. Yes. Correct. And I have to press the recording and > things like that. and then I had to send out a lot of things like run the > script manually and all that stuff. So it's quite a bit of manual process. > > Harrison Tang: Supposedly this is going to be all automated. So we'll see. > > Aaron Coburn: Great. … > > Aaron Coburn: we can be the guinea pig. > > Harrison Tang: Yes unfortunately you guys are this is literally the first > time we run the meeting at Google meet. > > Harrison Tang: Yeah. Yeah. > > Alan Karp: We have a regular Friday meeting. It's been going on over 25 > years. And we've been using Google Meet for the last four years or so. It > works I wish the chat would survive disconnect and reconnecting, but that's > the only complaint I have. > > Aaron Coburn: There is a feature in the chat that allows at least some > people to pin messages and… > > Harrison Tang: Yes. Yeah,… > > Aaron Coburn: those messages do in fact persist across reconnections. > > Alan Karp: Okay, I'll look into that. Thanks. > > Harrison Tang: my understanding is that the chat might not make into the > transcriptions. So, we'll see. > > Harrison Tang: But so far based on our other ECDU we're all switching from > GT to Google Meet. So far the transcription looks perfect. So it looks > amazing. Let me start the recording. I think we can start. > 00:05:00 > > Manu Sporny: You don't have to start anything, Harrison. It auto starts. > So, you just get to sit back and enjoy sharing. > > Harrison Tang: So it's already recording right now. > > Manu Sporny: Yeah. Yep. > > Aaron Coburn: This is the beauty of automation. > > Harrison Tang: Okay. > > Manu Sporny: Yep. That's right. > > Manu Sporny: Fully automated. The bots are in charge. > > Harrison Tang: All right. > > Harrison Tang: And I don't need to send out I don't need to run the script… > > Manu Sporny: You don't need to do anything. > > Harrison Tang: because over Okay. > > Manu Sporny: No, you just get to be a chair. Isn't that great? > > Hadrian Zbarcea: We don't even have to be here. > > Harrison Tang: First time for me. > > Hadrian Zbarcea: Actually, it's that automated. > > Manu Sporny: That's right. > > Harrison Tang: Even better. All right. So, we'll welcome everybody to this > week's CCG meeting. so this is the first time we're using the Google meet. > I just want to give a quick shout out to Mi again for actually setting up > all these things. Of course just want to thank him for all his work in the > past in regards to maintaining actually also paying for the GT > infrastructure and I want to thank him for helping us migrate to the Google > Meet infrastructure and actually supporting us as well. > > Harrison Tang: So big thanks to mommy. yeah, so today we're very excited > to actually have Erin and Hrien back again to talk about LWS link web > storage and solid and more specifically I think Erin will touch upon > self-certifying identifiers and portability authentication mechanisms and > off the authorization delegations. but before we get to that just want to > quickly go over some administrative stuff. first of all just a quick > reminder on the code of ethics and professional conduct. Just want to make > sure we have respectful and constructive conversations that we always have. > quick note about the intellectual property. anyone can participate in these > calls. > > Harrison Tang: However, all subsessive contributions to any CCG guidance > must be member of the CCG with full IPR agreement signed. So, if you have > any questions about those agreements or if you have troubles, signing up > for the W3C account, please feel free to reach out to me or any of the > co-s. All right. So I don't think we need to go through the code notes > because first of all these meetings and audio recordings are automatically > transcribed and we will send out the recordings in the next probably > immediately we'll see this is our first time using the Google Meet > infrastructure so if you have any questions feel free to just raise your > hand and I will moderate > > Harrison Tang: the queue next. Just want to take a moment for the > introductions and introductions. So, you're new to the community or you > haven't been active and want to engage, feel free to just unmute. All > right. let's get to the announcements and reminders. any announcements > reminders? > > Harrison Tang: Mario, please > > Manu Sporny: Yep. Just a quick one. > > Manu Sporny: The verifiable credential 20 vote is currently going on. it > ends this Thursday. So if you know of a company that's a W3C member that > has not voted yet, I will put the link into the chat channel. please be > sure to copy that and we unfortunately will lose anything in the chat > channel that does not end up in the transcription. but if you go there > you'll see you have to be a W3C member to vote. but if you haven't voted > yet please do. the voting will close in 3 days. things are going no formal > objections or anything yet, so that's good. and that's it. > > Harrison Tang: Thank Any other announcements or reminders? anyone want to > share their IW experience the presentations that they saw that they want to > share with the community or everyone just can't wait to talk about solid > 00:10:00 > > Drummond Reed: Harrison, it's a little hard to summarize three days of > craziness at IW and a few, but it was, as amazing as always and some I > thought felt there were some of the best presentations and sessions in 20 > years. So, that's how I'll sum it up. > > Harrison Tang: Thank you. Thanks, Ron. Anyone else? over you want to share > something? Now the world is > > Dmitri Zagidulin: I can jump in. so you could definitely feel a sense of > urgency in this particular Lots of sessions on the ones that really caught > my eye is of course proof of human conversations which sort of involves all > the credential infrastructure that we care about here. And then on the > other side, specifically MCP, the model context protocol. And the shot, the > overwhelming take away that I took from it is identical AI really needs > capability authorizations. That was the upshot. > > Dmitri Zagidulin: we're quote unquote delegating more and more > capabilities and power to AI agents, but the tech that we're doing it with > is still extremely primitive. So, we need better affordances for > identifying agents and we need better affordances for delegating > authorization to them. and this group's work item authorization > capabilities for links to data is the perfect candidate for it if we seize > the moment that's my takeaway. > > Harrison Tang: Thank And I definitely agree with everyone here. I was not > expecting so many sessions on the MCT auto context protocol. So yeah, > anyone else wants to share before we get to the main agenda? All right. any > updates on the work items on please > > Manu Sporny: Yeah, we're continuing to really finish off the incubation > for a couple of specifications before we hand it off to the verifiable > credential working group. once these seven specifications are published as > global standards hopefully in the next month the VCWG will be able to move > on to kind of the next set of items. we have been sending updates to the > mailing list like the summaries on Wednesday are pretty good kind of > measure of where we are. we think that verifiable credential barcodes is > pretty much ready to go to the verifiable credential working group. we > think VC API still needs quite a number of PRs before it's ready but most > of the technical work is figured out. We just need to update the specs. > > Manu Sporny: So, we're going to keep doing that. This Wednesday, we're > going to be talking about render method in trying to unify a number of > approaches that have been used over the past two years. before we're > handing it over to the verifiable credential working group. there's also > some postquantum data integrity crypto suites that we're working on in the > data integrity calls on Friday along with the pseudonym stuff. The good > news is that if for those of you following along we found a problem with S > pseudonyms a couple of weeks ago. > > Manu Sporny: what we believe is a workable fix for that. very related to > AIS and rate limiting and pseudonyms and things like that. so that's good > news. we're going to keep pushing forward on that and get that u into kind > of a track that can go to BCWG. So there are a lot of specs. I didn't > mention all of them but there are another I think six specifications plus > that we're hoping to move to standards track that have been incubating here > for a while. so lots of movement even if you can't join the calls we are > now using this new call infrastructure to auto send out summaries and the > summaries are pretty good. I've been kind of impressed by them. I'm not > usually impressed by the AI hype, but they do a pretty good job. I think > that's it. Harrison > 00:15:00 > > Harrison Tang: Thank you, And I also pasted the meeting link for the CCG > promotions for equation meeting. It happens on Wednesdays, which is > tomorrow at 8:00 a.m. Pacific time, 11:00 a.m. Eastern time. All right. any > last calls for work items,… > > Harrison Tang: announcements, reminders? Yes, please. > > Will Abramson: Yeah, I have something,… > > Will Abramson: Harrison. this is really to build on what Dimmitri said > about the Zcap LD spec or authorization capabilities, which I'll drop in, > kind of been languishing in the CCG for a while. I think there are a few of > us in the community who would like to I don't know energize it,… > > Harrison Tang: money. > > Will Abramson: pick it up and move it across the line to a published final > working group report. So it be really interesting to know if there are any > others who want to do that. > > Manu Sporny: Yeah, a plus one to that. I'll note that the spec text has > definitely been languishing. implementations have not necessarily there. we > have, the Zcap stuff in production in a variety of places. Huge plus one > for anyone that wants to pick that work up and kind of move it forward. > there's some fairly bigish changes that I think we can make to one of them, > which I don't think will be controversial is removing the link data > component of it. I think over time we've found that we don't necessarily > need it. but the data integrity signature portion of it, fairly useful. So, > yeah, huge plus one if others want to pick that work up and move it > forward. super supportive of that. That's it. > > Alan Karp: Yeah. UKAN is another certificate-based capability system that > introduced some ideas that are not in ZCAP that I think are worth > considering for anybody who picks it up. the work on UKAN is sort of stuck > because the company pushing it went out of business, but Fision went out of > business, but there are some good ideas in there that I think anybody > picking up Zcap should look at. > > Harrison Tang: Thanks. Any link? So, Alan, do you mind sharing a link to > that? > > Alan Karp: Yeah, I'll find a link to put it in > > Harrison Tang: Okay, Thanks. All right, let's get to the main agenda. So, > I think couple months ago, we have Erin and Tri here, to talk about solid > and link web storage. > > Harrison Tang: and they work at L LWS working group and it was a great > conversation there was so many questions and discussions that we weren't > able to get to so we've scheduled this follow-up discussion and I'll just > let Erin and Adrian take it over I think they have prepared a quick > presentation and we'll need a very good discussion that I think a lot of > things that this communities really care about. So, please the floor is > yours. > > Aaron Coburn: Harrison. And really, thank you to all of you for inviting > us back. we were here in January and now it's three months later, we're > back to give a little bit of an update on where things stand with the > linked web storage working group. sort of where we're heading, and also a > bit of an invitation, which I'll get to go back a stage. so I'm Aaron > Coburn. I'm one of the chairs of the working group. and I'm an engineer at > Inrupt. Hrien is also here. he's a co-chair of the comm the solid community > group and a member of the link web storage working group and also also at > Inro. > 00:20:00 > > Aaron Coburn: So just to recap, this is the same slide that I showed three > months ago. I think there might be a slightly different group of people > here, but most of you would have seen this already. But at a high level, > what we're trying to do is we're trying to build a spec set of > specifications that define a web-based permissioned data storage. with the > idea that this can help drive application interoperability across this kind > of shared storage system. a lot of the key parts of that and I'm just going > to go really quickly through this to really get to a part where I'm hoping > we can have actually more conversation and a little bit more engagement. > and I'm really thrilled to tell you the truth that you've been talking > about ZCAPS because I want to talk about delegation. > > Aaron Coburn: but some of the things that we need at a really core level > here are global identifiers for entities. Now in the past in the history of > solid at least we've always used HTTP URIs. So everything is this HTTP > which is useful in the sense that it's very simple. Everyone knows how to > work with HTTP URIs. > > Aaron Coburn: portability ends up becoming a bit of a question mark and a > lot harder to achieve. So that's one of the things we're trying to grapple > with at the moment in the context of the working group. secondly, there's > this notion of how do we make sure that we achieve application > interoperability using some kind of global semantics. so again, a lot of > questions there still to be solved and still to be sorted out. and then the > third thing I want to mention just in this context is in order to do > permission storage you need mechanisms for authentication and > authorization. so where are we now? we are about six months since the > chartering of the working group. > > Aaron Coburn: So, we're moving a little bit slower maybe than we were > hoping, but a lot of this initial work is really important because it will > help us make sure that when we do come up with a specific set of > recommendations that those recommendations have been fleshed out, that > they've been reviewed by as many people as possible and that there's a lot > of thought that's gone into it. right now, we're still refining use cases. > We're expecting to wrap that up by the end of the current month. At that > point, we'll be moving into the phase of writing from the requirements and > the use cases that we've defined and vetted that we'll then be able to > derive text specific recommendations for protocols and so on and so forth. > > Aaron Coburn: three things I want to bring up here and this is where I > want, I'm inviting questions, I'm inviting comments. but we're looking at, > how to have portable persistent identifiers. Obviously, one option is and > this will always be an option is to use HTTP URIs. they're easy, people > know how to use them, they've been around forever, relatively speaking, but > the portability is questionable. It relies on ownership or control of that > DNS. there are other kinds of identifier schemes that might make more sense > in this context, at least as a compliment. > > Aaron Coburn: So it's doubtful that we would say everything must use this > particular did method as an example. What I think is more likely is that we > would say here are the characteristics of an identifier scheme and HTTP may > fit into that those characteristics as might some specific dead methods. I > think that would be a success because it would allow for things that > currently work to continue to work but things that are up and coming things > that maybe don't exist right now but will exist in the future certain did > methods that are still being refined as an example those are things that we > want to make sure that this working group has considered. > > Aaron Coburn: the second thing to bring up is authentication. And again, > like I said before, we're still refining use cases. We don't have specific > solutions. We hope to get to the point where we have at least the outline > of specific solutions here. historically, Solid has been really focused on > browserbased authentication. This is why open ID connect has come in so > significantly in most applications that you see that use solid in reality > or certainly in the enterprise world the world where I've been interacting > with customers browserbased interaction is great but it's only one part of > the story and being able to authenticate securely and efficiently in a > non-browser context whether > 00:25:00 > > Aaron Coburn: this is client credentials or didcom or whatever it happens > to be a non open id connectbased authentication mechanism is really really > important so again I would love to get some advice some feedback from you > folks around that and then finally authorization there are a couple of you > high level models for doing authorization. In the past, solid has relied on > an RDF model that is tied to specific resources that typically are managed > by the storage system itself. That's useful in some contexts. > > Aaron Coburn: In other contexts, especially with delegation or time > boundaries or other structures like that, it tends to fall apart or at > least it has limitations. ZCAPS in particular are interesting here. think > as a working at the working group layer, we have to be a little bit careful > about bringing in items that either take us outside of the scope that's > defined for the working group or to refer to things that are still not > quite that level of maturity that is required by the W3C. > > Aaron Coburn: So, I would love to hear more about where ZCAPS are and > where they're going and even if they're not ready to be specifically > brought in as a normative reference in the working group, I would be very > interested in knowing how we could define at the LWS layer a set of > structures or a set of expectations that make it possible for someone to > use Zcaps or a L system. so I have one more slide here which is just about > u getting involved and I can go back over this in a minute but one thing > related to getting involved specifically around these items. > > Aaron Coburn: as a working group as all of one needs to be a W3C member in > order to be part of the group unless of course you're an invited expert. > There's another way of being involved which is especially if you have > expertise in an area and want to perhaps go in a meeting and give a brief > seminar give us some information about talk about a particular area that > you may be an expert on and bringing in outside people to do this. it's > what I'm doing right now. > > Aaron Coburn: but I really heartily want to invite folks from this group > who have so much expertise in these areas to come and help advise us on > especially these issues. so I want to pause there a little bit. Adrien, I > don't know if you have anything that you want to add at this point or maybe > if we should kind of open the floor up. I have not been following the chat. > > Hadrian Zbarcea: Hi all. I don't think there's anything relative in the > chat. I would open the floor. > > Harrison Tang: Morning please. > > Manu Sporny: Yeah. hey wonderful to, have you back here, you and Hrien as > certainly have some thoughts on kind of the persistent identifiers, > authentication and authorization, things as well as kind of like maturity > level. So, I think I mean, it'll probably come as no surprise to you. > they're decentralized identifiers. There are controlled identifiers which > is a new TR track spec that we are expecting to hit wreck soon that look a > lot closer to things like web ID and kind of controlled identifiers like > cryptographic where you can prove cryptographic control over then > decentralized identifiers so that's kind of a thing that you could normally > 00:30:00 > > Manu Sporny: normatively reference. it's food for thought. I don't know > how useful it would be like I don't think it's a big shift away from what > you already have in solid, right? So, it's not going to give you any > advantages. whereas maybe decentralized identifiers with did web might give > you some advantages. meaning break away from that could you start out in a > way that is kind of domain bound but move away from that in time. > > Manu Sporny: the folks from blue sky were here a couple of weeks ago > talking about they started out with a fairly centralized did method which > they are now looking at making more and more decentralized so that has to > do with the portable persistent identifiers there's new work that we're > going to try to bring to W3C to define a number of normative DID methods > right things that you could cite from the solid specs probably on a > timeline that would work for the working group. but at the very least you > could potentially did web as kind of a standin because it has some fairly > straightforward similarities I think with where solid is today. > > Manu Sporny: for authentication. as you know, exists. it is Probably not > something that you can specify and use just yet, but does the same kind of > cryptographic authentication kind of back and forth. that's defined in the > verifiable presentation request spec. and then finally for authorization as > you heard at the beginning of this call some people mentioned Zcaps the > spec again thanks to Dmitri hopefully we're going to see some good forward > momentum in that but I think we stepped back from the spec for a while just > because it felt like it was too early for the world meaning people this is > a solution in > > Manu Sporny: search of a problem. We don't, see why it's useful, yada. So > rather than try and push the spec forward, we kind of took a step back. we > dig bizarre implemented it in a number of production systems and have > learned a lot about, delegated capability systems where they're full-blown, > implementations. It's out in production, all that kind of stuff. so one you > had asked is there something that we can put in in place of it. > > Manu Sporny: we are running systems with dual authorization stacks where > one set is OOTH 2 and have been able to swap that out with ZCAPS not > without some effort but if you build your system so OOTH 2 works it's a > fairly straightforward replacement to use Zcaps including with delegation. > so just some thoughts on, specs that might be useful to you and the > timelines that they might be useful to you > > Aaron Coburn: Thanks, yeah, we're definitely very very aware of the > controlled identifier. I mean, it's proposed, but again, looking at the > voting, it looks like things are moving quite positively for that > specification to become a recommendation. I think that would likely fill > the gap that we currently have with use agent identity as an example or > different kinds of identity structures that we've previously been using in > web ID being a draft document from a community group that no longer really > exists. > > Aaron Coburn: So we need some way to fill that gap. controlled identifiers > look like something that very much will fill that gap. And likewise with > DIDs, I think that layer of indirection that s can provide. They don't > necessarily have to, but they can provide that layer that can really help > out, I found, with things like portability. > 00:35:00 > > Aaron Coburn: So I know Alan, you've got your hand up. go for it. > > Alan Karp: Yeah so two comments. > > Alan Karp: Do you know about GANAP grant negotiation and authorization > protocol? it's more than it's an accepted IETF standard. and it covers more > than just what ZCAP does, but buried in it is something like Zcap. I > believe the difference is the tokens are opaque, but I think something you > should consider, especially if you're looking for accepted standards and it > was done largely by Justin Richard who really understands this stuff. > > Aaron Coburn: I do. Yes. > > Alan Karp: and the other thing is you may not want to rule out opaque > tokens Olaf bearer tokens. they're very good if you have a high performance > need if you're getting gazillion tokens per second. the crypto in > certificate-based is too slow. So if you have that as a requirement. The > other comment I wanted to make was on use cases. I've been lurking on a lot > of these projects and in general my conclusion is they're designing for use > cases that are too simple. I believe > > Aaron Coburn: Interesting. > > Harrison Tang: Alan, I think we lost you a little bit. > > Aaron Coburn: The last I heard was the use cases are written in a too > simple fashion. I agree. I think there's one of the challenges you want is > you want to have the use case simple enough to define a problem and make it > understandable. but I think you're making a really important point about if > it's not actually capturing a real world situation then what value is that > overly simplified use case? > > Harrison Tang: Ellen, I think we lost you in the last three minutes. All > right, Dimmitri, let's get to you and then we can go back to Alan. > > Dmitri Zagidulin: So I want to comment on GANAP and give some advice about > the three bullet points on the slide. so the thing about ZCAPS is that as > always it divides into data model and Data model being what is it's all > going to be fancy signed tokens, so part we talk about the three part data > model protocols and the crypto. > > Dmitri Zagidulin: So with Zcaps, it defines a simple data model. it > defines a way to chain signatures together to show the delegation chain, > but the spec doesn't say anything about the protocols. Meaning it's just a > data model spec. It doesn't have anything to say about how do you get the > Zcaps? How do you request them in the first place? And then how do you > invoke them in the moment in an HTTP call? Those are slightly separate > specs. as is correct we should always layer well whenever possible anyways > data model and protocol But for protocol specs for how do you request the > Zcaps in the first place there you have a bunch of options. You can ask > using a VP request for example Chappie via credential handler API. > > Dmitri Zagidulin: You could ask for a ZCAP using the new digital > credential API that's being built into the browser. You can ask for a ZCAP > using NAP. the interesting thing about GNAP is that it's largely a protocol > spec. It has very little to say about the data model. So, I've done an > extensive study on GNAP and pretty much all of the existing u data model > protocols with regards to token structure. And GNAP and ZCAP are > compatible. you can use NAP to ask for a Zcap and so they don't really > overlap. they're not an alternative and then for protocol specs on how to > invoke a credential that's when you would look to something like HTTP > signatures which is an ITF RSC. So it is a standard. > 00:40:00 > > Dmitri Zagidulin: so yeah in fact with regards to earlier question of is > Zcap mature enough so the spec itself no it's just the work item of the CCG > but the loadbearing parts meaning how you ask for the Zp how you sign the > Zcap and how do you invoke it all those are specs right so we've got data > integrity which is in the process of becoming a W3C standard in the working > group we have HP signatures which is already a standard and we have Zcap > which is already a standard. and Aaron mentions in chat that he implemented > HP signatures the other month. > > Dmitri Zagidulin: Okay, but back to the issues for discussion for portable > persistent identifiers and I have a handy write up for what a possible > roadmap for portable persistent identifiers as applied to decentralized > social media. I'll drop that in the chat. but for porting persistent > identifiers I would generally look to did relative URLs either using the > query parameter that's in the core did data model right now or the work > item that is called one second I just had it on a tab this is a diff work > item > > Dmitri Zagidulin: And it's not did relative links. it's okay. Yeah, I'll > send it in chat too. But it's basically takes the whole structure of doing > did relative URLs and query parameters and makes slightly more elegant puts > it in the path component of the URL as opposed to the query component. But > the idea is the same that as long as it did stays the same, you can change > out the storage and the links don't break because there's a layer of > indirection involved. And with other techniques such as also known as links > and verifiable credentials, you can even migrate themselves and still have > the links not break. > > Dmitri Zagidulin: For authentication, I think both verifiable presentation > requests were mentioned by Manu as well as HTTP signatures, an limited > component of authentication. And for authorization delegation, like I said, > I would highly recommend using something like Zcaps. That's it for me. > > Manu Sporny: Yeah, plus one to everything Dimmitri agree with all of that. > the other thing that I think is interesting to look into Aaron is there's > kind of a language. So this is building off of what Allan Allen said where > it really does matter that your use cases are broad enough. and I think a > lot of the authorization failures that we've seen in the past is because > folks didn't think about fairly complex use cases and how the system would > work in those instances. So things like as most people know in the > community like a capability allows you to talk directly about the resource > that you're giving the capability to modify change. > > Manu Sporny: but there's kind of a little domain specific language there > is it read and write is it execute is it any kind of action how do you > specify the resource as Demetri was saying did you use a path what does the > path mean all of those things kind of need to go into any capability > specification and what you put in > > Manu Sporny: there what the domain specific language needs to support is > directly driven by the use cases and so you just need to make sure that you > have some important complex use cases and some fairly high-risk use cases > as well such as a journalist providing delegation to a drop point that they > only know about on the web things where if something goes wrong really bad > things happen. as well as examples where you have massive delegation going > on meaning a delegation chain that's maybe five or six people deep. > 00:45:00 > > Manu Sporny: those types of delegation chains happen in large corporations > or governments where're just potentially for example in a government use > case you're trying to give a citizen access to a sensitive government area > but one that they have the right to access. so something like an evidence > locker specifically that citizen should have access to that nobody else > should have access so the use cases matter a lot there. the depth of the > delegation matters a lot. the language that you use to express all the > things and the capability matter a lot as well. > > Manu Sporny: one thing that we have found over time that didn't matter as > much as we thought it would, is the link data portion of the ZCAP spec. So, > ZCAP has, authorization capabilities for link data and there's a really > nice language and everything that we, defined for it. but one thing that > we've learned over the past couple of years is that unlike verifiable > credentials where you really do need a global way of talking about things, > Zcaps are often consumed by the entity that issued them. And so you don't > really need, and this is debatable. > > Manu Sporny: I don't want to say it's, completely cut and dried, but you > don't really need a super expansive, way of describing the language and the > items and things like that. You might need links and URLs to point to > things, but you don't need the same kind of semantic flexibility that you > do with a verifiable credentials. the other thing that we've learned also > is that you should probably not use verifiable credentials for > authorization use cases. you should use a verifiable credential to get the > Zcap and then from then on out you should use the ZCAP and delegate the > ZCAP. so again some lessons learned in this area when it comes to > authorization and the depth of the delegation use cases that you have. > That's it. > > Harrison Tang: Thanks, Eris. > > Harrison Tang: Do you have any comments? > > Aaron Coburn: Thank you. > > Aaron Coburn: I really appreciate the advice. This is really, really > helpful. > > Harrison Tang: I think we lost you earlier. Do you > > Alan Karp: Yeah. Yeah. > > Alan Karp: My internet dropped out of all things. yeah. So Ammano said the > good bit of what I wanted to say about the use cases. as I said before, I > don't know if it got cut off. I think I've identified the simplest use case > that exposes all the hazards of delegation. a couple comments. Nanu, we in > our examples, HP had a product around 2000 based on capability > certificates. These were spooky certificates, simple public key > infrastructure. We saw delegation chains longer than five, 10, 15 sometimes > when we went cross enterprise. So that's one issue. let's see here. and I > forgot what I was going to say now. So I got the use case. > > Alan Karp: I don't know if you heard that sometimes if it's a high > performance requirement where you get a gazillion of these things, you > should consider using simple bearer ooth tokens. and you can build high > performance systems that way. I have one more thing on my notes and I can't > find it. So I'll let somebody else go and I'll raise my hand again when I > find it. > > Harrison Tang: Go. > > Jesse Wright: And I'll quickly introduce myself because I don't think I've > met a lot of people here and I didn't have working audio at the start. I'm > Jesse. I work on solid as well. I lead the open-source work around at the > open data institute. I also work in my PhD on ethical web and data > architectures at Oxford and I'm also doing zero knowledge proof and sparkle > work that I'll talk about later in a different context. I had a question > for Manu which is you said verifiable credentials are not good for > authorization on what experience and basis was that statement made. > 00:50:00 > > Manu Sporny: Yeah So when we were building verifiable credentials there > was a natural tendency for people to say what this would really work well > as an authorization framework and it is not that it's impossible to create > an authorization framework on top of verifiable credentials. It is possible > to do that. but typically when you have an authorization capability, you > don't want all of the baggage that comes along with verifiable credentials > to come along with the authorization capability. It should be a very > tightly controlled thing that doesn't provide the means to misinterpret > what's said. > > Manu Sporny: So that capability should have a very small security attack > surface. It really shouldn't have the ability to express anything about any > entity on the face of the planet because what we were finding is that > people were taking the verifiable credential. they were putting an > authorization system around it and then they were going wouldn't it be nice > if it also expressed these other things that could be interpreted in > different ways by the system that is granting or granting the ability to > change the resource. > > Manu Sporny: So people started putting things into the verifiable > credential that ended up creating confused deputy situations like they > started stuffing in arbback stuff in there. there were all these things > these kind of anti-atterns authorization that capabilities are meant to get > rid of and they were getting reinjected in because of the flexibility that > verifiable credentials has. > > Manu Sporny: And so the general advice was like nope that's a different > tool for a different use case capabilities need to be they are security > things they're security tokens and you should have a different language a > different way of specifying those things and the attack surface should be > much smaller on that at a high level that's it Jesse I know that Dave > Longley has a lot more thoughts on that. I'm sure Dimmitri also has some > thoughts on that as well. > > Jesse Wright: It does and I'll add a tiny bit more context as to why I > asked. Firstly, there's a discussion around in the solid and LWS specs > whether VCs should be used for delegated authorization. Secondly, I'm also > involved in a nonW3C working group on agents that has lang chain and a few > academic institutions in it and they are talking about using verifiable > credentials for de delegated authorization as well. I've been feeling > nervous about that discussion. So if anyone wants to come and give an > invited talk to the agents group as well that would be amazing. > > Harrison Tang: Val, do you have any comment? > > Alan Karp: Yeah, I found what I was forgetting to what I was going to say > before. so there's an opportunity to reduce how much needs to be > standardized in terms of designating the resource and the permissions and > that's to consider that to be part of the application API and that means > that one application can have one way of defining the resource and the > permissions and another one can have a completely different one because the > only one who's verifying > > Alan Karp: the capability is the resource or an agent working on its > behalf. So if you think of those two aspects as part of the API then you > don't have to standardize it and the less you have to standardize the > better. And I can give a talk on capability systems if somebody is > interested. I've given several > > Harrison Tang: Thank All I don't think anyone in the queue. > > Harrison Tang: Sorry. > > Dmitri Zagidulin: Wait. > > Dmitri Zagidulin: I pressed the wrong button. I wanted to give an > additional answer to Jesse's question about why you shouldn't use > verifiable credentials for authorization. and basically it has to do with > the data model of the payload. When you look at them sufficiently far away, > Zcaps and VCs are the same thing. They're an object with some fields that > has a digital signature, So in that case, yes, they are the same thing and > you can use them, but we do like to give more fine grain, more specific > terminology to tell one use case from another. And aside from the fact that > both are assigned object, the difference lies in the payload fields. > 00:55:00 > > Dmitri Zagidulin: A verifiable credential identifies this object and makes > claims about it and has some infrastructure about the credential itself. A > Zcap only basically it's a triple of fields identifying the key invoker, > what actions they're allowed to take and on what resource. Those fields > aren't found in the verifiable credential data model and vice versa. Right? > So basically when you do an authorization, choose the fitforpurpose data > model even though they're both signed objects. says it. > > Aaron Coburn: The other thing to add is that there's no concept of > delegation inside of VCs at least to start whereas in ZCAP has that built > in from the beginning. > > Dmitri Zagidulin: Exactly. > > Alan Karp: Yeah. Also the revocation mechanisms are completely different. > > Aaron Coburn: So what? Yes. And the moment you get beyond the simplest > kinds of authorization scenarios, you're going to have to deal with > delegation. And rather than having to build delegation from scratch in on > top of the VC specification, you might as well use something where that's > already been thought through and you're not going to make the kinds of > mistakes that others have. > > Harrison Tang: Money. > > Manu Sporny: Yes, that's exactly right what Aaron said. the other big > challenge that we have there is it doesn't really like what does it mean to > delegate your employee ID credential to someone else right now there are > people that talk about that I'm going to give my tap ID to somebody else so > they can get into that door that I'm allowed to get into but that is a > complete abuse of your employee > > Manu Sporny: ID card, right? I mean, that is the root of confused deputy > things. You literally gave your entirety of your authority to this other > individual. They have no limits on what they can do with the credential > other than you're watching them, When they go second they go out of your > eyes eyeshot, then they can do whatever they want. they can masquerade as > you to electronic systems that don't know the difference. So the whole > concept of delegation and a verifiable credential is not thought through > and on purpose right it was something that we knew you needed another > technology to do. meaning if what you're doing is authorization you > shouldn't be using a verifiable credential to do it. You should be using > another technology to do it. > > Manu Sporny: You can use a verifiable credential to kind of get that > initial capability, get that authorization. From then on out though, you > should be using that authorization, So a verifiable credential is your > capability is a car key. The car doesn't care who's holding the key. They > just care that you have the capability to use so anyway it's a very > important distinction and it is something that the community has spent a > lot of time thinking about for the past eight plus years. so yeah be beware > those that want to use verifiable credentials for authorization. the > general thinking right now is don't do it. It's a bad idea. > > Jesse Wright: That makes sense. I wanted to ask Allan, you mentioned that > there's a very different replication model for Zcaps. I haven't read > thoroughly up on ZCAPS, so could you briefly explain the difference? > > Alan Karp: Yeah, because the ZCAP specifies the resource. When you want to > revoke, you just tell that resource, don't honor this capability anymore. > With a mobile driver's license,… > > Jesse Wright: That makes sense. > > Alan Karp: you don't know who the verifier is going to be. So, you need > something like a revocation list somewhere, and then you run into all these > problems of phone home and all kinds of crazy stuff. So that's what I mean > by the mechanisms are completely different. > 01:00:00 > > Jesse Wright: Gotcha. Thank you. > > Harrison Tang: Great discussions. any last questions or comments? By the > way, Ellen, Do you mind explaining your last point? What's the difference > between the ZCAP revocation and then the VC revocation? Can you explain > that and clarify a little bit? > > Alan Karp: Yeah. Yeah. in a ZCAP, who the verifier is, right? That's > basically the resource provider and agent working on behalf of it. So, who > to tell to revoke in a general verifiable credential. > > Alan Karp: My diploma, Who's going to verify it? You don't know who to > tell to not honor it. Right? So,… > > Harrison Tang: Got it. > > Alan Karp: completely different mechanism for revocation. > > Harrison Tang: Yeah, makes Great discussion. any last comments or > questions? Aaron, do you have any last comments? > > Aaron Coburn: So yeah, my last comment is just really to thank all of you. > this has been a really fabulous conversation and I really appreciate the > comments and advice and thanks for inviting us back. > > Harrison Tang: No, thank you. wise. I found this discussion and > conversation very very educational. Love it. All right. this concludes this > week's W3C CCG meeting. Thanks for attending. Bye. Yes. > > Hadrian Zbarcea: Thanks all. > > Manu Sporny: Hey Harrison, real quick,… > > Manu Sporny: I lied at the beginning of the call. You do have to stop the > trans transcription and you have to stop the recording and then it'll ask > you if you want to throw everyone out of the meeting and you say yes. I > don't think you have to. > > Harrison Tang: Got it. > > Harrison Tang: We'll do. > > Manu Sporny: I just haven't tested what happens if you don't. > > Harrison Tang: I will do that right now. > > Ted Thibodeau Jr: Transdimensional vortex. > > Harrison Tang: Thank you. > > Manu Sporny: > > Manu Sporny: All right. > > Harrison Tang: Thanks, Mommy. > > Manu Sporny: Thanks. That's right. > > Harrison Tang: Thanks, Mommy. > Meeting ended after 01:02:36 👋 > > *This editable transcript was computer generated and might contain errors. > People can also change the text after it was created.* >
Received on Tuesday, 15 April 2025 23:43:59 UTC