[MINUTES] CCG Incubation and Promotion 2025-06-18

CCG Incubation and Promotion Meeting Summary - 2025-06-18

*Topics Covered:*

   - *Meeting Quorum and Summer Slowdown:* The meeting started with a
   discussion about low attendance due to summer vacations.
   - *ZCAP Spec Revival:* Dmitri Zagidulin expressed interest in reviving
   the ZCAP specification, driven by his work on a wallet-attached storage
   spec using ZCAP for authorization. A discussion ensued about the scope of
   the work (authorization vs. storage), potential integration with existing
   W3C groups (LWS, DID, Security Interest Group), and the need for updates to
   the ZCAP spec (HTTP signatures, delegation proofs). Dmitri will take a lead
   editor role, and a separate ZCAP work item call will be scheduled. The
   potential for aligning with the data integrity spec was discussed.
   - *Status Updates on Other Specifications:* Manu Sporny provided updates
   on several specifications, including quantum-safe crypto suites, VC API,
   verifiable presentation requests, verifiable issuers and verifiers,
   verifiable credentials over wireless, and credential refresh. Progress on
   each varied, with some specifications experiencing slower progress due to
   summer vacations and lack of engagement from some contributors.
   - *Verifiable Credential Rendering Specification:* Lack of engagement
   from contributors in Singapore was noted, along with the need for input
   from Patrick St. Louis on overlay capture architecture.
   - *Wallet-Attached Storage:* This was discussed as a primary use case
   for the ZCAP spec, highlighting the need for a standardized, secure storage
   mechanism with robust authorization. Discussions included use cases from
   the retail sector (pushing data to wallets, digital receipts), and
   employer-employee contexts (credential requests). The concept of a
   credential-specific inbox for updates and communications was explored.

*Key Points:*

   - The ZCAP specification is a high priority for several participants due
   to its importance in secure authorization for various storage mechanisms.
   - Several potential homes for the revised ZCAP specification within W3C
   were identified (VCWG, DID WG, Security Interest Group, or a new group).
   Consultation with W3C staff (Simone) was suggested before making a decision.
   - The meeting underscored the importance of aligning related
   specifications to avoid fragmentation and repetition of effort, drawing
   lessons from past standardization efforts (e.g., SD Jot/M).
   - Summer slowdown and challenges with contributor engagement were
   acknowledged as impacting progress.
   - There is significant interest in the wallet-attached storage concept,
   driven by a number of real-world use cases.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-06-18.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-06-18.mp4
*CCG Incubation and Promotion - 2025/06/18 10:55 EDT - Transcript*
*Attendees*

Alex Higuera, Dave Lehn, Dmitri Zagidulin, Hiroyuki Sano, Jesse Wright,
John's Notetaker, Manu Sporny, Phillip Long, Ted Thibodeau Jr, Tom Jones
*Transcript*

Manu Sporny: All right. Hey everyone. Let's go ahead and get started.
Although I think we may have to cancel the call for today. we probably
don't have enough people for quorum. I know it's summer so lots of people
are on vacation these days. and I expect that to kind of continue. So, this
is largely just a check-in call to see how things are going. I am bringing
up our kind of work items to kind of list what we have ready and then what
still needs to be worked on. so we'll just kind of go down the list see if
anybody has any updates and if not we can cancel for today.

Manu Sporny: but before we do that any updates on work that's being done
that might be related to promotion of work items or anything of that
nature. any other kind of work that would be of interest to the community?

Dmitri Zagidulin: I mean, I think I mentioned it before to you directly,
Mano, but I'm definitely interested in reviving the Zcap aspect. It's so at
dcc and with a couple of other places I'm actively working on a wallet
attached storage spec and that just uses Zcap for the authorization layer.
And so as a result of that right there's going to be more attention on the
ZCAP spec.

Dmitri Zagidulin: So, I'd love to and I figure I can just start with some
PRs to the existing spec, but just to plant the seed that I'd love to have
some task force calls with people interested in Zcap stuff.

Manu Sporny: Okay, that sounds good. I guess let's talk I mean we don't
have anything else on the agenda today. So let's talk about what that could
look like. Mark needed let me get the link to that very outofdate spec I
should say old. so I'll put that down there as kind of one of the things
we're looking at. are there any other Let's add that to the agenda,
Demetri, and let's have a brief discussion on it and then, kind of go are
there any other items that folks want on the agenda today? I'll run through
and just give a quick kind of status update on what's happening with some
of these.
00:05:00

