[MINUTES] CCG VCALM 2025-12-02

Here's a summary of the CCG VCALM meeting:
Meeting Summary

*Meeting Date:* December 2, 2025

*Topics Covered:*

   - W3C Technical Plenary Update
   - Holiday Schedule
   - Issue Processing

*Key Points:*

   - *W3C Technical Plenary:*
      - Verifiable Credential API for Lifecycle Management (VCALM) is in
      scope for the next rechartering of the Verifiable Credentials
Working Group.
      - All specifications incubated in CCG, including C API, verifiable
      credential barcodes, and others, are included in the charter.
      - The charter will be updated and put up for a vote in
      December/January, with the new charter starting in Q1 next year.
      - Discussions included the anti-fraud community group, did methods
      working group, security and threat models, and digital wallet
      considerations.
      - The Digital Credential API is removing the protocol registry and
      may become a global recommendation in 6 months.
   - *Holiday Schedule:*
      - Meetings will be canceled on December 23rd, December 30th, and
      January 6th.
   - *Issue Processing:*
      - Reviewed and discussed the following issues:
         - Issue 439: Clarify workflow step functionality - Dave provided
         examples.
         - Issue 527: Specify optional client profiles in Open ID workflow
         step to support Open ID for VP multiplexing - Dave provided examples.
         - Issue 545: Add selective disclosure example to specification
         with the conversion of query by example to JSON pointers -
Dave provided
         links.
         - Issue: Provide examples of OID4 protocol messages - Dave
         provided examples.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-12-02.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-12-02.mp4
*CCG VCALM - 2025/12/02 14:58 EST - Transcript* *Attendees*

Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton, Eric Schuh,
Joe Andrieu, John's Notetaker, Manu Sporny, Nate Otto, Patrick St-Louis,
Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right. Hey folks, let's go ahead and get started. I think
Patrick's been running these calls. I'm happy to run it today. but if
Patrick shows up, he can run it if he wants to. I'm just getting back into
the swing of things today. so I don't have much context on what's been
discussed. but let's go ahead and get started. welcome to the verifiable
credential API for life cycle management call. this is December 2nd, 2025.

Manu Sporny: don't know what's on the agenda today, but let me propose that
we review some of the stuff that happened at the technical plenary W3CT and
then we can go into pull request processing and then issue processing if we
have time to do that. any other updates or changes to the agenda? Anything
else we should discuss today? if not, let's go ahead and get started with
the first agenda item with it which is an update on what happened at the
W3C technical plenary.
00:05:00

Manu Sporny: the verifiable credential working group did meet at W3CT. the
main focus of meeting was to determine what items we would put in scope for
the next rechartering of the verifiable credentials working group. the
first question was whether or not we wanted to rechart consensus was that
we did want to recharter. and then the next group of questions was what do
we want to include in the scope of that rechartering and how are we going
to prioritize work and who's going to work on what and things of that
nature. there was also another breakout session around verifiable
credentials in supply chain trade use cases.

Manu Sporny: there are multiple global standards organizations that are
looking at the use of W3C verifiable credentials for World Customs
Organization, US Customs and Border Protection. So multiple large
organizations looking at using verifiable credentials. so that's good. but
going back to the working group what was the focus? the thing that is most
relevant to this group is the verifiable credential API for life cycle
management.

Manu Sporny: it was discussed there was broad agreement to bring it in
scope because there are so many impleers and people working on it so it's
in scope right it's going to be put into the charter that Ivon's working on
in fact it already is in the charter and there was no objection to
expanding the scope of the working group to also work on protocols so
That's the first set of good news. let me cover some of the other stuff
that was also covered. I'm pulling up my notes. let me get these up here.
Not sharing my screen. okay.

Manu Sporny: So, the other things that the VCWG discussed, was basically
the whole laundry list of specifications that we've been incubating in CCG.
Every single one of them got into the charter. So, I don't think, anything
got excluded. So that includes C API verifiable credential barcodes,
verifiable issuers and verifiable verifiers, render method, confidence
method which were already in scope as well as refresh wireless and
postquantum crypto suites.

Manu Sporny: So everything's listed in the charter and we can work on those
as we have people that step forward and volunteer to work on those
specifications. so that's good news all around. the next step is that the
charter is going to be updated with some small refinements which I think
Avon has already done. and then we are going to try to get it out for a
charter vote during December, January, which means the new charter would
start Q1 of next year. there were no objections of any kind, I think, for
the verifiable credential working group charter proposal. Right. We'll see
what happens when the charter actually goes up.

