Re: [MINUTES] CCG Weekly 2025-04-15

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.*
>