[MINUTES] CCG Incubation and Promotion 2025-07-09

CCG Incubation and Promotion Meeting Summary - 2025-07-09

*Topics Covered:*

   1.

   *Community Updates (GDC 25):* High attendance (nearly 2000), significant
   focus on EU-related issues and B2B credential wallets. Discussions around
   ZKPs and their applicability, particularly for mobile driver's licenses,
   were prevalent. Significant global investment in digital identity programs
   was noted.
   2.

   *Incubation Status Update:* Updates were provided on several
   specifications, including quantum-safe crypto suites, VC API, VC wireless
   specification, and ZCAPs.
   3.

   *Credential Refresh Specification:* Discussion centered around the
   location of the refresh service (within the credential itself or advertised
   elsewhere, such as in the DID document). Concerns around privacy and
   accidental leakage of refresh service information were raised. The group
   explored using a separate "entitlement VC" for refresh, reducing the risk
   of accidental sharing of sensitive information, although this adds
   management overhead. The group agreed to document two approaches: a "safe"
   refresh service embedded in a credential (requiring group privacy) and a
   separate refresh credential.
   4.

   *Verifiable Issuers and Verifiers Specification:* The group discussed
   the format and content of the specification, noting that the current
   version is not in Verifiable Credential format and may be overly
   heavyweight. The group considered a minimum viable example focusing on DID
   Web addresses, credential types, and JSON schema. A need to align with
   existing work on issuer registries (e.g., DCC and Credential Engine's
   OIDC-based approach) was identified. The possibility of a more
   decentralized approach, leveraging credentials to assert trust rather than
   a large central list, was also discussed.

*Key Points:*

   - The group aims to improve the Credential Refresh specification by
   clarifying its use and enhancing its privacy features. A separate
   "entitlement VC" for credential refresh was suggested, along with clear
   guidance on secure practices.
   - The Verifiable Issuers and Verifiers specification needs further
   refinement to determine its optimal format and level of detail, focusing on
   a simpler, more scalable model possibly leveraging existing issuer registry
   infrastructure. The group will involve key stakeholders to resolve this.
   - Future discussions will focus on aligning the Verifiable Issuers and
   Verifiers specification with existing issuer registry work and exploring
   the potential for a more decentralized approach.

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

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

Alex Higuera, Dave Longley, Hiroyuki Sano, Jesse Wright, John's Notetaker,
Manu Sporny, Manu Sporny's Presentation, Parth Bhatt, Phillip Long, Ted
Thibodeau Jr, Tom Jones
*Transcript*

Manu Sporny: Hey everyone. let's go ahead and get started. let's see. yeah,
let's go ahead and get started. our agenda today is largely focused on two
work items that we need to push forward. One of them is credential refresh
and the other one is the verifiable issuers and verifiers list. So those
two items are the ones that we are going to be focused on today.

Manu Sporny: let me go ahead and pull up our list of a work items really
quickly. let's Let me See 250 and then we'll do a quick rundown of where we
are on each one of them and then go into the main topics of discussion
today. okay.

Manu Sporny: So, what we have presently before we do that, let's do a quick
kind of round to see if there are any community updates. I think we are
still planning on taking a number of these items into the new charter for
the verifiable credential working group. I know that GDC was last week. I
don't know if any of you were able to attend the global digital
collaboration. but let us know if there are any news out of that. yeah,
Phil, would you mind giving us some kind of takeaways maybe specific to
just some takeaways that you found interesting would be great.

Phillip Long: I think it was actually more people came than they perhaps
expected. I think there was something close to 2,000 that actually ended up
coming from all over the world as you can imagine. obviously a significant
portion of the time was spent on EU related issues whether it's the EUDI
various other attributes of the credentiing environment within the European
Union and the EU European Commission.

Phillip Long: I was surprised not at the percentage of discussions on
businessto business wallets credential wallets that was probably 30% of the
wallet conversations were about that and there surprisingly except in the
unconference second day first day was all presentations in time slots that
were far too many people and far too short of time. but there was very
little in that first day that pertained to the MDL concerns. but although
it was brought up by Kim and several others in some of the sessions in the
second day. and to some extent with little actually Jesse was there too.

Phillip Long: at some extent with little real response other than from the
community that was attending a session on educational credentials and
related things that Kim and Carrie and several others hosted toward the end
of the second day. general takeaways. surprised at the extent of
implementations going on and it looks like things like the did webv
approach is getting some significant attention and particularly in
Singapore.

Phillip Long: And there was a number of talks from the IRA folks
particularly around first person credentials but still that's remains a bit
nebulous to me. Jesse, do you have any other comments? We're talking about
just a summary of the GDC 25 meeting.

Jesse Wright: I was surprised at…

Jesse Wright: how much of a buzzword ZKP was in general. I would need time
to think of a more well thought through summary. I'm not sure what you've
already said.
00:05:00