Manu Sporny: let's see other things that happened at W3CTPAC. there's a
meeting of the anti-fraud community group. This is run by Sam Schlesinger
at Google. they're interested in anti-fraud signals that they can pick up
so anything that can be used to detect if the thing visiting your website
is an unidentified AI bot, or a distributed denial of service attack,
botnet or things of that nature. so the interesting work there. We talked a
bit about overlap of verifiable credential and VC API, but they were
looking for something more lightweight, something that could be done
through the browser.
00:10:00

Manu Sporny: rather than more heavyweight credentials. so there was that
group that kind of met. It's just getting off the ground. there's not much
to talk about there because they were still trying to figure out what they
were going to be working on. let's see other things that happened and this
is in no particular order. we met to talk about the did methods working
group charter. we had a good fruitful discussion around what the work would
focus on, whether or not we should have categories or not. At the end of
the day, I think we just said we're going to be using and have a list of
dit methods as potential input, but didn't try to figure out if one of them
was ephemeral or one of them was purely decentralized or whatever.

Manu Sporny: we also agreed to include the blue sky did method in the list.
we are expecting at least one formal objection. that whole discussion was
minuteed. So if you want to kind of read into what the concerns are they're
in the minutes and they've been discussed over the past couple of months.
but I think where the group got to was or at least the people in the room
got to was we've done as much as we can to try and address the objection.
We'll see the objection and then kind of go from there.

Manu Sporny: next item up is, there was good progress made on security and
threat models. there was a lot of discussion around, threat modeling and,
security threat modeling. and so, that's making decent progress with a lot
more interest on it than has traditionally been at W3CTPAC. So, that was
good. Denin Chen from Taiwan or doing work in Taiwan was there to talk
about how VCs and DIDs are being used in Taiwan has a population of about
23 million people. and so Denin was talking about the desire for multiple
digital wallets and open source and a variety of things.

Manu Sporny: there we did meet with the web of things working group that
continues to push JSON LD and they have interest in Seabore LD and YAML LD
there they believe they're rechartering again to do a little bit more work
but they're continuing to use the JSLD they had a couple of very
interesting issues with their JSONLDD contexts. I told them that I'd try
and put them in touch with you, Benjamin and Dave and u Lane issues that I
had never seen be before and I was like, "Yeah, we definitely need to talk
about these things. they seemed like they had maybe painted themselves into
a corner based on the first standard that they published. So, we'll just
have to see. let's see.

Manu Sporny: got to look at the web payments working group and the
federated ID working group and the challenges that they continue to have
with not implementing things like payment handler. Apple just announced
that they're pulling support for the Fed CM API. which means that that's
not going to have enough implementations either. they're Apple is pulling
support for Fed CM.

Dmitri Zagidulin: Wait, Who's pulling support? Wow.

Manu Sporny: Yeah. it seems to be a trend. and seems to be moving more
towards the digital credential API. that might be the reason that they're
making that. Again it's hard to tell because it's Apple.
00:15:00

Manu Sporny: let's see other things that happened. The DID working group
processed all 50 pending issues on the DID resolution spec with a huge
thanks to Will who just kind of, motored through all of those issues. So,
that's good that we have, things that need to be done. So, the work's not
done clearly, but we were able to process all the issues. So, as soon as we
get through those issues and we've got PRs for them, we should be able to
be pretty close to entering CR. there were some meetings around community
groups like the work that we do here. Community group specifications are
getting some new headers on them.

Manu Sporny: So the style of community group specifications is going to be
changing to make it easier for people to understand that they're not
looking at a W3C standard or technical specification that they're looking
at a community group thing. so again good it was mostly visual design work
stuff they're focusing on. going back to the digital wallet stuff, there
was a meeting around digital wallets, kind of threat modeling stuff, but a
big part of the discussion was around whether or not wallet data stations
were a good idea. I specifically personally said I thought that they were a
really bad idea. That's really terrible idea.

Manu Sporny: it's going to lead to a whole bunch of centralization because
they're not defining how the wallet out of stations, are going to have
happened and it got some amount of traction in the room. there maybe half
the room was like, " it seems like a really bad idea. Don't do it European
Union." but Google and Octa disagreed because the EU regulators said that
they require it. So they were basically like we can't do anything. Our
hands are tied. The European Union regulators are requiring it. So we're
going to implement it. regardless of what anybody thinks about, let's see
the private advertising technologies group which was interesting.

