[MINUTES] CCG Capability-based Storage 2026-08-06

This meeting of the CCG Capability-based Storage Task Force focused on
progress and discussions around the Zcap, EDV, and Wallet Attached Storage
specifications. Key discussions included the organization of the Zcap
specification into a single document or separate specs, with a consensus to
keep it unified for now. The meeting also explored use cases for capability
suspension and delegation to unknown delegates, highlighting potential
complexities and the need for careful design. Progress on the EDV
conformance suite adoption and the announcement of the Vouched/DIFF chaos
protocol were also covered.

Here's a breakdown of the topics covered:

   -

   *Zcap Specification Organization:* The group discussed whether to
   maintain the Zcap specification as a single document or break it into
   separate specs for data model, protocols, and verification.
   - The consensus was to keep it as a single spec for implementation
      clarity and to avoid potential mix-and-match problems.
      - Future expansion and more complex sections may be moved to
      appendices or separate documents later.
   -

   *Zcap Milestone 0.4 Progress:* Benjamin Goering provided an update on
   the progress towards milestone 0.4 of the Zcap specification, focusing on
   improving readability and removing inline to-dos.
   - Several pull requests have been merged to clean up the document, with
      an emphasis on editorial changes rather than normative ones.
      - A significant pull request (PR 65) aims to remove most inline
      comments, and further review of open pull requests was encouraged.
   -

   *Authorization Delegation and Vouched/DIFF Chaos Protocol:* The group
   was informed about a paper from the DIFF Trusted AI Agents working group on
   authorization delegation, where Zcaps are a featured chapter, and the
   announcement of the Vouched/DIFF chaos protocol.
   - This highlighted the growing interest in delegation technologies and
      the potential for engagement with these groups.
      - The chaos protocol uses DIDs and VCs, and also includes a Zcap
      component, prompting a discussion about comparing delegation mechanisms.
   -

   *Capability Suspension Use Case:* Moises Jaramillo introduced a use case
   for suspending agentic capabilities, similar to pausing an agent's
   authorization, until further investigation.
   - This sparked a discussion on whether suspension should be a state
      within the capability itself or managed externally, with
suggestions for a
      "caretaker" pattern for flexibility.
      - The complexity of managing such states and the potential for
      denial-of-service vectors were noted, along with the idea of documenting
      use cases separately.
   -

   *Delegation to Unknown Delegates:* Alan Karp raised a use case for
   delegating to unknown delegates, such as subscribers to a Kafka topic or
   recipients of an email.
   - This use case could potentially impact the Zcap data model and was
      suggested to be tracked via a GitHub issue.
      - The discussion touched upon how existing mechanisms like
      interaction URLs from the VCOM spec might address this, and the need to
      consider data model changes if necessary.
   -

   *EDV Specification Status and Conformance Suite:* Dmitri Zagidulin
   provided an update on the EDV specification, hosted by DIFF, and called for
   new editors.
   - The task force is working on EDV alongside Zcap and WAS, and
      participation from DIFF members is covered by their agreements.
      - The adoption of a developed EDV conformance suite into CCG was
      proposed and met with enthusiasm, with discussions on how to integrate it.
   -

   *Call for Editors:* A call was made for editors for both the EDV and
   Wallet Attached Storage specifications, as current editor bandwidth is
   limited.
   - Volunteers are needed to help move these specifications forward.

*Action Items:*

   - Review open pull requests for the Zcap specification.
   - Open a GitHub issue to track the "unknown delegate" use case raised by
   Alan Karp.
   - Dmitri Zagidulin will transfer the EDV conformance suite to CCG,
   pending chair approval and opening a GitHub issue.
   - Manu Sporny will attempt to track down Derek to inquire about his
   continued involvement as an EDV spec editor.
   - Dmitri Zagidulin will initiate a call for editors for both the EDV and
   Wallet Attached Storage specifications.
   - Dmitri Zagidulin will follow up with the chairs regarding the EDV
   conformance suite adoption and explore reversing the liaison agreement if
   necessary.
   - Bumblefudge von CASA will provide a link to the existing EDV test
   suite in the DIFF repo.
   - Add items for the next call's agenda to the designated location.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-capability-based-storage-2026-08-06.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-capability-based-storage-2026-08-06.mp4
*CCG Capability-based Storage - 2026/08/06 12:56 EDT - Transcript*
*Attendees*

Alan Karp, Benjamin Goering, Bumblefudge von CASA, Dave Longley, Dmitri
Zagidulin, Furkan's Notetaker, Kayode Ezike, Kerri Lemoie, Lancine Toure,
Makki Elfatih, Manu Sporny, Moises Jaramillo, Patrick St-Louis, Phillip
Long, Ted Thibodeau Jr, Tom Jones
*Transcript*

Dmitri Zagidulin: Hello.

Phillip Long: Hey, how you doing?

Dmitri Zagidulin: Hey everyone. As always, going to give it a few minutes
for folks to join. That's right.

Alan Karp: Demetri is really eager. He's showing up twice.

Dmitri Zagidulin: That's right.
00:05:00

Lancine Toure: Hello everyone.

Dmitri Zagidulin: Hello.

Dmitri Zagidulin: Hello, Lancine. Welcome. We're going to give it another
few minutes for folks to connect. In fact, one more minute and we'll get
started. meanwhile, here is a link to the rough agenda for folks. I see the
problem here in the system.

Dmitri Zagidulin: Here's the ref agenda in meet All close enough after the
hour. Let's get started. folks will catch so welcome everyone to the twice
a month capability based storage task force this call is under W3C code of
conduct and IP release agreement. Anybody can participate in the calls.

Dmitri Zagidulin: However, all contributions to the work items to the specs
themselves, you do need to be a member of the CCG with full IPR agreement
signed. Let us know if you want us to walk you through that offline. Let's
do brief introductions and reintroductions. does anybody want to introduce
themselves? You can just raise your hand. if not we will move on. Yeah,
please. Fancy or how do you pronounce

