[MINUTES] VC API 2025-04-22

VC API Community Group Meeting Summary - 2025/04/22

*Topics Covered:*

   - *Community Updates:* The W3C vote for Verifiable Credentials 2.0
   specifications concluded successfully. Incubation promotion calls are
   ongoing, considering VC API for standards track.
   - *PR 473: Interactions and Initiating Interactions:* This was the main
   focus, addressing protocol agnostic interactions, verifier-initiated QR
   code generation, clarifying diagrams for different interaction flows
   (issuer/verifier initiated vs. holder initiated), and specifying protocol
   selection. Discussions centered around the website interaction protocol
   (redirecting to a website for further interaction) and the VC API
   interaction protocol (standard VC API exchange). Specific details on JSON
   schema for response formats were noted as needing further attention.
   - *Protocol OIDs:* Discussion regarding the casing of OIDs (lowercase
   preferred) and whether to include examples for both OID4 VP and OID4 BCI
   (decided against the latter for clarity).
   - *Issue #434:* This issue, concerning exchange information, expires and
   TTL (time-to-live) updates, was deemed fully addressed and ready for
   closure, pending a PR to implement the changes.
   - *Open Issues:* A review of the remaining 40 open issues identified
   that most were awaiting PR submissions.

*Key Points:*

   - PR 473 is nearing completion, pending minor corrections to diagrams
   and a few specification details.
   - The website interaction protocol aims to smoothly redirect users to a
   website for continued interaction, illustrated by a retail checkout
   scenario.
   - The VC API interaction protocol leverages the standard VC API exchange.
   - The use of XML schema date/time (with time zone) was reaffirmed for
   its time zone specificity, overcoming past challenges.
   - Future meetings will be contingent on PR submissions; no meeting if no
   new PRs are submitted by early next week.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-04-22.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-04-22.mp4
*VC API - 2025/04/22 14:58 EDT - Transcript* *Attendees*

Dave Longley, Eddie Dennis, Joe Andrieu, John's Notetaker, Kayode Ezike,
Manu Sporny, Parth Bhatt, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right, let's get started. welcome everyone. This is the
verifiable credential API call. it is April 22nd, 2025. we do have an
agenda for today and that is largely to close out the presentation and
discussion around PR 473 interactions. we will go through the remaining
protocols. We didn't get through all of them last week. and then see if
we've got consensus to merge or we're close. and then we'll just go over
our standard issue processing and pull request processing and item
assignments. are there any other changes or updates to the agenda?

Manu Sporny: anything else that we want to cover today? All with that,
let's go into any community updates, any news of interest. I have one item
and that it looks like the W3C vote for verifiable credentials 20 all the
specifications went really well. Voting closed last week. we're in good
shape. I can't share much because that's still kind of a member vote thing,
but we're in good shape.

Manu Sporny: okay. So, I don't know if there's anything else that folks
wanted to cover, community newswise. All right. I guess I'll also note that
in the incubation promotion calls, those happen every Wednesday at 11 a.m.
those are contemplating the VC API as one of the items that goes onto the
standards track in the verifiable credential working group. So we've got
our work cut out for us here.

Manu Sporny: we need to close out these 40 plus, pending items ideally. we
don't have to, but it would be good for us to do that. So, as many as we
can get to would be good. Okay, let's jump into our main agenda item. and
that is continuing to look at PR 473 which is interactions and initiating
interactions. this let me go ahead and pull up the preview, largely covers
a new part of the specification, section 3.12 around initiating
interactions, the code response format, and then two protocol interaction
protocols that we're defining here.
00:05:00

Manu Sporny: we went over a number of these sections last week, but since
last week, there are a number of items that people raised. Thank you. there
are now kind of updates to the PR to address those items. I'll go through
some of them today and then we'll finish off with talking about the website
interaction protocol and the BC API interaction protocol. so I'll just
start at the top here and keep going down the list. the first edition is
that Eric last week noted that interactions this whole protocol thing is In
fact, it's not even specific to verifiable credentials or digital
credentials.