Manu Sporny: for the quantum safe crypto suites, we have a big PR that will
put together that I think we'll get into the spec this week that defines
all the postquantum crypto suites that we believe are in scope including
all the FIPS ones MLDDSA stateless hashbased DSA and some other Falcon
which we're expecting to happen in the next year be standardized in the
next year or so and then our hope is that something along the lines of the
isogynes and sqi stuff survives because if that does then we have super
small postquantum signatures that would be good. So there's work happening
there to move that forward.

Manu Sporny: debatably it'll be ready by the end of the summer to go
standards track. we continue to work on the VC API. we're getting a slow
trickle of PRs in. we have been able to categorize all the PRs as loweffort
or high effort. We're going to leave all the high effort items to the
working group. It requires some decent working group discussion. but the
loweffort ones we've identified as fairly straightforward PRs to add a
paragraph or two of text or just modify some of the arguments sent to the
API. So that is progressing verifiable presentation request we have not
been through and categorized loweffort high effort items on that just yet.
So that needs to be done.

Manu Sporny: and there's also kind of a discussion on whether or not we
should merge it with VC API. I think we're leaning towards not doing that
just yet. for verifiable issuers and verifiers for that specification, I
think we're waiting on David Chadwick and Isaac to let us know when they're
going to update, the specifications. We did identify some things that we'd
like to see updated before it goes verifiable credentials over wireless. I
still have not sent that email out for adoption. but we've got some
organizations that are interested in that. specifically in the first
responder community where you are often offline in the worst situations and
you want to be able to transmit something verifiable credential over near
field communication setup.

Manu Sporny: for credential refresh for the credential refresh
specification there has been some discussion on the mailing list about
phone home and making sure that we don't do not support really bad forms of
phone home for example the verifier contacting the issuer directly to pull
the exact credential down from the issuer. That is the worst kind a phone
home that we're want to avoid. and so there's also some discussion around
maybe we shouldn't even put the instructions on how to do that within the
credial. Maybe they should go in a separate credential that the holder
never provides to anything else. Or maybe it should be a protocol level
thing.

Manu Sporny: where the issuer if they have a DID document would publish
credential refresh location and a protocol for refreshing credentials just
publicly so that the holder can refresh it whenever they need to without
that information leaking into the credential or having to manage a separate
credential or anything of that nature. So there's some discussion around,
how to refresh those credentials automatically. and I think that's kind of
where we are right now. Still, a decent bit of work to be done. And, of
course, now that we're in the summer, things are moving a little more
slowly, than we'd like them to. So, that's kind of where we are on each one
of those items.
00:10:00

Manu Sporny: I will also note on the rendering method stuff we have not on
the verifiable credential rendering specification we haven't gotten good
engagement from the folks in Singapore and that were working on some of the
rendering stuff. So we need to reach out to them to see what's happening
there. And I know that also Patrick St. Louis really cared about the making
sure that the overlay capture architecture stuff was supported and I think
he's going to present something along those lines as well to go into that
specification before we put it in the working group.

Manu Sporny: Okay, I think that is largely it for updates on all the other
specifications. so let's go ahead and dive down into the ZCAPS
specification. So Dimmitri, why don't you go ahead and kind of give us some
background on what you're working on that's using ZCAPS. what changes you
think might be needed to the specification and what form you'd like to kind
of work on that stuff meaning separate work item group or a part of this
work item group and your kind of hopes and…

Dmitri Zagidulin: Okay.

Manu Sporny: expectations around timeline I think that'd be good to just
give us some background on that Demetri so Please go ahead.

Dmitri Zagidulin: So, the overall motivation I think for, wanting to
revisit Zcaps, aside from the fact that they're useful in general, is
specifically, myself and a handful of other folks are working on this
wallet storage, very early spec. and what it is it's what it is you can
think of it as a spiritual successor to solid just simplified and a more
straightforward JSON REST API.

Dmitri Zagidulin: it's complimentary with encrypted data vaults in the
sense that this encompasses encrypt for encrypted data it uses encrypted
data vaults but it also deals with public data and it also deals with
shared data right like Google document style and you can see sort of the API