Lancine Toure: Hello everyone, my name is to I'm criminologist opensource
intelligence analyst. I'm from Kivoir and I'm a new member of this group.
So I'm very glad to be here because it's a unique opportunity to learn from
my piece and I'm very glad to be here.

Lancine Toure: I'm native French, so sorry for my mistakes in English.
Thank you.

Dmitri Zagidulin: We're very happy to have you.

Dmitri Zagidulin: Please at any point ask questions in chat or just raise
your hand and we'll so feel free to interrupt people is my point. All
right. Anybody else? introd introductions? I suppose we haven't since this
is the second call of the task force, we haven't gone on long enough to do
reintroductions, but just in case somebody wants to.

Dmitri Zagidulin: We've got Juan in introducing also a valid introduction
venue. Juan, welcome.

Kerri Lemoie: I'll say hello…

Kerri Lemoie: if that's okay to meet.

Dmitri Zagidulin: Yeah, please Carrie, go ahead.

Kerri Lemoie: Hi everybody. my name is Carrie Lamoy. I was the consortium.
U the director of the digital princess comments. We just moved from MIT
Destrada. Part of the work we did at TCC with Demetri was on this wallet
attached storage specification and we're very interested in these specs and
this work group or this task force I guess as part of the work we're
thinking about going forward and how learners can store their digital
credentials and other assets anywhere they need them in a safe and
protected and…

Kerri Lemoie: privacy preserved So I'm here really to learn and listen and
help however I can. Thank

Dmitri Zagidulin: Thank you so much,…

Dmitri Zagidulin: Glad to have for those just joining us, this task force
is deals with the overall subject of capability based storage, but
specifically convened to work on at least three pecs. the first one which
is the Zcap specification which can be found here at this address. I'm
going to post it in chat. the second one this is kind of in layer order.
00:10:00

Dmitri Zagidulin: The second one is the EDV stack which stands for
encrypted data vaults which is currently hosted at decentralized identity
foundation but we'll talk more a bit about that and thirdly we have the
wallet attached storage spec here link in chat.

Dmitri Zagidulin: All So, let's move on to our main agenda. yes, please.
Manu.

Manu Sporny: Just a real quick maybe agenda plus to talk about the vouched
diff announcement which has to do with delegated credentials. maybe if we
could add three minutes to the agenda to just briefly mention that.

Dmitri Zagidulin: That sounds great. Let's do just that. man, do you have
time constraint on this call or…

Dmitri Zagidulin: do we have you for the full hour?

Manu Sporny: No.

Manu Sporny: I'm here for the full hour.

Dmitri Zagidulin: Excellent. All let's talk about ZCAPS.

Dmitri Zagidulin: Before I hand over to our main Zcap editor, Bango, I just
wanted to remind people that there is a set of poll requests ready for your
review where we're trying to wrap up milestone 0.4, which is just remove
the glaring to-dos and formatting and some other items. So, if you haven't
had a chance to look at those, please do. in addition, I want to talk about
issue 72 about whether we want to have one combined spec or three

Dmitri Zagidulin: separate ones. I want to mention the diff gentic
authorization paper and give the mic over to Moyesus to mention the pausing
use case. But before we do any of that I want to hand the mic over to Bango
if you have any comments or questions for the group about the stack.

Benjamin Goering: Sure. Can I present?

Dmitri Zagidulin: Yes, yes, please.

Benjamin Goering: Okay. You all see the zc? You should, right? Great.

Dmitri Zagidulin: We do.

Moises Jaramillo: It's a little burn blurry, but

Dmitri Zagidulin: We do. Go ahead.

Benjamin Goering: So, we have merged a couple pull requests. based on this
milestone that we kind of talked about in the first meeting around a 0.4
whose main goal is to make no normative changes and just try to improve the
readability of what's there. And one big part of that is there's a lot of
inline to-do text in the pros that we can move into HTML comments or the
issue tracker or a section I'll show you. But basically now if anyone goes
to the link that's been live for a long time, you'll see that in the title
here it doesn't say v 0.3 anymore. It says 0.4. And with this pre-release
tag that indicates that it's not final. So we're basically working on what
will become 0.4.0. And if you look in the issue tracker, basically one of
the things I've done since the last meeting is go through all the issues in
the issue tracker. I've commented on A lot of them are seven or eight years
old, which is kind of fun.

Benjamin Goering: Some of them may not be timely anymore, but I bumped a
lot of them just to see if the people who filed them are still interested.
If you look in the poll requests of things that are updated since the
beginning of July, kind of when we started, you'll see a lot of little
things that got merged here with at least one co-editor approving it,
usually Dimmitri. But yeah, a lot of these are super small. You can go and
browse them if you want and file an issue or try to re comment on them if
you have any issues. But a lot of them are things like renaming versions
and fixing little examples and removing small pieces of text. There are
these two pull requests that are open. There's a third one this morning
that I merged emerging these editorial only ones as long as someone else
approves. I think the big one I wanted to highlight is this PR number 65
where Monte suggested we get more like other people reviewing it.

Benjamin Goering: This is like I got sick of making small pull requests and
so this one gets a rid of a lot of those inline comments basically. And if
we merge this PR it should clean it up quite a bit. This is what Once we
merge that, you'll see that in the real spec there's a lot of these to-dos
everywhere and things like link and stuff, but in the version we're looking
at there is to-dos except for in clearly marked issues which will be really
nice. So if anyone can help review that that would be great and that's kind
of all I wanted to show. I hear someone has a question but I'll pop
presenters to
00:15:00

Dmitri Zagidulin: Brilliant. Thank you so much,…

Dmitri Zagidulin: Over to you.

Manu Sporny: Yeah, plus one.

Manu Sporny: Thank you for all that work. Bango, that's awesome. and I
think, if I remember correctly, when I looked at the PR,…

Manu Sporny: you've moved some of the to-dos and links to the bottom of the
spec, so we didn't necessarily lose them. I don't think the only concern,
but I can't remember. Perfect.

Benjamin Goering: You're right.