Phillip Long: That's okay.

Phillip Long: But your comment about ZKP is reinforced. I think that was a
larger conversation than I expected.

Phillip Long: I guess it was coincided with the open sourcing of the Google
implementation as well which was partly prompting that. Back to you man.

Manu Sporny: All right, thanks Phil. yeah, Jesse, we're just trying to get
some highlevel thoughts and feedback from how the global digital
collaboration went. Mostly, what sessions you attended, what you found
interesting, any general themes could see, anything of that nature.

Jesse Wright: general themes. there's still a huge investment in a lot of
digital identity globally. I was shocked at the Swiss government investing
$180 million in their digital ID program for it to be up for referendum I
think today or tomorrow. and if it doesn't pass the referendum, they kind
of just throw everything away.

Jesse Wright: the less generic comments I went to a session on digital
public infrastructure run by the World Bank and they're very heavily
investing in standards for general digital public infrastructure outside of
the scope of credentials specifically. and they're also trying to work out
their procurement plans to get open-source software within governments as
part of their digital public infrastructure. all of this is very high level.

Jesse Wright: I went to the ZK sessions that Hart Montgomery and the Google
researchers were talking about ZKP and there was a discussion around how
applicable a lot of the current solutions

Jesse Wright: so there's for mobile drivers license now so that you have
unlinkability the current solutions back batch issuance for mobile drivers
licenses and there was a discussion of are these ZKP solutions really
useful if a lot of the time they're just being used to handle the
unlinkability problem and some skepticism around ZKP and credentials there
and also the fact that most solutions that are being looked at don't work
with the current hardware security modules.

Jesse Wright: There was a presentation on BBS Sharp which was apparently
meant to be a solution where there is work with the current HSM providers
to get an implementation of BBS sharp out there but it is not quantum
secure for forgery so I don't know if it's going to be useful in the time
frame in which you get HSM providers to buy into this and then get a
solution out there. I'll stop rambling. I need time to collect my thoughts.

Manu Sporny: No, that's all great. those are great thoughts, very
applicable to the work that we're doing here. So, thank you for those. I
know Joe Andrew is going to share some of his thoughts possibly in a
different call, but okay, thanks for the updates. I think because this is
the incubation call we'll go into kind of the status of incubation real
quick. We'll just keep going through this stuff and then we'll dive into
the main agenda which is focusing on credential refresh and the verifiable
issuers and verifiers specs.

Manu Sporny: okay. So, I'm not going to cover the things that we believe
are ready because we believe they're ready. the quantum safe crypto suites,
Jerem and, Andrea did a good presentation yesterday to the CCG. they shared
their implementation of a data integrity crypto suite that does MLDDSA 44
which is one of the postquantum crypto suites. It's what most people are
kind of implementing as the first thing.
00:10:00

Manu Sporny: So they demonstrated that working as a data integrity crypto
suite so that gives us one implementation I believe digital bazaar is
interested in doing a second implementation so that's good we've already
got kind of two implementations the specification is lagging a bit because
we do need to update it to be a bit more kind specific we need to update
the algorithms. We need to pick key identifiers and things like that. So
that needs to happen. VC API is continues. We've got five PRs that we need
to discuss and merge. I think Parth is going to take a shot at doing a
couple of more PRs for the VC API. so thank you for that.

Manu Sporny: parth VPR we need to go in and categorize some of the
loweffort high effort issues but we can do that over the next couple of
weeks. we'll talk a bit about verifiable issuers and verifiers this week.
one of the things that we need to do here is figure out what the minimum
viable kind of verifiable issuer verifier list would be. next item the VC
wireless specification went out for community group review and acceptance.
it's looking good so far.

Manu Sporny: we've got multiple people that want to kind of pull it in and
adopt it and so we'll be working with those folks to try and move this spec
forward. I think Brent who's the chair of the VCWG had a good question
around what's difference between the VC over wireless spec and the open ID
over Bluetooth spec. and we've got some good responses to that that mainly
we support NFC and the Open ID thing doesn't.

Manu Sporny: We in the VC wireless spec support multiple different
protocols including open ID and VC API whereas the open ID spec on focuses
on the open ID stuff and so on and so forth things like that but it's
largely the ability to just stay in NFC and do the entire transmission in
NFC and being protocol agnostic and being able to run multiple protocols
pure

Manu Sporny: early over the Bluetooth channel. so we'll do a kind of
response to that on the mailing list for c we'll talk a bit about
credential refresh during this and then the Zcap stuff. I think we're
waiting for Dimmitri to talk to the chairs and potentially move that stuff
forward. so Zcaps will be discussed there a bit more. okay, I think that's
largely kind of a review of where we are. let's jump into a discussion
around credential refresh. let me go ahead and pull this back up.