Manu Sporny: It could be, Any two systems that want to start communicating
with each other, you can use this mechanism to bootstrap. And so there's a
new note that points out that these interactions are application use case
and protocol agnostic. they're communication medium agnostic. and hopefully
that addresses Eric's concern. the next update is Dave Longley, you
mentioned that it would be nice to see kind of the verifier generating the
QR code instead of the holder. What we the last week we had this thing
where the holder is the one that generates the QR code and instructs the
verifier to interact with them.

Manu Sporny: but the other approach is a verifier or an issuer would
generate the QR code displayed on screen and the holder would use their
wallet or app to interact and that's what this top flow is about. go ahead
Dave.

Dave Longley: The one thing I would mention is I could imagine someone read
reading the spec only seeing a verifier only seeing the two out of the
three parties playing the role of generating the interaction I don't know
if it's worth it to have an entire other diagram that just says issuer
coordinator or if we want to say an issuer or verifier and…

Manu Sporny: Yeah, we should probably just Yeah,…

Dave Longley: put it in a single thing.

Manu Sporny: I think let's just change this to a sure verifier coordinator
and be done with that. I'm hesitant to put in another diagram that looks
exactly the same except for a change here, right? Okay.

Dave Longley: Yeah. I'll make a suggestion

Manu Sporny: All So, let's go ahead and put that in. If you don't mind,
what? the diagram is text in here. It's a sequence diagram. You could just
make a change suggestion on Thank So for this diagram, it's pretty standard
or straightforward. the diagram's more involved because they're more kind
of things that are involved meaning you've got a browser involved with this
where the holder clicks share credential in the browser which is what
coordinates a verifier coordinator website which then generates a QR code
and shows it on the website which the person then potentially pulls

Manu Sporny: out their mobile phone and scans the QR code. which then makes
the wallet get the available interaction protocols and then gets consent
from the holder at some point that there is an entity verif the issuer is
requesting credentials or wants to issue credentials or something. The
wallet then selects the appropriate protocol and then Joe this is your
request from last week where you said hey it's also down here where there
are these optional protocol selection that's made and then a specific
protocol is used to kick off the flow.

Manu Sporny: So I think that captures what we wanted to capture last week.
Modulo what Dave just mentioned which will go in as a change request. Any
other questions concerns about this? I know Coyote you were asking some
questions around these diagrams. I think this does what you also asked for
Coyote which is to show the website initiated interaction
00:10:00

Kayode Ezike: Yeah, I think what I was saying was related I think David
addressed it when it was talking about basically what it might look like
for the selection to happen but basically what a visual an example one of
these sites might look like. but I think this also kind of makes that clear
and he mentioned he gave where he said that there could be some decision
making that happens automatically from that site that reduces the amount of
control or…

Kayode Ezike: the amount of decision overhead that the user would have to
make. So that verification was useful.

Manu Sporny: Mhm. Okay.

Kayode Ezike: I don't know if it needs to go in here per se, but yeah, I
think this is good, though.

Manu Sporny: If there is something, yeah, I'm hesitating on the should we
show a picture of what this could look like to the user. usually specs
don't do that, but it's always nice to document stuff like that. in any
case, I think we could maybe put that in another future if you want to
raise an issue on it. yeah. Okay.

Manu Sporny: So that item and then this one is just the diagram we saw last
week but with the modification Joe that you asked for which is make it
clear that this is kind of selecting the protocol and doing a specific
protocol the website protocol is an optional thing. go ahead Dave.

Dave Longley: While looking at the other diagram trying to make suggestions
I'll note that a number of the things in the flow here are based on sharing
a credential not receiving one.

Dave Longley: So I don't know if maybe we do want a third diagram. So I
could try to inline suggest a third diagram.

Manu Sporny: Mhm. …

Manu Sporny: if you don't…

Manu Sporny: if Yeah,…

Dave Longley: We got out.

Manu Sporny: if you want. yeah, So they would cover issuance verification
and then verifier initiated verification and then holder initiated
verification which I think is fine. I mean hopefully these are fairly
generalized things. All right. Okay. So, that. And then I mentioned this is
Joe. I think the change you wanted here with the little dash line optional
protocoly thing. I think those got some changes.