Benjamin Goering: You're right. In the big PR, I mentioned that I would
like to get in. I meant to show this, but I've added a backlog section like
appendix and any issue that was at risk of being controversial to move,
I've moved on there.

Manu Sporny: Okay, That's great. I think the reason some of those to-dos
were in there were as we were working on the spec, we do have thoughts and
feelings and implementations on this, but we just didn't have the time to
add it to the spec. And so, I want to make sure we don't lose any of that
stuff.

Manu Sporny: I don't think your edits lost it,…

Manu Sporny: but I just want to note that why those to-dos and links were
there. that's it.

Manu Sporny: And if they're down there, that's perfectly fine.

Benjamin Goering: Yeah. And…

Benjamin Goering: if they're not point it out because my intention on this
these set of PRs is to not lose anything, but u and I'm pretty sure I
didn't. And we'll add it if I do lose anything, we'll add it back in if it
was in 0.3 and it was just an oversight of where I moved it. I think
someone else was on the queue.

Dmitri Zagidulin: Let's See,…

Dmitri Zagidulin: I think that might be it. Thank you so much, Pango, for
doing that. and folk folks, please go review the open poll requests. All
right, let's talk about issue 72, which is going to be this one here.

Dmitri Zagidulin: Ben or Juan points out to there's merge complex in 65,
but that's fine. I'm sure they're easily resolvable. Let me present again.
All right. So, this is likely going to be part of the larger discussion,
but I figure we would start NAC we have Dave and Manu weighing in which we
always appreciate. the overall topic is this. So at the moment we have at
least three major aspects that the spec combines data model protocols and
cryptographic proof chain verification. And so the issue is tracking the
discussion of hey do we want to keep them as sections

Dmitri Zagidulin: in the big spec or do we want to break them out as
separate standalone specs? so let's see what David man is saying. yes,
please.

Manu Sporny: I can just vocalize since instead of reading so what we've
seen happen in the past is for verifiable credentials we started a working
group and we were data model only and the reason that was the case was we
were forced to do that. We wanted to do data model and protocol and all
those things, but there were a number of very big companies at W3C that did
not want us to do that, And so we did data model first. and it worked out
just fine. the layering there is right data model, algorithms, protocols,
that's good layering.

Manu Sporny: But with this work I think we have enough momentum and I think
large companies don't care as much to try and block us and so I think we
can put them all in the same spec. It's really nice to have them all in the
same spec because you have a section about data model and then you talk
about the algorithms that process the data model and then you can talk
about protocols. and when the editors are working on it, if you need to
update one part of it, the likelihood that it's going to impact some other
aspect of it, for example, you change the data model, it almost certainly
changes the algorithms. and sometimes when you change data model and
algorithm, sometimes it messes with the protocol. So my suggestion is let's
keep it all together until it becomes very clear that we need to split them
apart. One example of that is also the verifiable credential data model.

Manu Sporny: we have a verifiable credential data model and we have a
verifiable credential API and are those are different specs because they're
two fairly significant sized specifications right so just some thoughts
from a W3C process perspective it's also much easier to have one spec that
you're moving through the process instead of three different ones it's for
those reasons I suggest We keep it one spec.
00:20:00

Dmitri Zagidulin: Thank you so much. Manu Alan, go ahead. You're next.

Alan Karp: I think it's better to keep them together. If you have three
separate specs it's possibility of a mix and match problem and that could
lead to holes. and so I think that it's safer to have a single spec.

Dmitri Zagidulin: Copy that, Patrick.

Patrick St-Louis: Yeah, argument for one spec u implementation clarity for
someone who wants to implement this thing to have one place that all the
information they need is really good. an argument maybe to play devil's
advocate for separating spec as one of these separated spec is meant to be
used on its own without the rest and there's significant use case for that.

Patrick St-Louis: But if they are all meant to be used together I mean I
would leave them together.

Dmitri Zagidulin: Yeah.

Dmitri Zagidulin: Good points. Bango

Benjamin Goering: just having been spending time in this document recently.
It's what I've been planning on doing is anything that expand enacts some
of these to-dos that we've been coming across and kind of expands the scope
of the document, we can always start drafting that in this document just
for the sake of benefiting from all of the tools and stuff we have. But in
an appendix that's just clearly marked as an informative. And if that grows
into something that is something we're ready to recommend or require and
then someone raises a concern that that should be not in scope of this
document, we can always move it out then. But for a lot of reasons, it
seems useful to just collaborate in one document within this repo. And
anything that has long-term concerns, just do it in an appendix.

Benjamin Goering: And we can decide where it slots in later.

Dmitri Zagidulin: Excellent. …

Dmitri Zagidulin: I'm hearing a lot of agreement on this topic and no
objections yet. Manu, go ahead.

Manu Sporny: Yeah, plus one to that. I did want to point out one thing
that's happening that it's just data everyone should have in their head.
there are some things I think that we're doing in the VCOM spec in the
workflows and exchanges that try to use Zcaps and that's a protocol spec
and that's an example of we're writing about Zcaps elsewhere. and that
doesn't mean that it overrides, what protocol stuff we might do in the Zcap
spec, but it's just kind of like a heads up in some way it's already in
another spec, But, I think it's just because we didn't have anywhere else
to land some of that stuff. So just as a point of data we may end up…

Manu Sporny: where some of the protocols are defined in this spec and then
maybe some other protocol utilizes the data model and the algorithms in a
different protocol. that's

Dmitri Zagidulin: agreed. Thank you so much.

Dmitri Zagidulin: Part of the reason why I wanted to double check with the
group about this is so yes we've got the typical data model versus protocol
and we have a couple of external requests that external specs that exist
that monu mentioned for example using vcom spec to request zcaps but then
also we need to specify how to revoke them and how to use them with http
bindings so far that there's consensus I mean let's just keep it in one
spec.

Dmitri Zagidulin: The reason I wanted to double check is also we've got the
data integrity aspect of it right specifically the introduction of the
capability chain build and introduction of additional logic in the
verification of data integrity proofs specifically for Zcaps. So you just
wanted to make sure that it's okay to keep them as a normative part of this
spec. That sounds like yes.