Dmitri Zagidulin: later down in the spec. It partly arose from our work at
DCC fielding an open- source mobile wallet and needing to share credentials
in a publicly accessible way. so we needed to put them somewhere and so we
tried storing them in Google Drive.

Dmitri Zagidulin: We tried storing them in just a one-off storage API and
ran into various problems with it. in addition, we ran into use cases of
okay, so we've got these credentials, but wouldn't it be great if we could
store evidence for them as well, right? So, we've got these skill
credentials. but you want to attach I see Phil's here. He's part of this
general work and community.

Dmitri Zagidulin: you have these skill credentials and you want to attach
evidence to the credential and so in these apps that help you authoring the
credentials you need somewhere to upload right so we've got this family of
use cases it would be great to have file store object store document store
that's MongoDB and even relational database.

Dmitri Zagidulin: All of these things have very similar access patterns and
all these things have exactly pretty much the same authorization
requirements a combination of semi-traditional access control and
capabilities right so the way I always explain it is think of Google Docs
you're sharing a document you have a popup and the up has two sections
specific list of people to share it with
00:15:00

Dmitri Zagidulin: individuals and groups and then below anyone with the
link dot so list of people shared with that's sort of classical alle anyone
with the link can that is a simple form of authorization capabilities of
course the zcap spec that we're talking about here can work like that but
is more intended for slightly more advanced use cases where the client can
demonst the straight proof of possession of cryptographic material. and the
reason it's called wallet attached storage is essentially projects like
this, including solid. we've been trying to standardize storage for decades
now, right? And the main thing that has been missing is authorization.

Dmitri Zagidulin: And I feel Zcap is a large part of the solution. And Zcap
basically needs wallets to operate or something that manages keys on behalf
of the client, right? Cuz you need to demonstrate a proof of possession.
And so given that we have these verifiable credential wallets and they
manage keys for the user anyways, it's so easy now to read and write in a

Dmitri Zagidulin: standardy manner. I see Jesse has hand ups. Go ahead.

Jesse Wright: asking from an LWS hat which is linked web storage…

Dmitri Zagidulin: Yeah. Yeah.

Jesse Wright: which you're I think a part of. Are there requirements that
you have for this specification that you could see as feeding into or being
solved within the scope of LWS?

Dmitri Zagidulin: Great question. So, in fact, it monitor just happens to
have the golden requirements, section up. so we do try to, have a set of
requirements. So, my thought is always with the link web storage working
group at W3C. I mean, I am part of it. I'm always a fan of I'm alum, the
solid project and so on.

Dmitri Zagidulin: I'd love to show this spec and the requirements to the
group, see if they find anything useful, but I don't expect that the group
will be like,…

Jesse Wright: Awesome. I …

Dmitri Zagidulin: yeah, we're just going to adopt it." Right? So, low
expectations, but I'd love for them to take a look at it.

Jesse Wright: I'll take a look for I'll put my hand up. Go. the question I
had on the authorization side…

Manu Sporny: No, please go ahead, Jess.

Dmitri Zagidulin: No. Yeah. Go ahead.

Jesse Wright: because you seem particularly interested in authorization is
in solid LWS we've got a range of authorization specs whack ACL and then
things like access requests and grants which are sometimes done through VCs
and…

Jesse Wright: I understand that Zcaps are a potentially better way of doing
the delegated authorization especially Have you looked outside of existing
web specifications and…

Dmitri Zagidulin: Yeah. I have Yeah,…

Jesse Wright: at how Amazon and Google actually handle authorization on
their systems? I've know Amazon recently gave a talk here on how they're
using formal logic within their authorization capabilities and I'm
interested in learning what they've done and seeing if it has relevance for
us in LWS. So I was interested…

Dmitri Zagidulin: I'd love to.

Jesse Wright: if you had similar learnings here.

Dmitri Zagidulin: I'd love to as well.

Dmitri Zagidulin: I've looked closely at the Amazon Cedar authorization
language and talked to a team that was in fact using dar they literally
embedded chunks of text with Cedar notation into JSON web tokens and they
ended up abandoning that approach.

Jesse Wright: I'll drop a link.

Dmitri Zagidulin: But it was interesting that somebody did it. I'd love to
hear more about what they presented on because maybe they've got a new
project that I haven't heard about. So, yeah, definitely. I'm always on the
lookout for prior art and existing projects. Thank you.