Manu Sporny: They've made some pretty significant progress on multi-party
compute MPC for privacy preserving ad measurement. this seems to be a
really good thing meaning they are moving away from using cookies to do
this stuff. I didn't get any of the details on it but they said that it's
got pretty broad support among privacy advocates and large ad networks
Amazon being one of them. so that was an interesting thing to hear. The
reason we might care about it is because it has overlap with BBS and
Longfellow and some of the more privacy preserving cryptography thingies
that are happening.

Manu Sporny: but I was not able to find out much more about it. let's see.
I think I already mentioned that UNCC fact UNCE is doing a bunch of supply
chain standards around VCs and DIDs. people definitely showed up. the
digital credential API, this is moving back to Fed ID working group. the
digital credential API is removing the protocol registry and they're just
going to hardcode the protocol strings into the specification.

Manu Sporny: So no registry they're going to write it supports oid it
supports ISO whatever I did have a discussion with the chairs and said hey
what about VC API and VCOM and the chairs said yep we would expect that it
should be in the spec since it's a standard that if W3C puts it on the
standards track we would expect it to be supported we will be able to test
that theory in the next two months or

Manu Sporny: So the digital credential API the chairs think that it might
be a wreck in a global recommendation in 6 months but fingers crossed don't
know until people implement but there's strong implementation signals from
both Apple and Google meaning they've already implemented it they believe
so we'll see what happens there. and I think that's largely it. good
outcome. Nothing terrible seemed to happen at there. yeah, I think that's
it for the summary. let me pause there. Any questions, concerns about
anything I covered?
00:20:00

Manu Sporny: All right. If not, we can get to the rest of the agenda.
Patrick, one, thank you very much for running the calls, while I was away
all last month. I'm totally happy for you to continue running the calls if
you would like to do that. up to you. I didn't know if you had anything
planned for today or not. Awesome.

Patrick St-Louis: Yeah, I can give it a go on the ongoing vehicle meetings.

Manu Sporny: Thank you. Do you want to take this call as Not to put you on
the spot or anything, but Okay.

Patrick St-Louis: Maybe start next week. that's okay.

Manu Sporny: Sounds good. All right. I'm going to Patrick, I don't know if
you had any specific thing you wanted to cover today, but I was just going
to do our standard issue processing thing.

Manu Sporny: Does that work for you?

Patrick St-Louis: That sounds good. And maybe if we can talk maybe about
the holiday schedule at some point. we're just starting December now and
I'm assuming a few meetings might get cancelled by the end of the month.

Dave Longley: You are muted Manu if you're responding.

Manu Sporny: Thank I was Yes, that sounds good. Let's pick up the calendar
question first. let's see. So, looking at the schedule, I would expect that
we're going to definitely cancel the last week of December and the first
week of January. So, we would cancel the meeting on the 23rd and the 30th.
I don't know if we should cancel the January or the 16th of December. We
can probably keep.

Manu Sporny: Does anybody have strong feelings about the 16th of December
or the 6th of January cancelling those meetings?

Patrick St-Louis: I think maybe cancelling the 6th might be a good idea.

Manu Sporny: Okay,…

Patrick St-Louis: I think the 16th is fine. maybe 23rd, 30th, 6th and then
come back fresh on the week of the 13th.

Manu Sporny: that sounds good. So, I will do that. I'll process the
calendar entries. So, we cancel those meetings. yep, I'm seeing strong
support for that in the so, we will cancel December 23rd.

Manu Sporny: December 30th, January 6th, those three weeks. Okay, that
sounds good. maybe we should also kind of talk about what high level before
we get into pull request processing. high level what the expectations on
this group are going to be. when the verifiable credential working group is
rechartered what we might want to do is keep this meeting slot and keep
meeting here but make it an official verifiable credential working group
meeting.

Manu Sporny: the reason for that being that we just kind of want to keep
the work going. We already have a time slot that works for us. people are
showing up and meeting here. we will need to talk about that with the
chairs seem to be fine with it. They seem to have a preference to keep
meeting weekly to keep going in parallel on the work items. I think that
would be a good idea. as long as we can continue to put pull requests
through. so I don't think the our work mode will probably not change much
other than we may have to wait. actually our work mode's basically not
going to change, which is good.
00:25:00