Manu Sporny: so for those of you that just to bring everyone up to speed on
the credential refresh specification it is a way of getting a new
credential once your current one has expired. we do this through the
credential in the refresh service property in the So the VC data model has
a property called refresh service and that is supposed to expose how
someone that is holding this could refresh the credential if it expires or
it's getting close to expiring. we have two protocols defined. One of them
is what's called a mediated refresh service. That means that there's some
kind of human interaction required.

Manu Sporny: and then the other one is a verifiable credential res refresh
service which does not require and human interaction. It can be done more
automatically using something like VC API and doing a author or something
of that nature. okay so that's what we have but the general discussion
today is around whether we should have a reach to fresh service at all in a
verifiable credential or whether the issuer of the credential should
advertise the refresh service through another means for example through
their DID document.
00:15:00

Manu Sporny: One way is for the issuer who's expressed here to be able and
if it was a SID they could express something in the service field that says
these are my refresh services and these are the types of credentials I
refresh there and then there'd be some logic that you'd need to match
against that and do the refresh that way. So that is the current kind of
alternate proposal potentially. so yeah let's open it up to discussion. I
does the path where we just continue to use the refresh service in the
credential is that still a viable path forward?

Manu Sporny: do we have mediated and automatic refresh? those are two
different protocols that we have? or do we want to move this out? there's
another option of issuing another credential that's a refresh credential
itself that goes along with this credential. and then there's kind of a
protocol like being able to expose a service through the DID document that
tells you how to refresh the document. go ahead Dave. You're on the queue.

Dave Longley: So, I put a couple of things in the chat. three items that I
think we need to get sorted ideally before this moves into working group.
the first is I'll do this in reverse order since I want to be responsive to
your question. I do think there's still a very good use case for having a
VC that essentially functions as an entitlement that you can use in
conjunction with a refresh service. So, because you hold this VC and it
could be a revocable VC. you can use it to present to get something else
refreshed either the VC itself or something else.

Dave Longley: I would say pro we should probably update the specs such that
that's the general pattern that you don't just attach a refresh service to
any VC that you intend to share with a third party but rather you include
an additional VC that allows for refreshing and that refresh VC is not
intended to be shared with another party unless it's the party that's going
to be doing the refreshing. I think that should be the general flow. we
might even want to warn against doing the other flow, which is just
attaching a refresh service to something and say that's not the way you
should do it. Of course, there's no way we could stop someone from doing
it, but we should probably speak against that as being and say what the
possible problems are. And those are related to accidentally leaking a
refresh service that isn't otherwise a protected or giving a refresh
service information over to a verifier and then they end up contacting an
issuer.

Dave Longley: So we don't want either one of those things to happen and so
we should probably talk about that and we should talk about how the
appropriate pattern is instead to issue this entitlement VC that entitles
you to refresh some other set of things during which you might also receive
a new refresh VC so you can do it again later. so that's my response to the
original question. the other thing we should look at is there have since
been invented interaction protocols and other mechanisms for
differentiating or expressing whether or not the refresh mechanism is
mediated or automatic or whatever it is and we should be leveraging that
going forward instead of having multiple different types to express that
information in the refresh VC.

Dave Longley: So if we look at for example in the VC API there's an
interaction protocol URL and that URL could be used here in the refresh
service to allow you to fetch protocol information that would give you
options for how to do your refresh. And once you have those options then
you would interact with for example a VC API system that would give you a
VPR that says what you need to do to be able to actually refresh. And that
might include sending your entitlement VC or sending other VCs or whatever
it is that service wants to do. It could also include redirecting you to a
website for some other process. And so I think we should be better
leveraging that in instead of trying to break it up into multiple types
that we put in here. so I think that's actually a simplification that we
can do to the spec. So we should do that.
00:20:00

Dave Longley: I think we should talk about making these separate
entitlement VCs and that solves some of the privacy concerns and I think
it's just a better pattern. and I think that covers the three points I
talked about that I typed in the chat.

Manu Sporny: All right, that sounds good. So the concrete changes would be
to just make the refresh protocol effectively point to an interaction L. Is
that right? And then you bootstrap into whatever protocol you support to do
the refresh. And at that point, you don't really care if that's leaked to a
verifier.

Manu Sporny: I mean you care a little bit but not a tremendous amount.

Dave Longley: So I yeah,…

Dave Longley: I think it's less of a problem, but I think we should still
care and we should also include a section. We haven't been doing these
sections yet in VC work or we've done it a little bit, but I think it would
be good to start having sections that give advice to digital wallets about
providing common sense protections. if a site is requested VCs, a digital
wallet should prevent you or warn strongly against sharing a VC that is
just one of these entitlement refresh things. In general, that's not
something that should be requested in a usual, I want to know what your age
is or I want to know on this page here whether or not you have a bach
bachelor's degree.