Manu Sporny: Good questions. and yeah, thanks for pointing this spec out,
Dimmitri. I knew about it, but I don't think had ever been able to find
time to click through to take a look at it.

Dmitri Zagidulin: I got noise. Yeah.
00:20:00

Manu Sporny: Okay. So, what I'm hearing is a couple of things. One of them
is we have multiple kind of file storage mechanisms that are kind of out
there today meaning there's the solid stuff there's this wallet attached
storage stuff there's the encrypted data vault stuff and Amazon stuff and
there's a long list right and I

Manu Sporny: I think Dimmitri you're largely focused on at least the ask to
this kind of community group is specifically around the authorization part
of it meaning the Zcap spec I mean they can be other ways to do it right I
mean you can have different authorization mechanisms but ZCAPS specifically
have they're a capability you talk about the resource that you want to give
access to and…

Manu Sporny: then there's some kind of proof of possession of cryptographic
material to get access to that. so I think you're asked to this group is
not to work on wallet attached storage.

Dmitri Zagidulin: Right.

Manu Sporny: That might be a separate thing further down the line…

Dmitri Zagidulin: Right. Yeah.

Manu Sporny: but it's specifically about authorization capabilities and can
we get this spec into shape. I'll note, and just with my dig bazar hat on,
we have a very strong interest in moving the ZCAP spec forward as well. we
haven't done it to date because again, these are open questions, didn't
know where it would land at W3C. it would, I think, be weird for it to land
in the VCWG the same way that it was weird for data integrity to land in
the VCWG. so people might, raise their eyebrows at, a charter to add ZCAPS
there. So we may be talking about a different charter. Maybe it slots in
better with the DID group or maybe there should be a, security protocols,
there is the Singh group now, the security interest group at W3C.

Manu Sporny: so there's a open question around all right, so if we work on
this stuff, where does it land? But clearly that's a bit cart before the
horse. We don't really need to, figure that out right off the bat. maybe
Dimmitri, we can focus on okay, so we get the use case. I think we're, all
on board with the use case. We all want some kind of, open storage,
mechanism with the proper, authorization stuff, built into it. And some of
us believe ZCAPS are a good way of doing that. Jesse, to follow on with,
kind of what Dmitri mentioned, we started working with Amazon a decade ago
on HTTP signatures.

Manu Sporny: for behavior. those people at Amazon since left Amazon.
They've, scattered to the wind and everything, but the thing that they were
trying to really get away from is the whole using tokens for access control
or authorization within their ecosystems. they were having to move massive
numbers of symmetric secrets tokens around and many of the security
failures that their customers were having had to do with effectively not
using capabilities. So HTP signatures was a spec we worked on with them for
the better part of eight years. then Annabelle and Justin took that to IETF
and got that standardized.

Manu Sporny: So that was the lower level part of the ZCAP stuff getting put
in place and then since then we really haven't pushed ZCAPS forward because
there hasn't been anyone really pushing on it.

Manu Sporny: So thank you to Dimmitri for pushing on it and going like you
want to move it forward. we have implemented the ZCAP spec an older version
of it and it is out in production. so there is kind of

Dmitri Zagidulin: And incidentally that's…

Dmitri Zagidulin: what we're using in our current implementation of quality
touch storage.

Dmitri Zagidulin: We're using the digital bazar libraries.

Manu Sporny: Okay.

Manu Sporny: And so I think Demetri there's this expectation that we will
want to upgrade to the latest thing that we believe is the right thing long
term. the only reason or the libraries are in the state that they're in is
we had to ship something, right? And so we ship something u but they're
kind of outdated. we need to upgrade the HTTP signatures part of it and
then we would need to upgrade the digital signatures part of it but that
those are not difficult things to do I think there would be an expectation
that we upgrade…
00:25:00

Manu Sporny: if we take this standard track at W3C so let me stop for a
second and see if that's your expectation as well Okay.

Dmitri Zagidulin: Yes. Yes.

Dmitri Zagidulin: Exactly that. Right. So, basically, go through the spec,
take care of the pending to-dos in there, update the HTTP signature to the
latest RFC, version, and once it gets going, I'd love to talk about
profiling the right so currently the ZCAP spec has a

Dmitri Zagidulin: very particular opinionated profile on…

Dmitri Zagidulin: let's say caveats how to do attenuation right now and I
want to open up that conversation a little bit but yeah that's exactly
everything that you said exactly…

Manu Sporny: Okay.

