[MINUTES] CCG Incubation and Promotion 2025-05-21

CCG Incubation and Promotion Meeting Summary - 2025/05/21

*Topics Covered:*

   1.

   *Review of Specifications for VCWG Transition:* The meeting focused on
   reviewing the status of various specifications proposed for transition to
   the Verifiable Credentials Working Group (VCWG). This included identifying
   lead editors and outlining remaining work needed before submission.
   2.

   *Verifiable Issuers and Verifiers:* This spec requires updates to the
   example, which needs to be a valid verifiable credential, and the addition
   of a security and privacy considerations section. David C and Isaac will
   lead the update. The group also discussed whether to include algorithms for
   validation in the specification.
   3.

   *Verifiable Credentials over Wireless:* This spec needs a co-sponsor
   before moving into the CCG.
   4.

   *Confidence Method:* The spec needs clarification on defining what
   raises confidence that a presenting entity is authorized for a subject. The
   group discussed layering: first establish that you are talking to the right
   entity (confidence level), then determine the entity's authority regarding
   the presented subject (policy). Additional issues were created to address a
   proposal for adding DID confirmation and to address a multi-layered
   approach for determining the holder's relationship to the subject.
   5.

   *Credential Refresh:* The existing spec is outdated and requires
   significant updating. The preferred approach is now to model refresh as a
   separate credential ("voucher") that enables the retrieval of refreshed
   credentials, rather than embedding the refresh service within the
   credential itself. This approach allows for flexibility with various
   verification services and protocols and manages validity periods more
   effectively. The group also briefly touched upon managing credential
   bundles to prevent duplicates.

*Key Points:*

   - Several specifications are nearing readiness for transition to the
   VCWG, but require further work (updates, lead editors, etc.).
   - The "Verifiable Issuers and Verifiers" specification needs a
   verifiable credential example and a security/privacy section. Algorithm
   inclusion is under discussion.
   - A co-sponsor is needed for the "Verifiable Credentials over Wireless"
   specification.
   - The "Confidence Method" spec needs clarification on handling multiple
   holders and physical cards.
   - The "Credential Refresh" spec needs a major update to model refresh as
   a separate credential ("voucher"), improving compatibility and flexibility.
   Managing bundles of credentials will also be addressed.

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

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

Alex Higuera, Benjamin Young, Dave Longley, David C, Dmitri Zagidulin,
Hiroyuki Sano, John's Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt,
Phillip Long
*Transcript*

David C: I'm trying to give it to you.

Manu Sporny: All right, we've got enough people to get started. welcome
everyone. This is the credentials community group incubation and promotion
call. it is May 21st, 2025. we do have an agenda today and it is largely to
just review the state of all the specifications that we have discussed over
the past month and a half. there are a lot of them. today we can
specifically focus on the confidence method and the credential refresh
specifications. and then use any remaining time to cover other
specifications that are of interest to everyone. are there any other
updates or changes to the agenda? Anything in particular we should cover
today?

David C: Yeah, Mano, I apologize. we both missed Isaac and I missed last
week's meeting when you discussed the spec the trusted is your spec. So if
you could just spend a couple of minutes at some point in the meeting
telling us what changes you actually need if that's documented anywhere,
what you need us to do because you said there's about a month's work. I
read yeah okay it been nice to have it anyway.

Manu Sporny: Mhm. E.

Manu Sporny: Yep. Yeah. happy to cover that. In fact, maybe we'll cover
that as the first item and then go into confidence method and credential
refresh. It's not a long list, David. It was just, some desired for
alignment and that kind of stuff.

David C: Thank you.

Manu Sporny: All we'll add that to the agenda. Anything else that folks
want to cover today? All right. let's go ahead and get started then. I was
having a hard time tracking all the specifications that we were talking
about. So I created an issue in the CCG. it is issue 250. I will put this
in the chat channel. and this lists every specification that I know of that
we have discussed as being of interest to move into the VCWG. It also
identifies the specifications that we feel are more or less ready to go
into the VCWG.

Manu Sporny: And then it also lists specifications where we have identified
f further work that needs to be done before we say that they're ready to go
into the VCWG. and today we will specifically talk about these two and this
one the verifiable issues and verifiers and then confidence method and
credential refresh. we'll cover those as well. the other thing that I will
mention is that we are looking for lead editors for all of these
specifications. so we can't propose these as things that BCWG is going to
work on and not also have a strong lead for them identified.
00:05:00

