[MINUTES] CCG Weekly 2025-04-15

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