Dmitri Zagidulin: what you said

Manu Sporny:

Manu Sporny: That sounds good. and then as far as kind of opening up the
design discussion on it, one thing that I think we have found over time is
that and I know this sounds weird coming from me but the link data portion
of it I don't think has had the use that we initially wanted. Right? me
meaning usually authorization capabilities you bring it back to the same
person that issued it to invoke it right and because of that you don't
necessarily need link data you can use it for kind of having formal
semantics around the structure and things like that but we were thinking
probably just going back to doing or a simpler signature mechanism would be
fine

Manu Sporny: and we would probably not need to use link data portions of it
unless somebody comes forward and says that they really found, a strong use
case for the link data bits. we would want to very narrowly profile it, for
interoperability purposes. And I'm sure we'd end up talking about all of
these things.

Manu Sporny: And we'd like to, integrate some lessons learned from Ukanss
and other things like that into the specification. So are those in scope as
well, Dimmitri? Do you feel?

Dmitri Zagidulin: Yes. Yes.

Dmitri Zagidulin: Absolutely. Absolutely.

Manu Sporny: Okay.

Dmitri Zagidulin: I agree with everything that you said about decreasing
lance to something data there and JCS and so on. Yes. Absolutely.

Manu Sporny: All That sounds and then I guess the question is, what form
would you want take? we could take out portions of this call to kind of do
the ZCAP thing. I don't think it was within our initial expected scope, but
again we're in a community group,…

Manu Sporny: so things are very fluid here. or would you rather have a
dedicated call specifically for ZCAPS to move, that stuff forward? what are
your thoughts there?

Dmitri Zagidulin: I'd love to at least start with a topic call for those
that are interested.

Manu Sporny: A separate work item call. So you'd need to kind of work with
the chairs to set that up and then I can set up the call infrastructure for
that.

Dmitri Zagidulin: Sounds good. Yeah. Yeah.

Manu Sporny: And I guess what's the next step there? Just kind of sending
out a poll to the CCG on…

Dmitri Zagidulin: Yeah. I think Yeah.

Manu Sporny: what time would people like to meet.

Dmitri Zagidulin: I think just that of course you're swamped.

Manu Sporny:

Manu Sporny: All Sounds good. and then the expectation, Demetri, is that
you'd take a lead editor role on it. I'm happy to, help out here and there,
but as you know, I'm totally spread thin right now.

Dmitri Zagidulin: Yeah. Yeah.

Manu Sporny: So, All right. I mean, sounds like we've got a, solid set of
next steps for that. you would contact the chairs, get the call set up,…

Manu Sporny: get, …

Dmitri Zagidulin: Excellent. Okay.

Manu Sporny: u opinions when people can and then get that on the CCG
calendar and then just start meeting regularly move that forward. cool.

Dmitri Zagidulin: Excellent. Yep,…

Manu Sporny: Okay,…

Dmitri Zagidulin: that works. Thank you so much.

Manu Sporny: that sounds great. No, thank you Dmitri for picking that spec
up and moving it forward. and…

Manu Sporny: I think the good news is, we've already got an implementation
for it, so we just need another one to get that done.

Dmitri Zagidulin: Exactly. And for those unfamiliar with this spec,…

Manu Sporny: Do you have Just go ahead. Go ahead.

Dmitri Zagidulin: part of the reason that I'm really interested in it and
would love to do some more work on it is there are other capability
specifications and tech out there.
00:30:00

Dmitri Zagidulin: starting from the things we're most familiar with access
tokens, but at the moment there isn't anything that can do multi-layer
delegation aside from Zcaps and UKAMS which are essentially isomorphic.

Dmitri Zagidulin: And I think Zcap's a little better fit for what I'm
looking for anyways than UKAMs. But yeah, and what were you going to say?
I'm sorry.

Manu Sporny: Let's see.

Manu Sporny: It was a question to you. unfortunately, it's totally gone.
no, it's totally fine. yeah, and it's not coming back. Maybe it'll come
back later. go ahead, Phil. And you're muted, Phil, if you're talking. One
second.

Phillip Long: incredible wisdom just passed. I'm sorry I'm a little bit
late. but one of the things I did want to emphasize is that the T3
innovation network and the US chambers are very interested in this as an on
facility that is the wallet attached storage to credential wallets that
businesses might be issuing to their members and in particular its
functionality as serving as a 24 by7 accessible location for making
credential