Manu Sporny: we have to do that and it's probably has to be a little better
than what ended up happening in the last BCWG iteration. so if you are
interested in being a lead editor on any of these specifications where the
success of the specification will largely depend on you to get it through
the process please I think we'll be asking for kind of volunteers as we go
through these. I will start at the top and just kind of go down review of
the spec and what we might need to do further. so verifiable credential
barcodes is largely ready.

Manu Sporny: this spec is going into production in some pretty big ways and
has a lot of just the base content that's necessary to do interoperable
implementations. We already have some interoperable implementations same
thing for Seabore LD. the specs algorithms could use a bit of work but
largely they are kind of ready to go into a recharger JSONLDD working group
so these are very very mature from both a spec text level and an
implementation level test vectors all that kind of stuff and actual
production experience and deployment.

Manu Sporny: next item up is verifiable credential rendering method. we
said this was ready to go. Patrick St. Louis had one thing he wanted to add
to it, which is the OCA work that he's been involved in. so that basically
means that, we let me bring up the spec so I don't misquote the name. we
have the latest template render method stuff in there. We have the open
attestation embedded renderer stuff in there, and we expect to have an OCA
render mechanism in there as well.

Manu Sporny: so this one I think we feel comfortable enough with it where
we can just put it into the working group and the working group can kind of
figure out some of the more specific details. the ones that we have
reviewed that are not quite ready yet are the quantum safe crypto suites.
this Will here today? No. but has a PR for the Quantum crypto suites.
Unfortunately, we won't be able to meet this this Friday, but we'll next
Friday to try and pick some names that we can use. and then that PR can
probably go in and that just establishes four postquantum crypto suites
that we might implement the standard DIP stuff.

Manu Sporny: So MLDDSA a stateless has SLH DSA Falcon we're just presuming
Falcon's going to be standardized by NIST next and then some of the SQI
sign stuff which have really tiny signatures compared to all the other
postquantum methods. So we're hoping that one survives the trial phase but
there are four that we've identified. I think everyone feels pretty good
about those four. and we just move forward with those. VC API we're making
good progress on FPRs are being raised. We're identifying loweffort high
effort issues. The high effort issues will probably go into the working
group.

Manu Sporny: the low effort issues or the issues that we want to process
before we get done. That one has quite a bit of work still on it. but it
has a lot of discussion that needs to happen before we put it in the BCWG.
We didn't want to hand the spec over with a whole bunch of issues that we
could close before moving it in there. So there are a lot of loweffort work
that kind of needs to happen there. verifiable presentation request is a
part of that for the query language that we use in VC API.

Manu Sporny: verifiable issuers and verifiers. let's talk about this one
right now, the main thing with verifiable issuers and verifiers, we did a
review of it during the last call. and it wasn't we should remove things
anything of that nature. There were open questions around, are these the
exact names we need to use verbatim or do we have some leeway there? TSP
email. The example in here wasn't, in a verifiable credential form.
00:10:00

Manu Sporny: And so we were wondering that's one of the changes that I
think the group would like to see is to just put this into a verifiable
credential form if possible. we can certainly help with that. But
understanding kind of what a full-blown verifiable credential would look
like for this Etsy trust list and then there was this example down here
which took a different approach from Etsy but had some of the Etsy things
in there as well as some other stuff.

Manu Sporny: So some of this stuff came out of rebooting web of trust and
so we wanted to make sure that there was no disagreement that you'd also
support this style of trust list. though that's largely it didn't have a
security and…

Manu Sporny: privacy consideration section…

David C: Yeah. Yeah.

Manu Sporny: which we'd probably at least want to bullet item out. so
that's largely David. those are the requests for changes.

David C: Do you want me to give you a quick update? I've had a meeting with
Isaac in the last week and first of all, the VC example is wrong. So it
needs completely remove it because it doesn't conform to the data model.
The previous example that you said That's absolutely correct. It's just an
example of the data model and we want to add a security section to say that
the data model can be secured in a numerous different ways. So it could be
secured for example by using X59 certificate and digitally signing it.