Manu Sporny: we may need to get a couple of people on here in as invited
experts, but looking at the list, maybe in any case, I think we're doing
okay. as far as kind of the work modes concerned we are also at a point
where we only have 23 issues and most of them have ready for pull request.
We are not really getting too many new issues. We might when the new
working group starts but I think we're pretty far along.

Manu Sporny: which means we could definitely do a first public working
draft some point in February of next year when the working group starts up.
And then in theory, we could probably get into candidate recommendation
within six months. the major thing that we would need is a test suite, but
that's pretty much it. we've got a fair number of implementations. We would
need some implementations, but this one, fingers crossed. It's always not
great thing to say this, but we are pretty far down the standardization
path already with this spec. go ahead, Patrick.

Patrick St-Louis: Yeah, I think the biggest challenge will be workflows
like testing the workflows and seeing what needs to be tested in there.
think for a lot of the VC API since we've been using that for a lot of test
suite I think this will be more about using probably JSON schema to
validate response models and whatnot. but yeah, for the workflows, I think
that this could be, maybe a bit of a challenge depending how it goes.

Manu Sporny: Plus one to that. totally agree with that sentiment. But I
mean, the rest of this stuff is looking Yeah, I don't think we have any
huge things that we need to discuss. luckily we got that out of our system
three years ago. so that's good. I think all we're waiting on is the
recharter now and we can again continue our work until that happens. All
right. Anything else on work mode that we need to discuss about work mode
or any of those items before we get into pull request processing. Okay.

Manu Sporny: If not, let's go ahead and get into pull request processing.
There's this updated get exchanges response object. Eric, do you want to
take us through this and…

Manu Sporny: then Yeah, we can

Eric Schuh: Yeah, we talked about this two weeks ago and…

Eric Schuh: I have on my plate a round of updates that I have not been able
to get to with the holiday travel and everything. so I have I guess the
suggested changes that I believe are listed in the final comment here by
Thursday I think of this week. So we could either discuss before the call
next week or hopefully close this out next week.

Manu Sporny: Okay, that sounds good. anything else we need to cover on this
one before we move on? All right. let's go ahead and move on to issues
then. I think we've got the vast majority of these. go ahead, Dave.

Dave Longley: I was going to suggest that you sort by most recently updated
just because I put a bunch of example co configuration code and other
stuff. I updated a bunch of issues with example information for people to
put into PRs and we could take a look at that stuff. So if you did by last
updated some of these top ones will have some example code that we could or…

Dave Longley: example JSON and other stuff we could look at.
00:30:00

Manu Sporny: Okay, that one's two weeks ago.

Manu Sporny: This is top four. All right. so this is issue 439, clarify
workflow step functionality. And if we scroll down, that's a lot of example
code there.

Manu Sporny: Yeah.

Dave Longley: Yeah. …

Dave Longley: starting at that post there, I can't remember what was asked
for this one was something about we wanted some examples on expressing
steps in a workflow. so what I did first was provide a couple of large
examples that use most of the features that we have and then I whittleled
those down at the end in this issue to some simplifications. But I wanted
to make sure that we had the larger examples that have lots of stuff so we
can crib from these if we want to make other examples other than the two
that were mentioned in the issue.

Dave Longley: So this first example shows anam a workflow configuration
that has credential templates in it. It has multiple steps in it. it shows
a verifiable presentation request in there. it has a presentation schema.
So it's using a bunch of the features that we've defined. The presentation
schema is just a big long JSON schema. You can just kind of skip through
that. And you really love looking at JSON schema.

Dave Longley: if you keep going down once the nesting yeah it goes back
then it lists what the next step this is a multi-step workflow there were
two steps that one of them the first one was named verify the second one
was named issue and the administrator that creates a workflow can put
whatever names they want to I picked those names for this example because
it seemed pretty straightforward that this is a workflow that has a verify
step and then an issue step and so in the verify step there was a VPR And
there was a big presentation schema for checking it. And then the issue
step just has issue requests in it. And I showed two different examples of
referencing a credential template. They happen to reference the same
credential template, which also shows that you can reuse that template if
you want to, but you could also use however many you might have. The first
one in the issue request just shows referencing the credential template by
ID.