Dave Longley: presenting a VC that has a refresh service in it should be
something that a digital wallet is like hey you're not doing the right
thing that refresh VC is only supposed to go to the issuer so that you can
refresh your VCs so I think there's also some additional guidance around
that and if we've also set up the spec to separate these things out as
these separate sort of entitlement VCs that also would flow naturally

Manu Sporny: So I'm trying to figure out if we keep the refresh service in
here or if we're basically saying that's an anti-attern.

Manu Sporny: The concern I have about the separate VC is that …

Dave Longley: When you …

Manu Sporny: how is that different from an oath token? and shouldn't we be
just doing that instead? I think that's one of the challenges there.

Dave Longley: an oath token doesn't necessarily give you any information
about what it is for. I should be more clear. It's opaque to the holder of
that token. It is considered opaque. And having an entitlement VC that can
describe be as rich or as not rich as you would prefer about what that
thing entitles you to get is useful and can be displayed in digital wallets
and has additional utility. just having that token and that token does
something but you don't know what it is.

Dave Longley: it doesn't really meet the third party model requirements of
having useful information or at least knowing binding it to some other
bundle of VCs or something along those lines. And so having this
entitlement VC can be more useful than just Having an OOTH token also
implies a very specific protocol that you're going to be using OOTH. And
that might not be how you go about doing your refresh. This could be an
entitlement that gives you an interaction protocol and you might show up at
a website that does whatever protocol you want and there's no strong
binding to O. that allows for any protocol in the future to happen without
having to revise this whole layer.

Manu Sporny: Yeah, I guess the challenge is the management overhead. So,
you're potentially doubling the number of credentials that a wallet has to
manage. because for every longived credential, you have another long lived
refresh credential that kind of lives elsewhere or has to be paired to that
thing. You see what I'm saying? we'd have to have some kind of mechanism
that allows you to identify kind of which credential the entitlement one is
associated with and…

Dave Longley: Yeah,…

Manu Sporny: I guess you have to also get rid of do you see what I'm saying
there's a big management kind of overhead But Mhm.

Dave Longley: there is additional management there. I'll point out that the
refresh credential could also be used to refresh some other types of
digital objects that aren't necessarily VCs such as Zcaps. So, you could
hold one of these and use it to get new Zcaps, which are completely
different digital objects. we could speak to and we could very clearly talk
about when it's okay to attach a refresh service to an existing VC. but
that's a careful line we need to walk because it might make it challenging
for digital wallets to do this sort of warning thing that we would prefer
them to be able to do.
00:25:00

Dave Longley: the trade-off being the additional management as we were
talking about but certain the case where you had just have an interaction
URL that doesn't contain any PII and can't be used to do anything unless
you also have whatever that interaction is going to require of the party
that's going to do the refresh seems to me to be a safe thing to do.
provided that there's strong guidance that there's group privacy and
whatever the URL is so it's not uniquely identifying and things of that
nature.

Manu Sporny: Go ahead,…

Manu Sporny: Phil.

Phillip Long: Yeah, I may be naive about this,…

Phillip Long: but as far as I understand, the only organization and entity
that can do the refresh is the issuer. unless that's somehow delegated in
some fashion to someplace else, which doesn't seem to make sense to me. And
if that's true, then the mechanism by which the issuer wishes to do it,
shouldn't that be the issuer's choice to tell the individual holder in
their wallet the preferred method that they have for doing that refresh and
where to go to get it done.

Phillip Long: And that speaks to the method I think you were talking about
earlier Manu about simply having it included as a service listing in the
credential itself not the refresh service as you described it…

Phillip Long: but rather associated with the issuer.

Manu Sporny: Yeah, I think it's always the choice of the issuer,… What the
issuer wants to do. I think what Dave's saying is that there's some
approaches that are from a privacy standpoint more privacy preserving than
others. meaning if we and I'm just going to use an extreme argument, but
I'm going to make the extreme argument.

Manu Sporny:

Manu Sporny: One of them is we say people should never use the refresh
service, Because it's too easy to get it wrong or we're concerned that some
issuers might get it wrong. and so what issuers should be doing is issuing
a credential telling people how to refresh any set of credentials. that
they've handed over to a holder, So one of them is let's ban refresh
service. It's too easy to get it wrong. let's only depend on this other
credential that is a kind of a refresh instructions credential for a
particular issuer.

Manu Sporny: So when you go and you get a credential issued by an issuer,
let's say a university and it's like u a workforce or it's like an
education credential you took a class and they want us for whatever reason
set a timeline on when that expires and when you might get a new one or
when even you could check for a new one meaning branding information has
been updated or whatever. what the issuer would do in that case is they
would issue two things to you. They would issue the credential itself which
would have no refresh information in it and they would separately issue a
credential that states how to refresh any set of credentials that you get
from the issuer.