David C: It could be secured as a VC or it could be secured by storing the
data model on a web page and then having a VC which references the web page
and as the hash of the web page and as we do now in the VC data model for
referencing external data. So there are number of different ways that the
data model can be secured and we wanted to write that into the security
section. So I hope that answers all your questions…

David C: because as I say the first example was not meant to be a VC. It
was meant to be an example of the data model that was define Just the data
model. Right. Exactly.

Manu Sporny: So this is just the example of the data model.

Manu Sporny: Okay.

David C: And then the VC example is completely wrong because we didn't have
time to update it with the latest data model. That was the older data model
before we rationalized it and made sure we got everything in there.

David C: So that needs completely replacing that section.

David C: Okay. …

Manu Sporny: Yeah, I guess the challenge there would be the complete
replacing.

Manu Sporny: So the Etsy model is fine, but I think some of us are wanting
to deploy something other than the Etsy model. and want to make sure that
or, we can try to see if the Etsy model applies, but the Etsy model seems
pretty heavyweight. and that's kind of the Mhm.

David C: it's yeah I mean the thing is what we didn't say in the data model
what are the mandatory and optional fields and…

Manu Sporny: Mhm.

David C: and so that is something that when it goes to the wider group can
be done.

David C: this feels optional, this is mandatory. but we didn't think that
we would be in a position to make those statements now given it's not gone
out to a wide enough audience.

Manu Sporny: Mhm. Mhm.

David C: Yeah. what else can I say? the Etsy model is actually more
complex. We've simplified the Etsy model. one of the things we've removed
and people might want to actually put back is historical data. So, the Etsy
model allows you to have the current trusted list, but also all previous
trusted lists that have been made since the trusted issuer started running.

David C: So you could actually look up what was trusted at the time my old
verifiable credential was signed,…
00:15:00

David C: six months ago. What was a trusted list that was valid then? Yeah.
And we haven't put them…

Manu Sporny: Mhm. Okay.

David C: because that complicates the data model even more. But we
recognize that some people might want that feature. So yeah.

Manu Sporny:

Manu Sporny: All So I guess the question is we need to update the example
at the very least to make sure that we can express it as a verifiable
credential…

David C: Yeah. Yeah.

Manu Sporny: because that's…

David C: Yeah. Yeah. Yes.

Manu Sporny: that's the group it's going into. I don't know if we can say
anything with any amount of authority on anything that's not a verifiable
credential the whole secured with X509 or I'm a bit hesitant to I know we
can say things with authority on how this is expressed as a verifiable
credential. I don't know if we I'm fairly certain we can't say anything
with authority on

Manu Sporny: this is how you would realize it as unless you're saying this
is an X509 certificate that's signing the verifiable credential. if that
makes sense.

David C: Yeah.

David C: I mean, the thing is it could be a JWT either. So, if you take the
VC data model as an example, the VC data model does the data model and then
the security and…

David C: the securing of it is actually done in separate specifications,
isn't it? we've got the data integrity specs and we've got the JWT spec.

Manu Sporny: …

David C: Yeah exa exactly exactly yeah so yeah so the data model is the
important thing…

Manu Sporny: you're saying it would be constructed as a verifiable
credential, but then you could put it into a different securing envelope.
that can be done as in a separate spec. Yeah, that certainly we could do.
Yep.

David C: because you need to know what the information is that is
specifying the trusted list and then how that's secured is a secondary
issue. Yeah. Yes,…

Manu Sporny: All right. So, I guess the other question is, presumption is
that you and Isaac are going to be lead editors on this in the VCWG.

David C: that would be my assumption. I haven't actually specifically and…

Manu Sporny: And Okay.

David C: explicitly said that to Isaac, but my assumption is he will want
to do that.

Manu Sporny: And then I guess the other question is around implementations.

Manu Sporny: A test suite and implementation. Would you two be doing the
implementation in the test suites or do we have implementers already?

David C: Right.

David C: So, Isaac's got an implementation. and the World Health
Organization have an implementation. but the future funding of the World
Health Organization is up to question at the moment because as you know a
large chunk of funding has been removed from it. So they're currently
looking for funding but within frownhoffer he's got funding. Now myself we
implemented it in our system verified credentials limited before we taken
over but the company that took over my company's gone bust.