Benjamin Goering: Concerns.

Dmitri Zagidulin: All right.

Benjamin Goering: I do anticipate that as we flush some if we keep these in
the spec and we resolve a lot of the ambiguities and generate a lot new
pros, it'll start to be a lot of stuff and it might make sense to move into
other specs. But let's wait till we've drafted and agreed on what that pros
would even be before we split. That's kind of an idea.

Dmitri Zagidulin: All then let us go with it. Go ahead. Bottom. Does it
require C or…

Manu Sporny: just administrative procedural. you could topic these and put
the GitHub issue marker in we can have a process that goes in and adds
everything that was said into the GitHub issue. There's a tool it works
over chat.
00:25:00

Dmitri Zagidulin: can it also work over copy that.

Dmitri Zagidulin: let us know if we need to do anything to make that
happen. Go ahead.

Manu Sporny: Yeah, we'll need to get Pier Antoine to run the tool against
our minutes, but I think it should hopefully

Dmitri Zagidulin: Yeah, that's super convenient. I really like how that
works in the VC and DI working groups. All right. Excellent. that was
pretty overwhelming consensus. Next up, I wanted to mention in case it's
interesting to folks, so the diff trusted AI agents working group is
working on a paper on authorization delegation.

Dmitri Zagidulin: The paper is performing an overview of existing
specifications and evaluating them against a checklist. is the spec does it
enable accountability resistance to confused deputy? does it present
authorization policies? Is it chainable? etc. And the reason I wanted to
bring it up is that Zcaps is one of the chapters in this spec. So we
encourage folks in this group who are interested in delegation technologies
to read comment in the margins and so on. All right.

Dmitri Zagidulin: Next up, Moyes, I wasn't sure if you wanted to,…

Dmitri Zagidulin: briefly touch on, the pausing use case that you brought
up because I thought it was pretty interesting. Then just a few words.

Moises Jaramillo: Hi everybody. Yeah. thank you for giving me the time. I
did really not intend for all of us to dissect this but really more of in
for all you experts here to be introduced to it why the need and then in
your own time if you wish to think about whether we should really support
this or not so I think you're sharing it perfect the

Moises Jaramillo:

Moises Jaramillo: First of all, I'm actually glad that the agentic world is
taking ZCAPS seriously. I started working on Agentic AI solutions over a
year ago and I say to myself why aren't ZCAPS a perfect tool for this type
of trust between agents? So I'm really happy that the market seems to be
validating that risk that I took a while. So now to expand into that I do
see cases where now agents hold authorization capabilities whether from
other agents or from humans or from organizations it doesn't matter.

Moises Jaramillo: There might be the case where maybe the behavior of an
agent holding a capability is suspected of misbehaving. And then I thought
of it, why couldn't we suspend pause that capability that delegation until
there's a further investigation? And if the investigation deems that the
alleged misbehavior is real, then of course, we support revocation. Revoke
it, right? And minimize the damage done. But what happens when maybe it was
a false alarm and that in that problem? Yeah. Bumble fudged. Yes.

Moises Jaramillo: you raised your okay I'll keep going. So what happens
when maybe it was a false alarm and we want to resume that delegation. So
give the privileges back to the agent and obviously the workaround is to
revoke that delegation and issue a new one right but at the end that's
actually bad user experience in my pers from my perspective and really what
I'm trying to solve here is patient use cases somebody a patient goes to
see The clinician leverages agentic AI for tracking and coordination of
medical records. but the patient

Moises Jaramillo: already agreed to let these agents do the work. So I
think it's a bad user experience to go back to the patient and false alarm.
we first thought that agents were misbehaving, but they're not. would you
sign this delegation? so I don't know. I just wanted to throw this out
there. kind of explain the use case. if this is something interesting take
a look at this issue number 73 and then just let me know why this is a bad
idea or maybe this is a good idea but we shouldn't support it because
there's intricacies I know Alan is really good at explaining all of those
attenu can of worms u so I just wanted to throw it out
00:30:00

Moises Jaramillo: To see if this is something that is interest of to you.

Dmitri Zagidulin: This is a really interesting use case.

Dmitri Zagidulin: right, we've got Juan and then Alan on the queue.

Dmitri Zagidulin: Juan, if you're speaking, you're muted.

Bumblefudge von CASA: Can you hear me now?

Dmitri Zagidulin: Yes, no worries.

Bumblefudge von CASA:

Bumblefudge von CASA: Sorry about that. I was going to say it makes sense
as a use case to accommodate, but I'm not sure it makes sense for suspended
to be a state of the capability because it feels more like suspension
happen when you go to invoke something during a period when chains or
actors or the entire thing is suspended. That feels more verifier state it
doesn't need to be encoded the credential in my wallet doesn't have to say
suspended because do you know what I mean?

Bumblefudge von CASA: It'd be good if the audit trail had some sort of
record of okay for two hours everything touching this sector or actor or
whatever was suspended. But I'm not sure it needs to be in the portable
cert.

Moises Jaramillo: That makes sense. I think it rides on the same rails of
revocation, right? There's a ledger out there, some highly available
service that in many manners does keep track of the state of that
delegation. when we introduce revocation and if we make revocation a first
member type of functionality it really rides on the same rails…

Moises Jaramillo: if I'm not

Dmitri Zagidulin: Thanks Alan and…

Dmitri Zagidulin: then Monu

Alan Karp: I think this is a useful pattern, but I can envision a gazillion
such patterns and having a mechanism for each of them would seem to be
awkward in a spec. what you can do if ahead of time you might want to
suspend is use a caretaker pattern where the agent is actually talking to a
proxy that will forward requests or not. That's the way you do revocation
object reference as capability system. That's all you can do in that
system. But here you could use that to run arbitrary code to make an
arbitrary policy decision about whether to forward the request or not. and
that would cover this use case and a gazillion others that we might think
of in a single mechanism.