Manu Sporny: Why aren't right. The QR code's just not going to show up on
the preview, but I think that didn't change much. I went back and looked at
Dave, you had had a suggestion around or you were like, I don't think it's
I checked it's API all lowercase altogether. I did also check that OID4 VP
is all caps and OID4 VC is all caps. I'm wondering if we could just say
make it all lowercase for everything and then we can just put something
that's case insensitive or we can say it's case insensitive.

Manu Sporny: I'm a bit hesitant to say it's case insensitive.

Dave Longley: I think we can leave the spec like this and…

Dave Longley: if we need to change it back we can…

Dave Longley: but hopefully implementations can just handle Awesome.

Manu Sporny: Okay.

Manu Sporny: I don't know if we wanted to say anything about it. I think
I'd rather not say something about it. because it's kind of weird to say,
these things should be match case insensitively, but you usually don't do
that for JSON. I'm just going to kind of leave it as is. They're lowercase
altogether. And that's kind of the design pattern we have. And then if
people want to do something fancier with their implementations, they can do
that. all right. So that is that one. This was also added longly based on
your request on how to map things to exchange URLs quick, easily.

Manu Sporny: let's I think that's it. all right. So, let's get into the
thing that we did not get into last week, which is the specific interaction
protocols and what the responses look like. basically so you do all this
bouncing back and forth until you select a protocol and then after that
everything after that point is kind of protocol specific.
00:15:00

Manu Sporny: So this one uses the VC API protocol and this one uses the
website in the requests and responses are protocol specific and that's what
these sections do is they give you the specific thing that happens. So for
the website interaction protocol if we remember the purpose of this is to
push the receiving party to a website where you will interact with them
further.

Manu Sporny: and so basically this is imagine let's take a retail use case
for example. You've got, a customer that has filled their basket up with a
bunch of stuff they want to buy and they want to check out. And you've got
a point of sale and a clerk, at the point of sale. what the customer does
is they go to their digital wallet and they click the checkout button. that
will generate a QR code and then they show that to the clerk who then scans
it. When the customer looks back at their phone, a bunch of stuff a
communication will have happened between the point of sale and their phone
in the background and their phone will say, "Hey, this store wants to send
you to their website. Are you okay with going there?" Right?

Manu Sporny: And if they click okay, then they're pushed to the retailer's
website where they will see their shopping, cart being filled up with items
as the clerk is checking them out. So, this is called a customer. Your
phone becomes what's called a customer display unit in the retail space.
it's like a point of sale, but it's your phone and it's showing you the
stuff that's in your basket. along with prices, discounts, that kind of
stuff. and there at that point once you're on the website, you can interact
in a whole bunch of other different ways. Chappie, the digital credential
API, some proprietary thing that the retailer has for an app on your phone.
there's all kinds of different stuff, but the main thing with the website
protocol is to just get the customer to a website and that's it.

Manu Sporny: And then once you're on that website, a whole bunch of other
things can happen at that point. But the only message that point of sale
needs to send to your digital wallet is this message which is the URL that
your wallet should open a browser session to. So basically open up this URL
in a browser why you are asking the customer to open up that URL and then a
reference ID for the particular transaction for debugging purposes whatever
right there can be other stuff in this message but those are the core parts
of it I just noticed that we don't specify the specific post data in here
and we probably

Manu Sporny: we should probably specify exactly what's expected the JSON
schema for what's expected here but that's it any questions on the website
interaction protocol so basically point of sale system would post this to
the customer's digital wallet and then the customer's digital wallet is
like hey Shopco wants to send you to their website for this purpose to
check out are you okay with that

Manu Sporny: And if they click browser session and they get redirected.
hopefully that's pretty straightforward. It's meant to go ahead, Coyote.
Bluetooth.

Kayode Ezike: Sorry, just really quickly. So you say post it to the wallet
service. if it's not a backend wallet, one that has a backend per se, would
it just basically return this to the wallet directly through whatever
mechanism that is agreed upon?

Manu Sporny: Yep. Mhm. Yeah. I mean,…

Kayode Ezike: Okay.

Manu Sporny: it could send it, in theory, we haven't fully speced that out,
but yeah, I mean, all of this could be posted back over a Bluetooth
connection and the URL could be a Bluetooth URL, but then it gets a little
dicey because it's kind of like and then how do you trust if it gives you a
Bluetooth URL?
00:20:00