David C: so that implementation is not available anymore, but we did
implement the Etsy model prior. So, it's not difficult actually because the
fortunate thing is that frownhoffer have an API. So they have the data
model stored in the DNS in different parts of the DNS and they have a
pointers from the DNS to web pages where it's stored and they've got an
API. So for anybody who wants to implement it, it's quite easy because you
can call their API and they return information to you.

Manu Sporny: Yeah, I guess the question I guess yeah, I mean this might be
an much easier thing because I mean it's a data model and…

Manu Sporny: it's a verifiable credential and therefore any verifiable
credential issuing platform should be able to issue this thing,…

David C: Yeah. Yeah.

Manu Sporny: so I'm wondering I guess the complexity would come in if you
were trying to apply this list when you're validating a credential. And I
guess that was the other question that came up is are we going to have
algorithms in here on How you use the list to do validation?

David C: That's a good point…

David C: because what we did we actually trusted the API from frownhoffer.
00:20:00

David C: So we called it and we asked it is this issuer in the list of
trusted issuers effectively.

Manu Sporny: Mhm.

David C: And then we get an answer back. So we just trusted that
implementation to be solid.

David C: But you're right the algorithm for doing that could be documented.
All right.

Manu Sporny: Yeah. …

Manu Sporny: so the danger in documenting the algorithm in the spec is if
we document the algorithm normatively, we have to demonstrate that people
have implemented the algorithm. So it would turn the spec from it's just a
data model. We can easily get multiple implementations of it to these
implementations have to actually implement the algorithm for the
specification to survive the standardization phase.

David C: No, we don't want to do that because there's probably different
ways of implementing it.

Manu Sporny: It may be something that people ask us to do anyway. We should
just be aware of that going into it,…

David C: Yeah. Yeah. Yeah. Yeah.

Manu Sporny: just to be clear, Digital Bizarre have an interest in this
specification because of the work that we're doing with first responders.
There are 22,000 first responder agencies in the United States and they're
all independent largely and…

Manu Sporny: they all want to issue verifiable credentials and that is one
massive verifiable issuer list. right u just so we would be interested in
implementing some variation of it.

David C: Exa. Exactly.

David C: That's exactly why you need this type of specification.

Manu Sporny: But that of course may be somewhat opinionated in…

Manu Sporny: and I don't so I think what we need to do is figure out if the
data model can work.

David C: I think it would be very helpful…

David C: if you actually said which of the fields are mandatory which are
optional.

Manu Sporny: Yeah. Yeah.

David C: Because you've got a real life use case with your responders and
the absolute core minimum that they need to know. they probably don't need
the postal address and…

David C: the phone number and all this other stuff that's in there. Yeah.

Manu Sporny: Right. Yep.

David C: and their registration number with I don't know what the
equivalent in America is but company's house in the UK that registers
limited companies you've got equivalent in each state that information can
be in there as well so you're actually finding out information about the
trusted issuer right

Manu Sporny: Yep. Yep.

David C: but you may say that's all optional we don't need

Manu Sporny:

Manu Sporny: Yep. Okay. All that's work to do. I mean, ideally, we would
have had done, this work at this point before handing it over to the group.

Manu Sporny: Let's make this concrete. So, I think the only thing, David,
that we would need is the verifiable credential example updated because
that will just establish this is the baseline. This is what we're trying to
do. We know we can get multiple implementations for and then having a
couple of security and privacy considerations bullet points at the bottom
just to make sure that,…

David C: Okay,…

Manu Sporny: they know we've thought about it. That'll come up in the first
public working draft review of the specification. okay.

David C: Good.

Manu Sporny: All right. that feels like a, clean and it again doesn't feel
like more than a month of work to get that into shape. yeah,…

David C: No, I'm sure it's just getting Isaac and I together when we both
got free time as it were at the same time. Yeah. Okay.

Manu Sporny: yep, yep, yep. Okay. of course.

David C: Thank you very much for your time.

David C: That's really helpful.

Manu Sporny: No, thank you David and…

David C: Yeah. Yeah.

Manu Sporny: you and Isaac for working on that and being leads on that.
let's see. Going down the list, we have the verifiable credentials over
wireless specification. Right now, it's just a digital bazaar spec. we need
a co-sponsor on this to pull it into the CCG. So if anybody is interested
in, being able to tap to transfer credentials using mobile phones, NFC
specifically, please let us know. we can't move it into the CCG without a
co-sponsor.