Dave Longley: The second one shows referencing it by ID and using some
custom variables for that template. So, shows that you can do that in your
workflow design as well. and in that second one, it shows that you can use
the results from the verify step in your template. So, that's what's going
on there. then let's see in it lists that the initial step is verify and
then I just took directly from a test suite this configuration. So it also
has zcaps. So if anyone wants to implement their authorization model using
zcaps. It shows how you can do that. So there's just a bunch of zcaps in
there.

Dave Longley: and then if we get down to the end of this it also shows that
there's an authorization section for OOTH 2. So if you want to do your
authorization using O 2, it shows you can put the OOTH 2 issuer config URL
that points at the metadata for your authorization server. So that this
first thing it kind of is a grab bag of maybe not all the features but a
lot of them that we've defined. The next one what it didn't show above was
a step template and this one shows a step template where you can express
the step not just as raw JSON but as a template itself. And so this is
showing that there's a template there and you scroll around you can look at
that but that's just a JSON template. So that's a string and so you'll see
a bunch of escaped characters because it's JSON as a string.

Dave Longley: and it's showing that when this workflow runs that template
will be processed and rendered using the exchange variables to produce the
step itself and the step that it produces will include the create challenge
flag will be I think it's set the verifiable presentation request there to
a variable that you could put in your exchange and it also shows the
callback feature. So if you scroll all the way to the right there, you can
put a callback URL in a variable when you create your exchange and will
inject that into your workflow. So it's showing all that stuff. the rest of
it is more or less what was above and so we can scroll past the remainder
there. And then I tried to whittle these down to this issue asked for two
things. What does a minimum viable step template look like? There it is.
00:35:00

Dave Longley: that is an example of one because you could choose different
variables that you might want to put into your step template. I just chose
the VPR. So when you're creating exchange, you could put whatever VPR you
want into this workflow. That's a very powerful workflow to allow that
anything to be requested by a coordinator. You might want to lock that
down, but I was just trying to show something super minimal. And so it just
shows there's a single step. The step I named verify it seemed to make
sense. could have called it finished since there's just one step. and then
it just has that and then the other question in the issue was what does a
minimal viable credential template look like? I gave the whole
configuration for a workflow. even though the credential template is just
that one little section in that array and I just made up a template in
there that will generate a VC 2.0 credential and it has one variable in
there called name at the very end.

Dave Longley: might be hard to read if you don't know JSON and it might be
hard to read even if you do but in your exchange variables if you specify a
name when creating the exchange as a variable it'll put that into your
credential template when it issues the credential so if you slide back to
the left it has a single step again here I happen to name it issue you
could call it whatever you want and it references that and I showed
referencing by index so you can reference a template by the index by its ID
so you can do either one and I tried to cover, the various features we have.

Dave Longley: So those are the two si simple examples, but I wanted to show
that you could do a lot more stuff and we might want to have other examples
by having that other stuff up at the

Manu Sporny: That's great.

Manu Sporny: That is going to make it much easier to create the PRs for
this. So, all that sounded good to me, meaning, we've got tons of examples
now that we can, one challenge might be the length of the examples. I don't
know what to do about those,…

Dave Longley: Yeah, they might need to be collapsible or…

Manu Sporny: but yeah.

Dave Longley: something, especially for the JSON schema portion. that's the
biggest portion in there.

Manu Sporny: Yeah, it's a new respect feature. I think that would need to
be added to have collapsible examples, which is totally can do that.
Awesome. I mean that Thank you very much for putting all of that together.
hopefully we can do a quick PR and then, I'll close this now that we've got
an example here. any other questions, concerns about this from anyone?

Manu Sporny: All right. If not, that was issue 439. Clarify workflow step
functionality. moving on to the next Issue 527. Specify optional client
profiles in Open ID workflow step to support Open ID for VP multipplexing.

Manu Sporny: Scrolling. Yeah.

Dave Longley: So again,…

Dave Longley: yeah, I added some examples for this feature. so this is
showing client in this context refers to an o oid forvp that's open ID for
verifiable presentations client profile and a client is the server in oid
forvp. it is the verifier server. So it acts as the open ID client in that
protocol. It's a little hard to follow that unless you're steeped in
working with these protocols. if we scroll down keep going down I think
this shows that you have to set variables.