Manu Sporny: So they're completely separated. when the individual goes to
present their education certificate or credential they don't send any of
the credential refresh information over with it if they're not selectively
disclosing it. and then there we have a very clean separation. It is always
Phil it's always the credential issuers's choice on what mechanism they use.

Phillip Long: Right. That has the overhead problem that you just described.

Manu Sporny: we just only provide one mechanism that we're sure is going to
be privacy preserving in every single instance as an example, the other
that's right. And so how can we address the overhead problem because now
for every credential you issue that's refreshable you issue a separate
credential and the wallets now have to have extra logic in them on managing
one versus the other or we could say that the issuer issues will have every
single type of credential that the issuer issues and
00:30:00

Phillip Long: right.

Manu Sporny: every single endpoint and it will be just managed by the
wallet software so that it knows all the different types of credentials and…

Manu Sporny: and issuer might issue and the refresh services and all that
kind of stuff that come along with it. Mhm.

Phillip Long: This seems to ignore the circumstances…

Phillip Long: where there might be credentials that have multiple
endorsements to them. And those also have to then have a refresh associated
with their endorsement credential? I mean it seems to exponentially kind of
in add confusion and o and challenge to that to the ecosystem to have the
concept of even endorsements taken up…

Phillip Long: because of the overhead that implies just expired.

Manu Sporny: Yeah. …

Manu Sporny: I mean, I think the fundamental question does the issuer
support refreshing or not? And in the case of a endorsement credential,
maybe they don't. but then again,…

Phillip Long: Yeah. Right.

Manu Sporny: yeah, but then again, it's kind of like if that's the case,
then once the base credential expires and is refreshed, you lose all of
your endorsements. potentially.

Phillip Long: And in a professional context, if it is an expiry associated
with a license, for example,…

Manu Sporny: Mhm.

Phillip Long: you're not necessarily saying, you want that refresh to be
something that's in some it can be automatic. You don't want if you've done
all the work to get your credentiing for your nursing degree and you've
done all your CMEs to keep up to date, you don't want to have it all of a
sudden expire and throw away all that stuff and get a whole new one.

Phillip Long: That is requiring you to submit a credential refresh with a
token that goes with it.

Manu Sporny: Mhm. …

Manu Sporny: So, let's talk about the other thing that came up was when is
it safe to use a refresh service? And I think what we're saying it's safe
to use a refresh service embedded in the credential. if you don't include
any PII in it. So the refresh endpoint has to have some level of group
privacy to it. It must not uniquely identify the individual. and I think
the expectation is that it's an interaction It's got good group privacy.
When you interact with the interaction it gives you a number of protocols.

Manu Sporny: you use one of the protocols for example VC API and the
exchange itself will say I need you to present your university degree
credential as a starting point and then you'd present it and then you go
through the series of steps maybe it's all automatic and then you'd get a
refresh credential at the end of it that would replace your current
credential. So Longley, is that the safe use case you were thinking of

Dave Longley: Yeah, I believe so. the other comment I wanted to make is
some of these discussions we will and should have in a larger working
group. So I just want to remind everyone that what we're looking for here
is to get this incubated spec into a good shape to get into that working
group. So I think there we're going to get wider review and input on these
approaches once we get it in there.

Dave Longley: And so I think the main goal here is to set it up so that
those conversations can be easier so that the options are avail available
in front of people in the working group.

Manu Sporny: Yep.

Manu Sporny: Okay. So, we're talking about documenting two options in the
spec. one of them is the safe type of refresh service along with warning
language to ensure that there's good group privacy on the refresh and then
maybe an example of how you'd execute the refresh service with the
interaction in a safe way. And at that point, it doesn't matter if you hand
that thing over to a verifier knows that it's refreshable, but can't
actually do the refresh because it requires authentication of some kind. go
ahead, Dave.
00:35:00

Dave Longley: And I think in order to do to allow wallets to implement the
check to make sure you're not handing over a refresh service like an
entitlement VC that's intended to be a refresh VC. We should have a refresh
VC type of some kind. So clearly we should be using and we can instruct
digital walts to look for that type as opposed to look for whether or not
refresh service appears and that would give the two different options. So
either you've provided a wholly separate BC that's never intended to go to
any verifier because it is your entitlement for refreshing some set of
digital objects and then there's a separate thing which is you can attach
this refresh service to an existing credential but it has to meet all those
privacy requirements and…

Dave Longley: it doesn't matter if you share it with somebody else because
they won't be able to use it to do refresh or to track you.

Manu Sporny: I was almost tracking you.

Manu Sporny: You're saying Right. Yeah.

Dave Longley: So I'm trying to cover the case…

Dave Longley: where someone might accidentally share a credential that
includes the refresh service information in it. And if we clearly separate
and we have credentials that sort of on privacy preserving refresh service
properties and then we have separate credentials that are themselves
refresh credentials, then a digital wallet can tell the difference. A
refresh credential should never be shared with a third party unless you're
talking to the issuer to actually refresh something because that is your
entitlement.