Manu Sporny: let me ask would anyone on this call be willing to sponsor
this with us, the wireless spec? Okay, we'll go out to the list and see if
there's somebody else that wants to sponsor this with us. let's see. Okay,
let's talk about confidence method and what we need to do for the
confidence method specification was initially created during the VCWG work.
I don't think Oliver's interested in working on it anymore. go ahead Dave.
00:25:00

Dave Longley: I just you might have been getting to this.

Dave Longley: I want to make a comment. I believe Ryan Richtor signed up to
be co-editor on this. There might be a PR that was just not ever merged
that says that.

Manu Sporny: Okay.

Manu Sporny: Nope. No PR. yeah. okay. I mean, know. I'll try to reach out
to Brian and see if he wants to take it over. basically this specification
came about because there were a class of verifiable credentials where
people wanted to associate a cryptographic key with it a hardwarebound
cryptographic key with it without binding the subject to a decentralized
identifier.

Manu Sporny: So to be specific for the credential subject they wanted to
leave it blank because there's a class of and this kind of comes from the
MDL world in the MDL world they model the card itself not a subject or
individual rather the subject is the card it is not the person in they bind
hardware key material to the hard again, not the person when it's really
the person that has the phone is doing the work there. And so these cards,
can have key information associated with them. that has nothing to do with
the did subject or even the u and it's not the subject of the credential.

Manu Sporny: it's just associated information. So there is not a lot in
this specification right no background no terminology there is a definition
of what confidence method is and we need some updates on we need to update
this a little bit there's an example of its usage here so this is how you
can get confidence that the subject is who you think it is. so this is a
verification key confirmation.

Manu Sporny: It just lists a public key. And what you would do is during
some kind of presentation in whatever protocol you're using, you would
verify that the credential subject is in control of that public key through
some kind of challenge response protocol and that's it. So, for example,
this is like a bachelor of science and arts degree. if you wanted to make
or I guess this is an individual that has a degree, if you want to make
sure that the individual who has this degree can prove that this is in fact
their information, you would use the confidence method to verify that. go
ahead Dave.

Dave Longley: Yeah, this mechanism also supports potentially having
multiple holders of the same credential. The confidence method property
appears on the particular subject somewhere nested within the credential
for the subject that you're interested in getting more confidence that the
presenter that is in control of whatever competence method is associated
with that subject. So you could have a credential that has a birth
certificate that has two parents and a child. Each parent might have their
own different confidence method or…

Dave Longley: even lists of confidence methods allowing them to hold the
same credential with and be able to present it from multiple different
devices and that sort of thing.

Manu Sporny: Yep. David,…

Manu Sporny: you're on the queue.

David C: Yeah, I had a slightly different take on this. we had a big
meeting where this was discussed and I had an alternative proposal, but
there was not enough time at that meeting to discuss it. But I did quite a
lot of work on how do you know how the holder is related to the subject?
and I had a whole presentation on it and it's related to confidence method
but it's slightly orthogonal because it's looking at this entity is it I
don't know who he is this holder but he's giving me this verified cential
about this subject and

Manu Sporny: Mhm. Go ahead, Dave.

David C: why under what authority if you like does this holder is he
allowed to say something about this subject and that was the
00:30:00

David C: crack I was coming from. So it might be that I am the subject's my
child. So that's Dave's example. So it would deal with that, but it would
deal with other examples as so I don't know whether that's of interest to
people or not, but that I thought that was of more value than just the
confidence method itself.

Dave Longley: I think that is of interest, but I do think it's at a
different layer. So, the confidence method itself allows you to get
confidence that who whoever you're talking to is in fact that entity. you
can raise that level of confidence. But I think what you're talking about,
David, is whether or not they should then therefore be allowed or whatever
it is they are presenting, should that go into some kind of policy that the
verifier has about that information? And I think that happens at a
different layer and has to happen necessarily subsequent to getting
confidence that you're even talking to the right person. So you first
establish that you are in fact talking to the parent of a child for example
and…

Dave Longley: then there's some policy and other information that might
occur as to whether or not they should be presenting whatever it is they're
presenting or whether whatever it is they're presenting is acceptable for
the use case.

David C: I think you're right.