Alan Karp: The downside is you have to know you want to do it ahead of
time, but other than that, maybe that's the better approach.

Dmitri Zagidulin: Thank you,…

Dmitri Zagidulin: Monica. Go ahead.

Manu Sporny: Yeah, I mean I think plus one to…

Moises Jaramillo: Yeah,

Manu Sporny: what Allan and Bumble Fudge said, I think my biggest concern
is the explosion in complexity here, So it is definitely a valid use case,
right? people are going to want to do that. I think we need to find the
minimum viable way to achieve this use case and many others. And the
pattern that Allan spoke to could be one of those things and we need to
write about it in the spec, right? So, what's the outcome here? we should
probably write about the pattern that Allan mentioned as one way of doing
this thing in the spec. the other thing that's a bit dangerous here is how
rapidly these values can change and how deeply nested the thing is.

Manu Sporny: it can turn into a denial of service vector for someone just
trying to evaluate whether or not whether or not this thing that they
received is an acceptable thing and having to reach out to an external
system each time to do that is becomes increasingly dangerous the more you
have to do it plus one to the use case I think it's a valid use case we
should capture these types of use cases and see if multiple of them
achieved through for example Allen's caretaker model or if we should con
consider instead of revoked and suspended just having an non-active thing
where this maps to it.
00:35:00

Dmitri Zagidulin: Beno, go ahead.

Manu Sporny: That's it.

Benjamin Goering: Yeah, I left a comment to this effect, but I think the
use cases interesting. and I think we talked in the last call about having
an kind of an ing community work item gathering use cases that we agreed
were worth pointing back to and this seems like the beginnings of a good
one. one of the things going through this spec recently and reading some
relevant literature in the last week is there are some old issues about
macaroons and why don't we do things this way that supposedly macaroons do.
So I was reading a lot of old macaroons papers which get into specific
designs for first party and third party caveats which are somewhat hinted
in the decap data model but aren't elaborated upon but I think this type of
use case may be something that can be satisfied in the use in the existing
caveat affordances without necessarily the exact notion of status idea
ideiated here.

Benjamin Goering: So there may be several ways of accomplishing the use
case and the one that's already in the spec talks about caveats and there
being one that's called valid while true. I think one thing we need to make
a decision on pretty soon in the spec that's already there what does that
mean? Is that a real thing? Is that a real caveat that has requirements
around it and if not take it out and also how could caveats be used for
this kind of use case. I think that's something I can do some writing on.
Especially if we capture this into the use case and…

Benjamin Goering: separate it from the particular mechanism it imagines
that would solve it. Then we can compare that and that this option and
eventually have a good explanation next to that use case and how our work
items can make it happen.

Dmitri Zagidulin: That sounds great.

Dmitri Zagidulin: Phil, you're up next.

Phillip Long: Yeah, related to I was struck by what Allan said in
addressing this problem. I know work that I've been engaged in at ASU,
they've been using a set of agents with an initial agent as an orchestrator
and then successive subdelegations from the orchestrator to sub agents
working under it. and somewhat similar to what Alan was saying, rather than
when an issue arises that may violate or a sub agent scope that they're
trying to do, that information is sent back to the orchestrator, which
looks at the overall problem that's trying to be solved and makes an
adjudgment as to whether that is in fact violating the intent of the
problem that is being made and makes a decision at that point.

Phillip Long: And this pattern has been useful for them in keeping these
loops starting to build between for example a coding agent and an assessing
agent that's evaluating the code that the coding agent made and they find
that that can end up in an endless loop of tokens expenditures as minor
tweaks are made and…

Dmitri Zagidulin: Thanks. Good point, Alan.

Phillip Long: the progress sort of stops at a great expense. Just wanted to
throw that out there as Another dimension of this

Alan Karp: if we're talking about use cases there's another use case that
came from Nicola Gallo and that was an unknown delegate so if I want to
delegate through something like Kafka I post something to Kafka and the
subscribers pick it up and I want the subscriber to that pick it up to be
delegate the way we're doing the delegations chains we have no way to
express that directly I'm wondering… if that's a use case bring it up in
the issues. I'm just wondering if it's one we should consider.

Alan Karp:

Dmitri Zagidulin: I wanted to hop on the queue to so that's also a really
good use case.

Dmitri Zagidulin: We should definitely capture it. Whether or not we should
explicitly specify it in the spec is up for discussion. I have a similar
use case wanting to delegate to, for example, an email, Typical Google Docs
workflow. you're working on something, a resource, you want to share it.
00:40:00

Dmitri Zagidulin: It's very unlikely that your recipient has a DID and…

Alan Karp: Cute.

Dmitri Zagidulin: a DID key and B that you remember what it is. Once we
have integrated wallets and contacts books into the wallets, that stuff
will become easier. But for the moment, state-of-the-art is share to an
email. What does that look very similar to your CFKA example. And so far
the implementation solution is to do it of scope in application land you
set up a notification endpoint and a pickup by email endpoint.

Dmitri Zagidulin: a system that proves control of an email by you the usual
sending of a code but then after that it issues a zcamp and Dave mentioned
in chat also the interaction URLs from the vcom spec which also might be
useful Dave do you want to expand on that or…

Alan Karp: Sorry.

Dmitri Zagidulin: shall we wait until there's an issue go ahead

Dave Longley: Yeah, I just put it in chat because I didn't know that we
wanted to spend too much call time on it. I was just offering another
option there are interaction URLs in the VC colon spec which are capability
URLs. You could send that to an email and when the user uses the
interaction URL, you can do all kinds of things like you could ask them for
a VC that they would have had to acquired previously or that they could
acquire on the fly through some other process. So it's a primitive that
allows you to do a number of different things and you could ultimately end
up handing them a Zcap if they were able to actually invoke one because
they had key material. So it gives you a variety of options.

Alan Karp: The reason I like the Nicholas use case is one solution would
affect the data model. And so that's where I think that it's worth
considering. the idea is that any legitimate subscriber has the same public
private key pair but then you need for responsibility tracking a separate
way to identify them and…