Dave Longley: So, if we look at the template, there's a step template for
this. and if you scroll to the right, it's pretty similar to that other
example I gave, where you need to provide a verifiable presentation request
and you can also provide this open ID section. And so, I just, put it in
there as a variable. And then I gave an example what the variables would
look like to put into an exchange to create this. So you can see what this
client profile section would look like. So you could either do this
statically without using a step template or you can provide it like this.
This is showing you can create as many of these oid forvp client profiles
as you want to. you can name them whatever you want. your coordinator would
need to know what those names meant in order to commte protocol URLs to
different clients.
00:40:00

Dave Longley: And so this feature is primarily for coordinators that need
to do things like provide either an M some kind of user experience for
someone to click on an MDOC URL that might be different from a user
experience for scanning a QR code or clicking on some other URL or using
some other the DC API. because the ISO 18013-7 NXB spec has some
differences in it from some other protocols. you have to do this in a
different way and these client profiles allow you to make different choices
and attach them to the same exchange so that as a coordinator you can
create a sing you can have a single workflow that would support many
different protocols and it has a single state attached to it.

Dave Longley: You can create that single exchange as a coordinator and then
pass that off to you might have a lot of different users that have a lot of
different options or digital wallets or different credentials and the
single exchange can support all of those and you just need to find a good
way to express a good user experience for them. Now the VCOM spec provides
something called an interaction L that makes that user experience much
simpler. but that's not necessarily available for everyone certainly
wallets who haven't implemented that it's not available. so anyway that
shows an example of using these client profiles.

Manu Sporny: Yeah, awesome. thank you also for that.

Dave Longley: I think below all that is some other example I put in here.
this is an MDL enabled one.

Dave Longley: So, if you go to the bottom, again, I just threw it in there
as a template. You could hardcode that. this is showing that this is
showing what you'd have to do with MDL the current for oid forvp draft 18,
which is implemented by a lot of people, but is no longer what is used in
oid forvp 1.0. So I don't know if we care about including presentation
definition stuff in our spec. I think we decided we're not going to but I
wanted the example to be here. so if going forward oid forvp is not going
to use definition presentation exchange but people might have already
implemented that in some places and that's unknown.

Dave Longley: So we may or may not want to have this information. But then
the client profile data here, this just defines a single client profile. I
called it default. And it shows you the various parameters you need to set
to work with MDL for ISO 1803-7 NXB,…

Manu Sporny: Awesome. Thanks,…

Dave Longley: which is not the same thing as NXC or NX the up and cominging
NXD.

Manu Sporny: D. not awesome. This is a dog's breakfast, but thank you for
showing all of that stuff. Nate, you're up.

Nate Otto: Yeah, just a question on the naming of the profiles.

Nate Otto: Given that it requires some coordination between the coordinator
and the exchange server here to know what the different names mean and how
to handle them. Is it useful to have fairly meaningless examples like
default in there or would it be useful to do something like call this oid
forvpdraft 18 or something as the profile name to sort of indicate what
someone might name this in a more real world situation where they're
handling different profiles and trying to map them to sort of real world
concepts.

Dave Longley: Yeah, that's a great idea. I think for our examples, we
should do that. if you just have a sing I wanted to show an example that
just had a single client profile and that one's just here called default.
the other one poorly named FU and bar to demonstrate that you can name them
whatever you wanted. but I do think our example, we should certainly have
an example with names like draft 18 and so on. that would be helpful and
we'll have to figure out how to make it clear that you can name them
whatever you want, but choosing good semantic names like Nate just
suggested for those use cases where you need more than one and you want
them to reference these different protocols where your front end is going
to have to do something special to make the UX manageable.

Dave Longley: That's a great point.

Manu Sporny: Plus one of that.

Manu Sporny: I'm wondering what the best way to put this stuff into the
spec would be and highlight the various parts cuz I mean a lot of this
stuff is I don't want to say it's boilerplate but the key parts are the
tiny little thing in the template this thing here and then the bit down
here Right. No. Was it this one?
00:45:00

Dave Longley: The other thing we want to highlight is depending on…

Manu Sporny: It's this one. Mhm.

Dave Longley: how powerful you want to allow your coordinators to be, you
can let them choose. So, I showed an example where the coordinator is
effectively empowered to choose the client profile names. so if the
coordinator would be providing these variables so they would know exactly
what they're doing, but you might want to lock that down more as a workflow
creator so that coordinators don't make whatever they want. It really
depends on your setup. So, We're going to have to have some text. we need
to have general text around that if we don't already around how there's
different privileges and different powers you can give to different
entities in your setup.