David C: I think there are two layers, but I think you've not quite got the
layers right. I think the first layer is that I'm talking to entity X and
am I really talking to entity X and I have confidence in it. So that's the
confidence level. And then the next layer is entity X says they're the
parent of the child, which is the one I was addressing. Whereas you mix
that into the bottom layer. And I think the bottom layer confidence is just
I'm talking to X and I know it's X.

David C: I don't know anything about X except he's the holder.

Manu Sporny: I heard Dave's layering match what you just said, David. So, I
didn't hear a difference in what you said and what Dave said. which is good.

David C: That's excellent then.

David C: That's excellent.

Dave Longley: Yeah, I agree with that.

Manu Sporny: Yeah. Yeah.

Dave Longley: Yep. No worries.

Manu Sporny: Okay.

David C: So, sorry I misheard you then, Dave.

Manu Sporny:

Manu Sporny: All that's the good news. It means That's much easier place to
work from than not being ign so yeah, I mean, I think the confidence
method. So David, I think what we could do here is for you to raise an
issue on the specification with the proposal you had so that it's in the
issue tracker and we deal with it in the working group and that sort of
thing.

Manu Sporny: But I don't think that there's disagreement on at least the
lowest layer that both of you talked about which is there's a confidence
method for the subject and this is how you raise confidence that you are
that is the subject that the entity presenting is an authority for that
subject. I think that one of the places this gets it's harder for me to
reason about is when the subject is a physical card a driver's license.

Manu Sporny: I think that's where it's just weird because I think it works.
Meaning the verifiable credential is saying there's a subject. it's a card
representative of a real life card and the confidence method for the card
is attached to a key. And so anything that can do a presentation and meet
the needs of that confidence method helps you understand that that is a
legitimate document, I think that's the way to reason about it. although it
always felt a little contrived to me,…

Manu Sporny: but I think it's a legitimate use case. go ahead Dave.

Dave Longley: you just two comments there.

Dave Longley: I think the first is in fact if there was a physical card
that had a key on it, you would in fact be establishing confidence that it
was in use during the presentation. And that makes sense to me. The second
piece is you can also model and either this is for the same use case or a
potential different use case. You can model that as there's a card holder
that can be selectively disclosed and…

Dave Longley: the card holder can have a confidence method. and then you'd
be checking that it's the holder that you're getting confidence on. So you
can do both of those cases.

Manu Sporny: Yeah, plus one to that.

Manu Sporny: I guess the other thing to add about this is that if we put
this in confidence method, all of a sudden it makes the confidence
mechanism selectively disclosable. So there's a card with this information
on it, this is a driver's license that exists in the world. you have no
idea if I selectively disclose that to you and I don't disclose the
confidence method, the verifier still knows it's a legitimate, entity that
exists in the world.
00:35:00

Manu Sporny: But if I then decide to disclose the confidence method to the
verifier then it can challenge me on that confidence method and get
assurance that I'm more tightly bound to that piece of information than if
I had not provide the confidence method. So I think these are all useful
things to do. the question is what do we want in this specification when we
hand it over to the VC working group. I think Ideally we're just very
minimal and all we define is effectively this.

Manu Sporny: The confidence method is a verification key. and you can
express it using the standard key formats that we define and just leave it
at that. go ahead Dave.

Dave Longley: The only other thing I might suggest to add would be a did.
So you could prove control of a did as well.

Manu Sporny: Right. So verification key confirmation and bid confirmation.

Dave Longley: Yeah, dead confirmation.

Manu Sporny: All let's go ahead and add two new issues. David, have you
been able to add yours? I can do it here if you haven't. No audio from you,
David. okay. Add did Okay,…

David C: I'm adding the issue about the two layers. I'm doing that now.
Yeah.

Manu Sporny: great. I'll add the other one did confirmation to list of
confirmation methods. the

Manu Sporny: The vines So confirmation is done method. We should also did
confirmation as a confidence method such that key rotation is possible.

Manu Sporny: Okay, this one is of course we do not have Okay, so that one
needs to be done. sorry. I'm going to just fix this while I'm Are there any
other things that we would want to do to this spec?

Manu Sporny: We need security and privacy considerations, of course. are
there any other changes or modifications we'd want to make to this
specification? Is there anything else we feel needs to be done to this
specification before it's ready for the VCWG? Okay, that's okay.

Dave Longley: No, I think it's pretty straightforward. there's just, work
to be done in the working group to fill it out.