Dave Longley: If you have a credential that has the refresh service bolted
onto it in this other model where we're trying to solve for the overhead
case that the refresh service needs to be privacy preserving and have all
these other properties in it.

Dave Longley: But it is sharable with a third party maybe with a warning
instead of an error. do you really want to be sharing this refresh service
proper?

Manu Sporny: Mhm.

Dave Longley: I don't know that there is a use case where it needs to be
shared. But if you didn't have selective disclosure, it should not be a
privacy problem. Does that track or not? Yeah.

Manu Sporny:

Manu Sporny: I think so. You're saying the refresh service you're saying
that there's going to be a refresh service. Sorry, it's some refresh.

Dave Longley: If we use the example that's on the page.

Manu Sporny: It's a refresh credential. Yeah. Yep.

Dave Longley: Yeah. So the example on the page is the on case.

Dave Longley: The new case that we need to better document in the spec is
the type of credential will be a That refresh credential of some kind
should never be shared with a third party. That isn't the issue or that
isn't the party that's going to do the refresh.

Manu Sporny: Yep.

Dave Longley: And so a digital wallet can strongly prevent that from
happening. One would think Yeah,…

Manu Sporny: And that other refresh credential thing might contain because
one thing we haven't talked about is what happens when a refresh triggers
the creation of multiple credentials, me meaning that you might be looking
at you might end up it's a true age is one example of this…

Dave Longley: that the

Manu Sporny: where when you refresh you actually get five or six
credentials sent back to you. you don't just get one.

Manu Sporny: Mhm.

Dave Longley: And this refresh VC can include information that's specific
to…

Dave Longley: what the person is entitled to get which would be considered
tracking information but digital wallet should look at that type of VC and
say you you should not be sharing this with any party other than the one
that you're going to do the refresh with. And so those same privacy
concerns or the privacy concerns are not the same in the two different
places, but there is a very clear distinction between the two that digital
wallets can use to help make sure users are doing…

Dave Longley: what it is they're supposed to be doing.

Manu Sporny: All right.

Manu Sporny: All right. So changes that we would end up making in the
refresh data model section we are going to keep the refresh service thing
but we're going to reduce the protocol sections to effectively just use an
interaction URL that has good group privacy characteristics and then we're
going to defer the entirety of the proc process to VC API. That's the first
kind of change made. So media ref Verifiable credential refresh service
2021 goes away and it's just replaced with interaction URL stuff. So that's
the first thing.
00:40:00

Manu Sporny: The second thing is we're going to add a section in the
refresh data model. that is going to add this new refresh credential type.
we'll need to figure out what the data model for it looks like. But I'm
presuming that it is going to at a minimum specify who the issuer is and
then the types of credentials the issuer will refresh. and then maybe a
specific type of credential identifier that refresh service is associated
with that one I'm a bit unsure of.

Manu Sporny: Go ahead, Phil. We're talking about the refresh credential
itself.

Phillip Long: No, I just said that it's fuzzy to me as well.

Phillip Long: And I'm still not clear if that method is just the one that
requires the separate refresh credential to accompany it. So that's very
okay.

Manu Sporny: Yeah. Yeah. So, we're saying, we're not talking about this use
case. We're talking about something that's not on the screen,…

Phillip Long: Right. Yeah.

Manu Sporny: which there will be a refresh credential. It will be issued by
a certain issuer and…

Phillip Long: Yeah. From that issue. Mhm.

Manu Sporny: it will list here are all the credentials that I can refresh.
for you. gen in a general way right meaning what the wallet's logic would
be is it would say all right this credential is going to expire soon it is
of this type issued by this issuer do I have a refresh credential in my
wallet issued by that issuer saying that they have a refresh service for
this type of credential…

Phillip Long: Yeah. Heat.

Manu Sporny: if so I can run the refresh protocol all there. Dave, was that
ma matching…

Manu Sporny: what you would expect the logic to be in the wallet.

Dave Longley: Yeah, I think there will be some more discussion on…

Dave Longley: whether or not we can simplify that further, but that's more
or less correct. that's…

Manu Sporny: Okay.

Dave Longley: what I was expecting.

Manu Sporny: Sounds good. All right. so let's see. So, we'll go ahead and
add that and then just we'll check again. We'll look at it again once those
changes have been added to this one. okay, that gives us a good clear path
forward. Thank you everyone for the discussion. We'll get that kind of
updated and then once we get that stuff in, we'll review again. okay.

Manu Sporny: In the remaining 10ish minutes left, the other spec that we
need to talk about is the verifiable issuers and verifiers specification.
David did write back and said that they are planning on updating the
examples in here. so that's specifically this example which is just a data
model. It's not expressed as a verifiable credential. we're going to have
to figure out some way of, aligning this.