Alan Karp: that would be additional data in the certificate which again it
changes the data model which is why I think it's an open question whether
we do I will heat.

Dmitri Zagidulin: …

Dmitri Zagidulin: Alan, if that is a great use case, can you open an issue
to track it? Excellent. Ben, you're up next.

Benjamin Goering: Yeah, I guess I just want to advertise that yeah,…

Benjamin Goering: so often these use cases are tied to a particular change
to the data model or behavior and stuff and makes me really nervous. So in
general just want to advertise anytime there's something like a use case
I'm going to try to advocate that we get it documented as a use case at
least separate from this mechanism that may or may not solve it and also
ideally into the publishing workflow that we're doing with change control
with the spec itself. what I think would be great would be the Zcap spec
having a folder of use cases in the git repo and in general we can ideate
in the GitHub all we want with to get to the point of actual text but a lot
of times if someone gets to a use case on an issue I'm going to be great
can you make a poll request adding a markdown file to the use cases
directory and I see Dave has a reaction I'm curious if that sounds workable
for people Dave…

Benjamin Goering: what do you

Dave Longley: No, it sounded good.

Dave Longley: I also just wanted to say that also gives us space to decide
whether or not we think we need a data model change. There might be a
variety of interesting ways to solve these problems without making data
model changes and we need the space to do

Dmitri Zagidulin: …

Benjamin Goering: Yeah, ideally each of these use case documents could have
a section that's great here's…

Dmitri Zagidulin: just to clarify,…

Benjamin Goering: how you would do it. and one of the answers could be
we're totally blocked right now until these issues are resolved but other
people could pull request in here's ways that you could do it in user space
and eventually that can inform the main text. Sorry to skip the Q one.

Dmitri Zagidulin: no worries. I see you on the queue, but I just want to
clarify. Bango. so you're saying preference is not issue, but a pull
request into the Okay.

Benjamin Goering: I think issue I for now issues fine. Everything's fine.
if this doesn't sound crazy, I'm going to create an initial directory like
I'm saying and maybe try take a stab at ex turning one one of these into a
use case and…
00:45:00

Benjamin Goering: then we can talk about it on the next call. But no one
needs to change behavior now. Just more like object to what I'm saying if
it sounds like a bad plan.

Dmitri Zagidulin: Got it.

Dmitri Zagidulin: Come on. Go ahead.

Manu Sporny: Yeah, it's an interesting way to go about it. I don't know of
many other groups that have done that. but I don't think it's a bad idea.
So usually when we take this stuff onto the standards track, they meaning
the horizontal review groups like the technical architecture group,
internationalization, accessibility, security, and privacy. They're going
to ask us what are your use cases and how to use the spec to address those
use cases. So we do have to have the use cases documented at some level.
and ideally we show them how we address it. though what typically ends up
happening is some groups do a totally separate use cases document and they
just talk about use cases. They don't talk about how to solve it. some
groups put their use cases directly into the spec and how to solve it into
appendices.

Manu Sporny: Of those two approaches, the latter is the easiest thing to
get through the W3C process. Meaning that we at least have some focal core
use cases in the specification and we have some appendices on for this use
case, this is you address however, what you end up having to do in that
case is you have to cut use cases. You have to decide which use cases are
worth mentioning in the spec and which ones aren't. And I think that's
where Bango, your directory of markdown files with use cases and then
potential ways to solve it is a great kind of like scratch pad area, it
doesn't block the spec. It allows kind of people to put in pull requests to
the markdown files to address them. so just some thoughts there. I'm not
saying one way is better than the other.

Manu Sporny: I'll also mention that it is very hard for some people to
engage on markdown edits, whereas in the issue tracker, you just jump in
and you type some stuff and you're done, So, if you have a drive by
comment, you can do that in the issue tracker. you can't do that. or…

Manu Sporny: if there's back and forth, you can do that in the issue
tracker, but you can't do that in the markdown file. just as a, suggestion.
It's a good Yeah,…

Benjamin Goering: One of my concerns this is the ease of creating permanent
issues that are basically impossible to resolve…

Benjamin Goering: because they're just there to track a use case. But it's
not clear how do we make a decision on Not Minton.

Manu Sporny: I think that is a very good thing to be concerned about. We
don't want perma issues. and so you could say I mean you're right as an
editor to basically say where is this issue If it's going nowhere I'm going
to close it. Right?

Manu Sporny: So if something is a use cases issue, the expectation is that
eventually it ends up in a markdown file or in the spec. And if it has been
out there for six months with no real movement one way or…

Manu Sporny: the editors and organizer can just say we're going to close
this because there doesn't seem to be consensus. We're not getting there
and we have other things to deal with.

Dmitri Zagidulin: Thank you.

Dmitri Zagidulin: So Juan,…

Dmitri Zagidulin: I see you on the queue. I do want to move on to the other
items. Make sure we have time for them. Go ahead.

Bumblefudge von CASA: Yeah, maybe terrible idea,…

Bumblefudge von CASA: but just one way to gather lots of a sort of
compromised solution is just to leave PRs open for each markdown file so
people can comment on it and it can iterate over time and still close them
after six months if there's no discussion but whatever It's just a ID off a
double edge.

Benjamin Goering: I think I also don't want that…

Benjamin Goering: because I don't want a PR to be open for six months. I
just think each good change can be a separate PR with rationale and…

Dmitri Zagidulin: Yeah. Agreed.

Benjamin Goering: there's no in general an anti-attern to me as of
longunning PRs. We can just have many separate PRs with a distinct owner
and improve this back over time in many ways. I think it'll be good that
way.

Dmitri Zagidulin: Sounds good. All right. I'm sure we'll come back to this
topic again for the moment. Just give us your use cases one way or another.
We'll get them in there. or at least we'll discuss them. moving on to EDVs
real quick. one thing I just wanted to clarify once again the situation. So
the EDV spec is currently being hosted by diff.