Phillip Long: requests mediated in some fashion in ways we haven't quite
decided or figured out yet to enable the distribution or the creation of
VPS or other sets of credentials that might be an interest of an employer
in a hiring context without necessarily having the individuals to be online
with their wallet open and…

Dmitri Zagidulin: Thanks, Phil.

Phillip Long: such to deal with it at the time. So it's a very high
priority there. Just wanted to make that point. Thanks,

Manu Sporny: Sounds good. the other set of use cases that Digital Bizarre
is from the retail sector around being able to write data after the fact to
somebody's wallet and asking the person authorizing a right to a wallet

Dmitri Zagidulin: Yes. Yes.

Manu Sporny:

Manu Sporny: hey, you just bought something. we want to write your digital
receipt there but we can't for whatever reason it may happen asynchronously
right

Dmitri Zagidulin: If you don't mind me jumping in. I'm glad you bring that
up. That right there is also one of the very strong use cases for us as for
example, when we were doing an app that does evidence and recommendations
for verifiable credentials. It was exactly as you described. You have a
verifiable credential and then downstream an app needs to write something
to a space controlled by the user. And again, we did the first iteration of
it using Google Drive and was extremely awkward. So we want to iterate, but
that's exactly it.

Dmitri Zagidulin: In fact, what's kind of emerging is wouldn't it be useful
if we had a general purpose notion of an box? Not just like an email inbox
from a person, but each verifiable credential could have an inbox for files
or updated versions or whatever communications about the verifiable
credential after the fact that's using some of this stuff. Yeah.

Manu Sporny: Yeah, exactly. It's a push authorization, and around,
credentials like you wanting you as the issuer of a credential wanting to
get a pre-authorization from the individual that it's okay to push the
credential to their system. but you can't just unlike email it's
pre-authorized and you can shut it off.

Manu Sporny: So if someone starts spamming you, so let's take in the retail
space, let's look at ons. if you authorize someone to dump coupons into
your digital wallet, again, retail use case, and someone starts spamming
you with a bunch of coupons that you don't want because it's an
authorization capability and it's not run like an email inbox, because they
have to have proof of possession to send that in, you can shut them off,
It's a very direct specific capability that you can de authorize them in
the future. so yeah, I mean it's kind of like an authorized inbox for
digital credentials. and the question I forgot Demetri I finally remembered
what are your thoughts on the right mode for a working group?
00:35:00

Manu Sporny: I know that's a year away from now potentially, but
understanding where we think this land I think would be useful.

Manu Sporny: Do you have any thoughts on how we would structure

Dmitri Zagidulin: Yeah. …

Dmitri Zagidulin: it's funny that I was going to come to you and ask the
same question. so my general mental algorithm for this stuff is one come
present it to the CCG, see if anybody's interested as far as both
incubation working group kind of stuff. there's a couple of working groups
that might be interested for example verify credential but you're
absolutely right that adding what is it called to the charter would be
difficult.

Dmitri Zagidulin: There's a in progress charter being chartered for the
next iteration of the social web working group, the group that brought us
activity pub which turned into things like Mastadon. And while Zcap
specifically are not part of the charter, that group has borrowed the
incubation stages from what Wuiji and from the digital credentials working
group which means there's a pathway to be introduced as an incubated item
and eventually making its way into the existing working group there.

Dmitri Zagidulin: So that's Thought number three, as JC mentioned, there is
the linked web storage working group that may or may not be in charter for
it either this iteration or the next. And the other question that I always
have is that was with your ITF, it would be interesting to see if ITF would
be interested in specifically the proof chains, the delegation proofs which
is what majorly differentiates this tech from a plain access token.

Dmitri Zagidulin: So I don't have high hopes that for example the OATH or
any other ITF groups have interest in this but it's worth at least talking
to them.

Manu Sporny: Yeah, I mean those all sound like reasonable options. the
other thing I was wondering is, the authorization spec paired with a
storage spec might be the right kind of a couple of thoughts.

Manu Sporny: So this spec in and of itself, kind of needs driving use cases
on top of it. the whole wallet attached storage thing is a driving use
case. there is not link data platform…

Dmitri Zagidulin: Mhm. Uh-huh.