Manu Sporny: So, that's confidence method. I think a month want to work is
a reasonable kind of expectation for someone that's focused on it. …

Manu Sporny: And then credential refresh is this specification sorry let me
anything else on confidence method we need to talk about before we move on.
00:40:00

David C: Just I've got my issue in there so people can have a look and…

David C: if they think it's worded correctly or if they'd like it
modifying. It's issue number 12.

Manu Sporny: Excellent. Okay.

Manu Sporny: All That's great. Thank you. we can review that next time we
come around to the spec.

David C: Yes, sir.

Manu Sporny: Okay so that is the method credential refres the verifiable
credential refresh 2021 spec has in fact been deployed into production.
This is what the true is the nationwide age verification system in the
United States uses verifiable credential refresh to refresh use tokens that
are themselves verifiable credentials in the US. So this has been in
production for probably around 3 years. the specification though is pretty
out ofd and I think definitely needs to be fundamentally credential refresh
just tells you how you can refresh a credential if needed.

Manu Sporny: There's a manual refresh that basically takes an person to a
website starting at a particular date and allows the person to go through a
manual process to just get a new credential. So that's manual process.
there is one that uses verifiable credential. This was before we had the VC
API where you could do you could present the credential at a particular
workflow. look at that we used workflows way long ago and that is the name
we ended up using. so you could go through a particular workflow.

Manu Sporny: so the workflow would basically say give me your old
credential and as long as it's within this validity period, I will give you
a new credential in return. So let's say you've got an expiring vehicle
registration or you've got an expiring driver's license or you've got just
an expiring employee ID or something like that. this would allow the wallet
to auto update, auto refreshes the credential so that you've always got a
fresh one in the wallet. so there's this more kind of automated flow that
uses a refresh service that's a workflow based. and then the workflow, the
refresh protocol, again, this is out of date.

Manu Sporny: we would just replace this with a VC API workflow exchange
which could use a variety of different protocols. You can switch to oid or
other protocols if you want to just auto refresh we have some algorithms in
here which would need to be updated. this would probably point to the VC
API specification and then we've got some examples that kind of step
through each one of those things. go ahead Dave

Dave Longley: Yeah, I was just waiting to get on the queue to talk about
some things that we pro probably should put in here over the next month or
so. the first is that in implementation one way to do this is as a separate
credential that is sort of like a voucher, a ticket or an entitlement to
receive one or more other credentials. So when receiving one or more
credentials you can receive an additional credential that is the refresh
credential and then you would use that one to receive refreshed a refresh
bundle of whatever you received before and we might want to model it that
way.

Dave Longley: that mean do I I certainly think we should at least have that
be in the spec and it might be the preferred way as opposed to mixing the
refresh service into another credential and it just works better in a
layered way. there are a number of different parties that will model their
credentials that are expecting them to be a certain way then adding a
refresh service to that might not necessarily work in their ecosystem. But
if you do it in a layered decoupled way where you say, " and by the way,
when you go to pick up this credential, you might receive this other
voucher, this refresh credential that allows you to continue to get the
credential you want." that might work better. And over time, that's sort of
how things have evolved and that might be the preferred way that we should
suggest it be done even if this original mechanism can be done this way
where you mix it into the credential information.
00:45:00

Dave Longley: the additional benefit of that is since we wrote this spec we
have added from valid until in VC 2.0 O and there are a lot of verification
services that are going to potentially just outright reject a credential if
something's outside of the validity period and you can have this separate
voucher run it and have a different validity period from the one you're
trying to refresh which makes it more clear or obvious so if you had a
credential you wanted to be able to refresh and it expired in January you
could have this voucher that goes to say February gives you a 30-day grace
period to refresh your credential. And the first one can expire and no
longer be used, but the voucher could continue and move on at least for
some grace period.

Dave Longley: And so I think we should probably reconfigure this a little
bit to model it as the preferred mechanism is to do this as a separate
layering and then it's really easy to bolt this onto any VCs you have and
any delivery protocol that lets you send more than one credential can then
just let you send these it has the additional added benefit of there's no
need to potentially selectively disclose a refresh service in a credential…