Dave Longley: you can make the workflows very strict and locked down so
that coordinators can only choose a few variables that you want to give
them the power to choose or you can have it be really flexible this example
shows where the coordinator can sets that entire open ID section to
effectively whatever they want and so you have both options available to
you with the way the spec is written but for any given deployment you're
going to want to make different decisions potentially Okay.

Manu Sporny: Yep. Yeah. I was just wondering about we have to write pros
around it. I mean, it feels like some of this stuff almost goes in an
implementation guide if you want to do X or not that we have an
implementation guide and not that I'm suggesting we should create one. but
maybe this is stuff that we put down in the appendex that's like, by the
way, if you want to do this, here's how you do it.

Manu Sporny: If you want to do, this other thing, here's how you do it. And
that goes in appendices. Mhm.

Dave Longley: Yeah, I think having a few example use cases is probably a
good way to teach it to people on the spec or in a implementation

Manu Sporny: Plus one of that. maybe that's what we should do is have
appendices in the spec that's like here if you want to do this use case or
presume you have this use case, this is how you would do it. and then pay
particular attention to X, Y, and Z variables in, this next example. that
might be the best way. That's going to take a little more effort and time
to do it. But we have the base content now. Thank you, Dave. And we can
build some pros around that. Okay, that is issue 527. Specify optional
client profiles and open ID workflow.

Manu Sporny: And with Nate's suggestion to use proper semantic names that
mean that will help people understand what this client profile is we'll be
able to raise a PR on that. we've got about seven minutes left. two more
issues. Next issue is issue 545.

Manu Sporny: add selective disclosure example to specification with the
conversion of query by example to JSON pointers. Okay.

Dave Longley: Yeah, I think for this one I just left a link to some code in
an open source library that does conversion to and…

Dave Longley: from pointers. and you can convert from query by example to
DALE. so I just left a link and maybe I just left the link to the library.
May I need to more directly link to specific conversion code. so that was
justformational. I think it's the last tab that you have open that have
more examples that I put in here. and so actually there's a different issue.

Dave Longley: So this one also links to some matching code because people
were asking how do you do the credential matching and I said we could take
a look at some open source code and turn that into some spec text. So this
just does matching code in JavaScript so there's a match function there
checks for wild cards and checks some other stuff and then I think that's
matching doesn't have to be horribly complicated. and it might be good to
have some pseudo code that could come from this library as well. So there
should have been one more issue in there that was around oid for VP.
00:50:00

Dave Longley: …

Manu Sporny: got four items in here.

Manu Sporny: Those are the four You remember the name of the issue or…

Dave Longley: if we scroll down, I don't know why it wouldn't have been
listed under newest.

Manu Sporny: issue number one?

Dave Longley: I just remember that it had o oid for Are these all the
issues? I wonder if we didn't close any,…

Manu Sporny: They're the ready for PR ones maybe.

Dave Longley: did we? that's why it's not showing up. It might not be ready
for PR.

Manu Sporny: Yeah, this one.

Dave Longley: Yes, there we go. And so because we needed some other
information about OID4 and so I put more examples in here for this.

Dave Longley: so first I don't know how much this one again is just showing
some steps referencing supported formats for jot vc and so on since that's
a thing that's used in oid for vc. we can scroll past that. So it's got a
quick example of that. we can scroll past this for now. That's just putting
some variables in. this is showing using bid proof request which is part of
a oid for VCI. If you need to provide a proof during issuance it's showing
that you can express accepted bid methods to do that. Let's keep going. I'm
trying to get down to since we have limited time.

Dave Longley: trying to get down to this bit because this issue was saying
give examples of protocol messages but those are all defined in the oid4
specs. So I think what we really want to do in our spec is say how would
you implement oid4 both vci and vp on top of vc vcom exchanges. And so the
first thing that came to mind was the question is where do you put the
routes that you need to implement. So to implement these other protocols
there a bunch of different routes you need different endpoints that your
server has your servers or server have to expose.

Dave Longley: And so I made a list here of that an existing implementation
uses for the various metadata routes for authorization server something
that's called in OD4 there's an authorization server and there's a
credential issuer server and then there's a batch a a credential offer
endpoint non token JWK's and then request and response endpoints for oid
forb so there's a bunch of different endpoints that you need to implement
that each perform a different function in those specs. importantly, each
one of these when you implement on top of a vcom exchanges, if you look at
that first open ID route that's on the page there, it's just off of So, an
exchange is the base path and then all of these other things get attached
onto the end of that.