Manu Sporny: I think one of the challenges with the European trust model
stuff is that it tells you kind of what the trust model is based off of,
but it's not clear what the algorithms you run on this are to figure out
whether or not the credential that you have is trustworthy or not, right?
for example it doesn't tell you the type of credential that any one of
these issuers issue. It just says how they can be identified and what
certifications they went through. I guess no sorry it's here service issued
credential types. So we do have that.

Manu Sporny: So, the other concern I guess here is one, it's not in
verifiable credential format, so we're going to have to do that. two, it
might be way more heavyweight than what you'd need for a minimum list. So,
for example, let's say that you're interested in an organization in a list
that basically just lists a whole bunch of kind of did web addresses and
says these are the types of credentials that we trust them to issue. and
then maybe even have a JSON schema associated with each of those credential
types.
00:45:00

Manu Sporny: So that's the kind of viable examples. So there's a question
around minimum viable example. and do we also cover that in here? I don't
see we don't know if there's any guidance here on do you need all of this
information or not in this verifiable issuers verifiers list. All right.
So, let's kind of open it up to kind of discussion on this.

Manu Sporny: I think yeah thoughts on this from anyone

Dave Longley: Yeah,

Phillip Long: I'm just trying to decor issuer registry approach …

Phillip Long: where for example the dcc and credential engine just spent
the last six months or so looking at whether and how an issuer verifier
registry should be constructed and…

Phillip Long: what approach to take to do that for institutions at least
and the governance around all of those things etc. Is this list approach an
alternative to that with infrastructure?

Manu Sporny: hopefully not an alternative.

Manu Sporny: I think we want to reuse that infrastructure and that's what
we're looking for is because right now, that we know of, there are no
implementers of this. I know David and…

Manu Sporny: Isaac, are proposing this and it's aligned with some stuff
happening in the EU, but we don't know who's going to implement it. We
don't know, and so if there's existing work in the space, we want to
leverage that instead of reinventing that. So I think what we would need is
more information on what that issuer registry thing looks like.

Phillip Long: Right. Right.

Phillip Long: There they came to the decision and recommended and have
begun pilot implementations.

Phillip Long: they being DCC and credential engine for essentially an OIDC
based approach to issue a verifier registry and…

Phillip Long: I'll dig up the specification in the document and send it and…

Manu Sporny: All right.

Manu Sporny: That would be good know about I think we need to reconcile
that before we push this, specification into the PCWG.

Phillip Long: it is heavyweight because Hawai is heavyweight I Yep.

Manu Sporny: Yeah, we were looking for something lighterw weight where it's
just, a list of did webs and a list of credentials and JSON schema and
that's it. Okay.

Phillip Long: We So are we. But that's what they ended up with.

Manu Sporny: Go ahead Dave.

Phillip Long: right. Thank you.

Dave Longley: Yeah, my thanks.

Dave Longley: My comment is a little bit related to the formatting here and
you were saying might need to be redone. I'm wondering and I don't remember
exactly last time David presented this. I'm wondering if this is a
translation of an existing format. if all of this JSON here is exactly what
other people are already using, then I would recommend that we just try and
reuse this information. there are some advantages and disadvantages to that
approach. but if this is already a workable format and is already in use,
then the VC that expresses it should probably just call that out and then
just reuse what's there.

Dave Longley: this is sort of like a handcrafted thing that's kind of
matches something that's in some other format. whether it's expressed in I
don't know whether this uses XML or some ASN.1 type stuff. It kind of looks
like X509 style information, but I'm looking to not there's a lot of stuff
here and either we're going to cut down on it significantly or…

Dave Longley: we should reuse what's there if it's already in use. I don't
want us to have to redesign an entirely new data model that is very similar
to something that's out there. is my main comment.

Manu Sporny: got it.

Manu Sporny: Yeah, I think this is based on an XML format that exists in
the European Union. I think that's where David and Isaac got it from. but
we'll have to, take a look. I'm going to pull up the link that Phil
mentioned on the dcc issue registry stuff. So I think we could probably
chat with them meaning c about some of the decisions that were made here.
is there an example kind of
00:50:00

Alex Higuera: What would you like to know?

Manu Sporny: Hey Alex.

Alex Higuera: Hi, let me check to see.

Manu Sporny: Do we have an example that we could look at to see how
different or similar it is from the current specification?

Alex Higuera: There was a repository we were working out of. and I believe
it's public. Give me a second. I'll pick it up.

Manu Sporny: Okay, I appreciate that. I'm gonna keep looking.

Manu Sporny: Go ahead, Dave.

Dave Longley: Yeah, while we're waiting,…