Dave Longley: because people shouldn't be asking for those and wallets can
have different protections around people requesting these vouchers as
opposed to the main credential that a verifier might be interested in. that
was a mouthful, but what it comes down to is we should probably remodel
this as hey make a separate c the preferred way to do this is make a
separate credential to put the refresh service in.

Manu Sporny: Mhm. Okay.

Manu Sporny: So, we need to do all of that work probably before it goes
into the BCWG. because doing that all of that work in the BCWG is probably
a problematic thing to do. I think largely though it's still fairly
mechanical update to the specification. It just needs new content. and…

Manu Sporny: we need to point to and…

Dave Longley: Yeah, I think it'll mostly be a duplication of what's there
and…

Dave Longley: and here's the refresh one and then that travels alongside
whatever you are refreshing one to more other credentials.

Manu Sporny: then using the endpoint will just give you a new bundle of
credentials. Yep.

Dave Longley: And a new voucher to do that again later.

Manu Sporny:

Manu Sporny: Yep. Yep. Yeah. I guess the biggest concern I have is around
management of bundles. I know Dimmitri, you all had a big long conversation
about this in the BCEDU group about detecting duplicates or if you have
four versions of the same sort of credential, how do you manage that? that
would probably come into play here as well. Go ahead, David.

David C: Yeah, this sounds a little bit like reproducing the oorthth
protocol, isn't it? With refresh tokens and I'm just wondering whether it
might be sensible to leverage the oorthth protocol rather than inventing a
new one.

Manu Sporny: Yeah, I don't know about the overlap.

Dave Longley: Yeah, there's more overlap in em embracing that protocol and
then requiring it to be used to do refresh. So this is a protocol
independent mechanism for doing it and it doesn't bring any of the other
protocol considerations that you would have to implement in from that other
mechanism.

Dave Longley: And this same mechanism could work if you're using that other
protocol or a different one.

Manu Sporny: meaning you could still use open ID…

Manu Sporny: if you decide I already have an open ID ecosystem set up I'm
just going to reuse that for credential refresh you could use that in this
mechanism as

Dave Longley: Yes, you would just present your voucher and then you would
receive the credential in response. So, it would work for that as and it
doesn't split wallets into both having to implement a protocol. If they
want to do refresh, they have to use this protocol and it doesn't make
wallets have to understand how to store refresh tokens under protocol A
versus protocol B. That might work in other ways. And if the other piece
there is more than one protocol and…
00:50:00

Dave Longley: if it's defined in a protocol specific way then wallets who
want to speak two protocols might have to implement two different refresh
mechanisms as opposed to just One.

Manu Sporny: All right.

Manu Sporny: So, it sounds like we need a fairly large mechanical update to
this specification to at least get it into shape so that the working group
can have a discussion around Anything else on the verifiable credential
refresh spec. All right. I think that's all of the specs. Are we missing a
spec? Can someone think of a spec where, it's being incubated here.

Manu Sporny: we want it to go into the BCWG and we haven't talked about it
yet or anything of that or something of that nature. we will then I think
largely be waiting on people to make the necessary changes to these
specifications. we can check in week to week. but largely folks will have
to make updates to these specifications so that we can review them.

Manu Sporny: I can certainly commit to doing some of that work, but given
my workload I might not be able to get to a new set of updates for every
week. also noting that there are other groups that are pushing some of this
stuff forward like the quantum safe crypto suites is being pushed forward
in the data integrity meeting. in the VC API meeting as is presentation
request. verifiable issuers and verifiers. David, you're pushing that
forward with Isaac as time permits. the wireless stuff needs to be pushed
forward. I don't think it's largely defined, but we might want to put some
more work into that and we need to get a sponsor for that pec. confidence
method will get some work done on it and credential refresh will get some
work done on it.

Manu Sporny: So if we have PRs to talk about a week we will have our
meetings. If we don't have updates we will probably skip the meeting for at
least that week but we will keep the same kind of meeting cadence here so
that we can discuss issues and PRs and things of that anything else for
discussion today? Anything else that we should cover? If not, thank you
everyone for your time today. I appreciate all the discussion and preparing
all these specifications and we will meet again next week if we've got PRs
and changes to review. and if not, we'll cancel the meeting and meet the
following week. Thanks all for the call today. Have a wonderful rest of
your week and we'll chat again next week. Ciao.

David C: Thank you. Bye.
Meeting ended after 00:53:43 👋

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