Dmitri Zagidulin: And we've got Juan who's a representative of diff here
who can clarify anything that I say. but the general deal is this task
force is doing three specs, two of which are CCG only, one which is both
diff and CCG. If we do have people that are diff members but not
credentials community group members, then they can join the call. They can
make contributions to the spec because they're covered by the diff but as
editors and chairs and conveners we'll have to remind people that if you
want to make contributions to the other two specs you need to be a member
of the CCG.
00:50:00

Dmitri Zagidulin: So just to clarify let me know if anybody has questions.
next up I wanted to draw people's attention to the recently open. So I open
an issue basically doing a very similar overview on the EDV spec that Bango
did with the ZCAP spec and sort of outlining if not road map then the bits
that we're going to fix first. so

Dmitri Zagidulin: So please take a look add on to it and you can start
opening issues on Any questions about spec assessment basically goes over
yeah we need some more sections. we need to clean up the issue blocks which
I think some of them are broken. we need to document some of the spec
versus implementation differences and so on. next up, yeah, go ahead on.

Bumblefudge von CASA: Are your editor on the EDB spec?

Dmitri Zagidulin: Correct. But…

Bumblefudge von CASA: Okay. …

Dmitri Zagidulin: but other editors are welcome. Please come join.

Dmitri Zagidulin: Hey. I'm not on there officially. so I'll add myself to
it.

Bumblefudge von CASA: and I haven't seen security active on diff lately. I
believe it's been what do you call it absor acquired something I don't know
if it's still a company called secure key but couldn't hurt to double check
with any editors that are still listed…

Dmitri Zagidulin: Got it. So, we should reach out Well,…

Bumblefudge von CASA: if they want to be former editor or they take it off
or if they want to participate. yeah.

Dmitri Zagidulin: fortunately, one of them is on this call.

Bumblefudge von CASA: I mean,…

Dmitri Zagidulin: Manu said that he's okay.

Bumblefudge von CASA: yeah, I saw B

Dmitri Zagidulin: Can you reach out to Derek and ask him if he wants to
still be on the No.

Manu Sporny: I don't think he's at that organization anymore. we should
Yeah,…

Dmitri Zagidulin: Okay. Yeah.

Manu Sporny: I can try to track him down. I don't know where he is these
days. we should do a new call for editors of the spec,…

Manu Sporny: Dimmitri, we need to add you. I'm happy to stay on there.

Dmitri Zagidulin: Yeah. Yeah.

Dmitri Zagidulin: Yes. Absolutely.

Manu Sporny: We should ask Derek if he wants to continue on there, but
please, anybody else that wants to be a part of the fun of editing a spec,
feel free to step forward. we need editors for this spec.

Dmitri Zagidulin: Call for encrypted data vaults, and on a similar note,
call for editors or wallet attached storage. definitely need volunteers
there. Next up. Go ahead. Right.

Bumblefudge von CASA: I was just confirming that security key got rolled
into Jen.

Bumblefudge von CASA: Jen is no longer so whatever IP unless Derek joined
diff or CCG individually at the time then he would have to rejoin either or
to be editor Thanks.

Dmitri Zagidulin: Right. Okay. next up, I wanted to ask the group if
there's any interest to adopt the EDB conformance suite. So, got the suite
here my team's worked on. it covers much of the spec and the current
implementations. We have two implementations passing the digital bazaar and
the interup alliance one plus anybody else that comes in with an
implementation. So, I wanted to ask if the group is interested in adopting
it into CCG. Go ahead Mono.

Manu Sporny: Yeah, plus one. I think it's a great idea.

Manu Sporny: We're super ahead of the curve if we adopt it, Because you
don't usually have one of those until you go into candidate wreck in a W3C
process. So, hooray. Thank you very much, Demetri, and your team for
putting it together. plus one to adopt it. I think it'd be good to have it.

Dmitri Zagidulin: Right. Right.

Dmitri Zagidulin: All So if there's no objections, I can transfer it over
to the CCG or yeah,…

Manu Sporny: We process question I guess Dmitri do think we have to put it
forward as a proposed work item. I don't think it'll be or can we just do
it because it's a part of the existing Right.
00:55:00

Dmitri Zagidulin: I think we can do it as because it's directly related to
the spec that is a work item.

Manu Sporny: Yeah. I'd say just ask the chairs and…

Bumblefudge von CASA: But it no sorry so the test suite for the EDG one was
in scope of the liaison agreement and…

Dmitri Zagidulin: Yes,…

Manu Sporny: they'd probably be fine with it.

Dmitri Zagidulin: I'll ask the chairs and I'll open an issue on GitHub about

Bumblefudge von CASA:

Bumblefudge von CASA: There's a placeholder for a test suite that seems to
predate that work in the diff repo already linked from the EDB spec.

Bumblefudge von CASA: So you could just merge that onto the existing EDB
conformance suite repo in diff GitHub.

Dmitri Zagidulin: That's a good point and…

Dmitri Zagidulin: that's also an option.

Bumblefudge von CASA: No.

Dmitri Zagidulin: All right.

Bumblefudge von CASA: What I meant was it isn't a equivalent option like it
it's kind of confusing if there is one that is outofdate and there's
another one in CCG. I would just overwrite the outofdate one with the
up-to-date one because that's…

Dmitri Zagidulin: All right.

Bumblefudge von CASA:

Bumblefudge von CASA: where it's supposed to go. and…

Dmitri Zagidulin: Sweet. Yeah. got I see a plus one.

Benjamin Goering: Can you link to…

Benjamin Goering: what you're talking about bumble fudge so I can follow…

Bumblefudge von CASA: yeah, sorry.

Benjamin Goering: what you're saying? I went to a repo and…

Bumblefudge von CASA: I put it in …

Benjamin Goering: I do not on diff for spec and I don't see a test sweep.

Bumblefudge von CASA: Hold on. I found it earlier. I thought I shared it.
Okay, I'll try to find that window. yeah.

Dmitri Zagidulin: Okay. Yep.

Dmitri Zagidulin: All right. So, we'll come back to