Dave Longley: I'm wondering what the core use case I mean there are a bunch
of use cases that have been related to SHER and verifier lists that have
come up and I'm wondering how much of this could be made more
decentralized? I'm always imagining these protocols where the issuer in a
VC API protocol would present a credential that says it is part of some
important list that gives it the privilege to ask for some set of
credentials. it's passed some other set of external hoops so that it's
trusted.

Dave Longley: it meets some compliance rules or whatever or being able to
request something or be part of some consortium or whatever it is. and
having that might be cleaner than having a big list where you go look stuff
up. and it also is more flexible in that those rules can change over time
and you just have to be presenting a credential that is ultimately going to
be rooted in some other issuer that does have to be on some list.

Dave Longley: But that list could be much smaller and simpler. I worry that
we're putting everything about that whole process into this list for every
issuer as opposed to there's some root authorities that meet some basic
requirements and that is the only thing that has to be in the list because
everything has changed from there and I'm wondering if that would meet most
of the use cases or not.

Manu Sporny: Yeah, I think there's a larger kind of discussion around that.

Manu Sporny: And Alex, I pulled up the link that you put here. Thank you.
go ahead, Phil.

Phillip Long: Yeah. what you just described, David, is the argument that
IRA is making in which the car labor conversation between IRA and the
issuer registry as a subregistry within the overall IRA global registry is
currently about.

Phillip Long: Alex, you may know more about it than I do, but that's my
understanding.

Manu Sporny: I mean,…

Manu Sporny: as a next step, it sounds like we need to bring So, Alex, I
don't know if you could help us bring folks that worked on Okay,…

Alex Higuera: So, that would be James Chartrand. he developed more of the
backend stuff for this.

Manu Sporny: I know James Yeah.

Alex Higuera: I can let him know.

Phillip Long: approaches. Yeah. Mhm.

Alex Higuera: I maybe encourage him to come to the next meeting or so. I
don't know. We can schedule something.

Manu Sporny: Yeah, that would be good because what I'm concerned about here
is that we've got three potentially different approaches and that means
that I don't know if we're that ready to put this on standards track…

Alex Higuera: Do we have an idea of…

Manu Sporny: so we need to at least get the folks that have built solutions
in the space together so that we can figure out what they were building
for, which use cases they were trying to work towards and that sort of
thing. …

Alex Higuera: what we're going to be talking about next week?

Manu Sporny: we will not have a call next week and we might not have a call
the following no, we will have a call the following week.

Manu Sporny: So, we won't have a call next week, but the week after that, I
think we'll have a call. And Alex, if you want to invite James in.

Manu Sporny: I think that would be a really good use of our time to just
get kind of the technical background on what was, put together. okay.

Alex Higuera: Yeah, sure.

Alex Higuera: No problem.

Manu Sporny: Thanks so much, Alex. yeah. Yeah. And I think the general
issue that we're having here is that, there seems to be this belief that
you absolutely have to have these kind of registries and trusted issuer
lists. when kind of the BC and did approach has been more decentralized
than that. and so there needs to probably be some level kind of alignment
on what use cases do require kind of this list. Should it be more
decentralized?
00:55:00

Manu Sporny: should it be more centralized? and then kind of going from
there. and maybe it's a chance to bring the Arya folks in, Phil, as you
mentioned, to provide their kind of input on this. ultimately we want a
solution that can scale to tens of thousands to 20,000 plus issuers without
having this massively complex centralized single registry because those
things are very difficult to scale and often don't scale even when they're
really good reasons for them to do it for example their passports in the
world they have existed for many many many decades the electronic

Manu Sporny: chips on them have existed for many decades and still today
there is no trusted registry of every single issue of a passport in the
world.

Manu Sporny: There are countries that choose not to participate in that
list. and that is for something as vital as kind of border security and
travel. okay.

Phillip Long: Yeah, that the master list doesn't necessarily need to be
there.

Phillip Long: That I think the notion was that the different communities
would build their own issuer verifier registries for their community. DCC
is building it for their community and therefore there could be nuances and
governance differences from registry to registry.

Manu Sporny: Yeah, agreed. But even in that case for example there are
22,000 first responder agencies in the United States and there is no
central list of agencies right there's no one to pick up the ball there
right so…

Phillip Long: The ball. Yeah. Yep.

Manu Sporny: what do we do in those cases okay we'll make that the focus of
our next call in two weeks Alex I'll try to start a thread with you and
James to make sure that we can James and anyone else from, GCC to come in
and provide their perspective on that.

Alex Higuera: Yeah, we did also have a contractor, Rob Schwarz, who helped
with the architecture. I can reach out to him, too.

Manu Sporny: Wonderful. Thank you. okay, that's our call for today. I
really appreciate everyone's time and attention to all of these
specifications and discussions. we will not have We will have a call the
following week where we will talk about the trust registries issuer lists
stuff. Thank you everyone. Have a wonderful rest of your week. We'll chat
again in two weeks. Bye.
Meeting ended after 00:58:07 👋

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