Dave Longley: and more or less that's it and it's just putting that here as
a list. I think there's another message below or I put some other examples
below. Once you've done that and made all those routes, how do you keep
track of the stuff that needs to happen during these other protocols and
what they need to do to operate? So, these other protocols have things like
they have expected credential requests. So if you request a credential,
there's certain credentials the way that those protocols are designed is
that they have these endpoints that are supposed to sort of just hang off
your server somewhere that do everything that your server could possibly
do. And VCOM is divides things up and contextualizes them.

Dave Longley: So whenever you use an exchange in VCOM, it's specifically
tied to specific workflow and that's not how these other protocols work.
And so when we attach oid to an exchange, we have to do things like be able
to say what are we expecting a request for a credential that comes to an
exchange needs to match whatever that exchange has been programmed to do.
And so you have to say what the expected credential requests are. And then
in order to implement OOTH 2 on top to because all of those routes above
all use OOTH 2, you need some key pairs and stuff. And the way you can
engineer that on top of VC API exchanges is you can just generate those on
the fly for each of your exchanges.
00:55:00

Dave Longley: And then it's where every exchange and then when the exchange
expires you just throw them out. So the VCOM design is such that an
exchange is a capability URL and it's only ever known by the party that's
using it and the OID4 routes are not designed that way where they're just
open and available to anyone who reads metadata. But because the approach
that we have is to attach those to each exchange, all of that key material
and all that other stuff that has to be set up for OD4, it more or less
becomes super superolous, but still has to be done in order to be compliant
with the spec. And so without compromising security in any way,…

Manu Sporny: Wait.

Dave Longley: we just generate these keys every time you create an exchange
and then you throw them out.

Dave Longley: and so this is showing some of the stuff that you need in
order in order to make those protocols work on top of your exchange. Go

Nate Otto: Yeah, just briefly noting that within the oid family, as used
for the ISO MDOC exchanges, there are some of these ephemeral keys created
as well for the session transcripts. So those servers that are primarily
implementing those specs are doing some of that work too and those are
distinct from the keys where your response is encrypted to the serverwide
key. But in any case, your point stands.

Dave Longley: And you'll also see in what you had on the screen there, if
you go to the bottom of this JSON text, there's some other for encrypting
responses. This is sort of related to what Nate just said, you need to
generate some key agreement pairs because the response you can both have
signed requests with OID4. So when the request comes across, it's signed by
a particular key. You can als and when you provide the response, it can be
encrypted to a key that is specific to your server. And the way that this
is all engineered is that it's specific to the exchange. So you don't have
to worry about key rotation or any of that other stuff because you just
generate these keys, use them with the exchange, and then you throw them
out.

Dave Longley: In terms of signing requests, which is also somewhat related
to what Nate just said, you might have some key rotation concerns because
you probably want those keys to be more persistent. and I don't remember if
I put an example in here. Maybe this example has it, but I think in one of
these examples, you can also set up your exchange. You can give it, for
example, a Zcap to sign a request and keep that key material off of your
workflow service.

Dave Longley: So I think I put examples in here for all of that stuff so
that you can layer on all the OID4 specs and the MDL stuff to your, heart's
desire.

Manu Sporny: if this is…

Manu Sporny: what one's heart desires. Yes. again thank you very much for
all the detail here and all of the examples. that'll help us a ton to just
effectively copy and paste pieces of this into the specification. I don't
know about anybody else, but I'm exhausted by the complexity here I'm just
going to shut up about Open ID. this just feels so fantastically complex.
in a bad way, not a good way.

Manu Sporny: but whatever that's what other people have really pushed for
and so we're just trying to make sure that we can support all these
different variations that are floating out there. with that said we are out
of time. Thank you again very much Dave for putting together all of these
examples. I can only imagine how exhausting it is to have to put together
these systems rather than just read about them like we're doing right now.
And that's it for our call this week. Patrick, I'm presuming you have the
call for next week. let me know via email if anything changes there. and of
course, always, we need pull requests.

Manu Sporny: that's really what we need to make progress at this point is
more poll requests. so if you have the time please raise some pull requests
on the spec so we can keep moving it forward. All right, thanks everyone.
have a wonderful rest of your day and we will chat again next week. Take
care.
Meeting ended after 01:00:06 👋

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