Manu Sporny: How do you know it's someone that's not, nearby that is that
true? How do you know it wasn't someone that was looking over your shoulder?

Manu Sporny: It would be pretty hard to pull off the attack, but you could
do it and they could send you somewhere else.

Dave Longley: What matters is once you establish a channel,…

Dave Longley: you can if you're using the VC API protocol over that
channel,…

Dave Longley: you can transmit messages to increase your trust. So, they
could present verifiable credentials over that channel.

Manu Sporny: Yep. …

Manu Sporny: the retailer could basically be like, "Here's my Shopco
credential. It's issued by, the National Retail Federation, and they, are
proving that I am who I say I am."

Kayode Ezike: Yeah, true. Yeah, I guess I'm realizing as we were discussing
that the key distinction between the VC API examples we've used in the past
is that it was same device and…

Kayode Ezike: so the chat stuff was the clear way to do that kind of a
thing. But in this case there is a cross device flow. So yeah, thanks for
clarifying.

Manu Sporny: Mhm. Yep,…

Manu Sporny: that's all right. So, that's 312 4. And then the VC API thing
should look very familiar to us in this group, which is let me go back up
here. So, This is our kind of shopping use case. So, the holder generates a
QR code, shows it to the Verifier selects Oops, sorry, that's the wrong
one. no, it's this one. which is where the verifier kind of, generated it.

Manu Sporny: down here when the wallet selects the appropriate protocol it
will then contact the verifier coordinator and that will be the start of
initiating participating in exchange. So it literally will just fall into
this flow here where they post to initiate, they send a VP, they get back a
VP. and so the VC API can do the initiating party can send a verifiable
presentation request or they can send an empty message which then the other
side can send back a verifiable presentation request.

Manu Sporny: And this is just, bog standard VC API at this point. It's just
an ex a standard VC API exchange at this point. Okay, I think that is the
entirety of the PR is that Any other questions, concerns, comments on any
of that? I guess the only other question I have is do we want to put an
OID4 example in here? We do up. So where do we do it?

Dave Longley: I believe we have an OID for VP.

Manu Sporny: Here. Yeah.

Dave Longley: Yep. Example.

Manu Sporny: So we have that there. Do we want to put OID4 VP and OID4 BCI
as two other interaction protocols here? We just want to keep it.

Dave Longley: Let's just keep it. I don't think we need to put both. if we
find that we do,…

Manu Sporny: Mhm.

Dave Longley: people might also get confused if you put both of them in the
same protocol message since and there's an expectation that if you're
receiving a credential, it's just going to be oid for VCI.

Manu Sporny: I think that is it then. any other questions or concerns? All
right. So, if there are none, I'm not going to merge this today because I
think Dave, you had another thing that you in.

Dave Longley: Yeah, I put the suggestion in there.

Manu Sporny: And then Ted's got a question there. I'm going to come back to
that, Ted. And then there's this one. Okay. I think we've addressed all of
those. Dave, are you pretty confident that the sequence diagram is right or…

Manu Sporny: do you want to merge …

Dave Longley: If we put it on the screen,…

Dave Longley: we can find out.

Manu Sporny: how do we do that? I think I can.

Dave Longley: It should autogenerate a preview.

Manu Sporny: Yeah. add sequence diagram for is So while that is crunching
Ted you asked a question each step can involve the issuance and
verification transmission presentation
00:25:00

Dave Longley: Yeah, I think that's fair.

Ted Thibodeau Jr: Right. The question is,…

Dave Longley: Go ahead.

Ted Thibodeau Jr: you're probably going to say what I'm going to say. the
question is whether each step is atomically one of these interactions or
can involve multiple

Dave Longley: Yeah, current implementations would allow you to present and…

Dave Longley: then be issued something in a single step.

Manu Sporny: Clarify that steps one or…

Manu Sporny: more than one can involve action I guess. All right.'s that.
And with that, let's go look to see if it regenerated. Yeah, it's linting
now. So, if I go up here in theory and I repreview

Manu Sporny: and go down over here. Holder veri So, this is a no. I'll fix
it up. there's some Yeah.

Dave Longley: Did it just say there's just a random box.