Bumblefudge von CASA: I'm just trying to clean up all this mess.

Dmitri Zagidulin: Listen, at least a link.

Bumblefudge von CASA: On behalf of diff, I'm probably the only person at
DIFF that remembers any of this stuff. I don't think anyone has any strong
opinions about what happens with any of it. at the very least if it moves
back, I want to make sure there is or I don't just mean on GitHub. I mean
there was a leazison agreement between CCG and diff for this to be joint
works and I don't think there's anyone at DIFF who has inquired in years
about participating on the diff side but if it becomes a CCG work item
again you'd have to somehow reverse that agreement for retroactive
clarity's sake.

Dmitri Zagidulin: Right.

Bumblefudge von CASA: Just to refresh my memory, I looked up all the
language of the old agreements and there's a bunch of stuff in there about
what happens if this gets bumped up to normative status within W3C, which
would be kind of a mess if it never left diff or if DIFF never whatever
rubber stamped the if nothing changes, if this just remains a joint work
item with only CCG members participating in it. just rubber stamps it
because there's no diff participant to say anything otherwise. Do you know
what I mean? the default state is that if no diff members are
participating, that whole section of the approval process is just skipped.

Bumblefudge von CASA: But I just think for the sake of IP cleanliness
before godliness, it would be good to either stick to status quo or write
an agreement that reverses the older agreement. because doing anything else
just makes lawyers nervous later.

Dmitri Zagidulin: understood. that's a very good point. so'll do that.
We'll make sure to cross our tees. real quick because I want to make sure
we get to this item. Bon, if you want to talk about the vouch announcement
and…

Manu Sporny: Sure thing. let me always a great question.

Dmitri Zagidulin: which of the vouched Is it the ED or just D?

Manu Sporny: This is the chaos stuff. So, …

Dmitri Zagidulin: Aha.

Manu Sporny: let me share my screen. So, I think, vouched and diff just
announced that the chaos protocol, which is basically a know your agent,
protocol, published a 10. and a lot of that's based off of DIDs, and VC.
So, there's a lot of W3C tech, in here. but the way that they're doing
delegation is, I mean, it is a way to do delegation. And it uses VCs to do

Manu Sporny: But they also have a Zcap part in here as well. And so this is
just like a heads up. we should probably engage with Vouched and DIFF on
this because they're basically doing two ways of delegation and I think
many of us agree with one way and the other way is not super great. And
then there's also a protocol in here as So just flagging that to engage
with them as the weeks roll on. They're super friendly,…
01:00:00

Manu Sporny: nice folks. They've presented to CCG before so on so forth. Go
ahead, Demetri.

Dmitri Zagidulin: Fantastic. Yeah,…

Dmitri Zagidulin: I just wanted to add on to that. So, I've been engaging
with them as part of the authorized agentic working group at DIFF. they've
came to several of the delegation calls and they're aware of Zcaps
obviously since they mentioned them and they're essentially the reason why
we added a chapter to if I can u take over present the reason we added a
chapter to the spec overview paper on essentially how to do

Dmitri Zagidulin: ZCAPS as a VC and why you should or shouldn't, right? So,
they're definitely engaging with us on this. so, yeah, love to have further
conversation with them about versus ZCAP equivalent in VCs etc.

Dmitri Zagidulin: Han, go ahead.

Bumblefudge von CASA: Yeah,…

Bumblefudge von CASA: I would just mention that part. So exists diff they
already have a product and customers in prod for something they call chaos
and they wanted to govern future versions at diff and one of their hopes
and plans was to make it really modular and extensible and one of the
things I talked them into as a goal for version 1.2 two would be that when
you install it, you can configure whether or not you want to accept or
differently treat their native VC delegations which they are using and
broad and multiple other kinds of delegation chain like they have said if
someone wants to submit a PR that parses Zcaps according to the Zcap spec
and someone else wants to submit a PR for the UK

Bumblefudge von CASA: pen version and someone else wants to do a I don't
know macaroon version within reason maybe not macaroon but their idea is
that it would be a pluggable thing like you could have one or more
delegation logics allowed by each specific chaos instance and the degree to
which ZCAP is a fully fleshed out option or a recommended option or just
something that's theoretically possible is probably contingent on
volunteerism.

Bumblefudge von CASA: If anyone just shows up to meetings and says hey I
already implemented it. it would look like this. If someone does have to
work they'll take the PR I'm guessing.

Dmitri Zagidulin: Got it.

Dmitri Zagidulin: So, we are at the top of the hour, so we'll continue, but
yes, we'll definitely interact with the chaos group and vouch. thank you,
Manu, for bringing that up to everybody's attention. real quick. I wanted
to ask the group, is there any interest in an open hours call on the off
weeks, So this is twice a month. This is for the other two twice a month.
I'm willing to host a just open office hours call for anybody who's an
implementer who wants to come and ask questions. So any interest in that
raise your hand or put a plus one in chat.

Dmitri Zagidulin: All right, got a one from Moises. Yep, Mono mentions DB
thinly stretched.

Dmitri Zagidulin: And…

Benjamin Goering: I'm a little worried honestly that for now can impleers
just come to these calls and…

Benjamin Goering: ask questions more.

Dmitri Zagidulin: yes. Yes. also good point.

Benjamin Goering: I would rather spend the ext…

Benjamin Goering: but I'm worried that if those calls are happening it will
create more work for me.

Dmitri Zagidulin: Understood. unerstood.

Dmitri Zagidulin: So Bango and Manu implementers come to the calls. then
we'll hold off on it until there is more demand. Thank you everyone. talk
to you all next week.
01:05:00

Dmitri Zagidulin: Issue number add items for the next call's agenda the
same place …

Dmitri Zagidulin: which is here and see you all in a couple weeks.

Moises Jaramillo: Thank you,…

Moises Jaramillo: Demetri, and…

Dmitri Zagidulin: By thank you

Moises Jaramillo: everybody. I

Lancine Toure: The light.
Meeting ended after 01:09:29 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*