Manu Sporny: but the solid group as another potential option where you're
kind of like saying hey look we've got a storage mechanism here we can also
standardize authorization mechanisms for that storage mechanism there's
also going back to the verifiable credential working group if we put and I
don't think this is a good idea but as an option if we put things like EDVs
in scope then naturally ZCAPS would also go in scope because EDVs use Zcaps
for all their access control. it's the same kind of thing how data
integrity ended up in that group. and again it kind of worked but it was
super awkward.

Manu Sporny: So I think one of the challenges here in the ITF thing is I
mean what I see happening is that if we've put in ITF ITF will go one path
and…

Manu Sporny: this stuff will go another path meaning there will be a set of
us that are just kind of like we already have a delegation chain signature
mechanism in data integrity and that's what we're using and that's one in
production and so that's just what we're going to do.

Dmitri Zagidulin: right, right,…

Dmitri Zagidulin: right, right?

Manu Sporny: And so the danger there is that we end up with another SD
jot/m verifiable credential complete failure to standardize three different
communities doing three different things effectively.

Dmitri Zagidulin: Right, right, right.

Manu Sporny: So I am a bit bit concerned about that happening again. and I
think the vast majority of the tech stack that we need is there and all we
need to do is do the ZCAP spec. So another alternative is to just have a
very finely tuned finely focused just we're just going to do the ZCAP spec
that's…
00:40:00

Dmitri Zagidulin:

Manu Sporny:

Manu Sporny: what this group's doing. and then the other argument is to,
whatever that group is, why can't we just pull the data integrity stuff
into that group as well? So, it's kind of like a digital signature
authorization, group to basically take the load off of the VCWG, take all
the data integrity stuff off. so one of the things we're contemplating is
the controlled identifier document never should have been in the verifiable
credential working group. It just ended up there because the way we were
splitting things out SIDS, the controlled identifier document really should
probably go to the DID working group like it belongs there more than it
does in the BCWG.

Dmitri Zagidulin: Any question?

Manu Sporny: And then the data integrity stuff that's in the verifiable
credential working group gets moved into another working and that, group
deals with cryptography and signatures. And maybe we can also put the ZCAP
spec into that group. So that group isn't just a single spec working group.
It's working on kind of a bunch of different cryptography related
technologies for, wallet attached storage and things of that nature.

Dmitri Zagidulin: That's a really good point because everything that you
said and specifically the part about maybe this can be housed under data
integrity because 80% of the spec is specifically how to do chainable
proofs which is exactly data integrity. 80% of this Zcap spec. Yeah.

Manu Sporny: Yeah, Yeah. maybe what we should also do, Dimmitri, is just
chat with Simone and see what his thoughts are. lay the options out in
front of him and say as W3C staff. I mean, he would almost certainly be W3C
staff contact.

Dmitri Zagidulin: Uh-huh. Awesome.

Manu Sporny: It's either Simone Pierre Antoine. and Avon's technically
retired although he doesn't seem to be acting like that. Pier Antoine I
think way has way too many groups on his plate and this really feels like
something that Simone might be in charge of because he's a security lead at
W3C. so yeah maybe we should chat with him just start the conversation
super early and say hey what do you think about restructuring things in
this way and then when we may want to have that as a part of the charter
restructuring discussion in August I think we are going to at least put
forward a new did working group charter one or more did methods working
group charters a reshuffleling of the verifiable credential

Manu Sporny: charter where we could potentially move things, out and then a
separate kind of, security technologies,…

Manu Sporny: whatever charter that could pull in ZCAPS and could take over
the data integrity work. granted that's at least four different working
groups, which sounds very painful for many of us.

Dmitri Zagidulin: Right. Absolutely.

Manu Sporny: Worth has a path forward there. anything else that you would
like to cover on this Dimmitri?

Dmitri Zagidulin: Not at the moment. great ideas though.

Manu Sporny: Okay, no problem. and happy to help on any of those if I can.
okay, I think that is it for the call today. are there any other items that
folks wanted to discuss? if not, we can end a bit early. All right. If
there's nothing else, thank you everyone for the great discussion today.
Thank you for the discussion on ZCAPS and, moving that forward. we'll meet
again next week. don't quite know what the agenda might be, but if folks
want to discuss anything particular, just let me know before I send the
agenda out this coming weekend. All right, thanks everyone. Have a
wonderful rest of your week and we will talk again next week. Take care.
Bye.
Meeting ended after 00:44:45 👋

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