Manu Sporny: Yeah, That's fine. I'll take a look at it and fix it issue
generating interaction using car shared with the holder and proceeding with
the VC API protocol. Yeah, some of these are a little out of order. I'll
take a look at it and fix it up. Okay, so we won't merge this.

Dave Longley: Yeah, I had to move, just to be clear, I had to move the
consent for issuance and I just moved the steps. I didn't think it would
break the diagram. because the consent for issuance happens after you start
the workflow and…

Dave Longley: you're presented with credentials. So the consent then says
do you want to accept the credentials?

Manu Sporny: Right. Yep.

Manu Sporny: Yep. Understood. I'll make sure that that's in there. I think
we're pretty much ready to merge this once that those syntax things are
fixed. all right. Anything else on that before we go to the Next one is one
you raised coyote. and I did a couple of review or…

Manu Sporny: did a couple of minor knits but should be okay.

Kayode Ezike: Yeah, I addressed two of them.

Kayode Ezike: The one that basically were recommending to switch from ISO
A601 to XML schema daytime. The one that I didn't address yet cuz you asked
a question which I think you touched just earlier on this call about what
the official name for the family of protocols is. I generally just say
I4star family of protocols but yeah I can add family there to make it clear…

Kayode Ezike: but sure any opinions.

Manu Sporny: I don't Yeah,…

Manu Sporny: I don't have a strong feeling one way or the other. I was just
kind of openly wondering if there was a name. does anyone have any strong
feelings?

Kayode Ezike: Yeah. Hello.

Manu Sporny: Otherwise, it's fine to not accept this and move forward. All
right. No strong feelings. Let's just merge it. let's see. let me go ahead
and just how do I I'll just have this change. Leaving it as is. Okay.

Manu Sporny: I think we're good to go. Time. And just to double check, we
are doing XML schema date timestamp because ISO8601 doesn't require time
zone which gives you date times where you have no idea where the time zone
is. And so we use XML schema date time to enforce that there's a time zone
on there. And why did we do daytime stamp? maybe it's daytime stamp that
requires the Both 8601 and XML schema datetime don't require you to put a
time zone on there.
00:30:00

Manu Sporny: And so we were like, "No, always put a time zone so where the
time's anchored." that was after three years of pain in the VC working
group trying to get to where we needed to get to on that. All right. I
think we're good. Yeah, I already approved it. so let's go ahead and merge
this puppy.

Manu Sporny: Thank you, e, for the change. It's approved. And then many All
So, let's clean base and Excellent. Thank you, Coyote, for the All right.
we have about 20ish minutes left. We don't have any new issues, which is
good. I should have closed that. I think Did we fully address 434?

Kayode Ezike: Yeah, 434 had a lot of stuff in there. but yeah, it should
have all been addressed.

Manu Sporny: So, PR needs to be raised that adds, expires, and removes TTL.

Joe Andrieu: Goodbye.

Kayode Ezike: Yeah, it used to be exchange information if you scroll up.
that was removed basically just Yeah, there's a number of different things
that were mentioned in this.

Manu Sporny: Do we?

Manu Sporny: But I guess do we want to change this? Hold on. Let's say you
made all the changes that we needed to, right, Cody?

Manu Sporny: I think we can close this then. 74. What's Okay, All right, we
now only have 40 issues left. let's take a look at these issues. I don't
know if there's really much I think everything that's an open issue we've
already talked about before and so we're really just waiting for PRs. which
is fine,…

Joe Andrieu: Thank you.

Manu Sporny: but there's not much to talk about until we get PRs in. are
there any specific issues folks wanted to talk about? If not, I think we're
good for today. Meaning we don't need to extend the call any further than
we need. Are there any other items or any other business folks wanted to
discuss today? Okay.

Manu Sporny: With that we'll end the call and…

Joe Andrieu: All right.

Manu Sporny: then we will have another call next week if we have PRs and if
we don't have PRs we will not have a call. so try to get PRs raised by the
end of the week or at least next Monday and then if If we don't have PRs we
won't have a call. All right. I think that's it for today. thank you
everyone. have a wonderful rest of your day and we will maybe chat again
next week. Take care. Bye.
Meeting ended after 00:35:03 👋

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