[MINUTES] VC API 2025-09-02

W3C VC API Community Group Meeting Summary - 2025/09/02

*Topics Covered:*

   - *Community Updates & VCWG Rechartering:* Discussion on the W3C
   Verifiable Credential Working Group's maintenance mode, upcoming
   rechartering process, and a poll to prioritize standardization efforts. The
   VC API was identified as a top priority by the community.
   - *Pull Requests:* Review and approval of several pull requests,
   including renaming the specification to "Verifiable Credential API for Life
   Cycle Management" (VCOM), updating the API component overview to include
   workflows, clarifying the use of controller and authorization fields, and
   addressing various minor issues in the specification.
   - *New Issues Triage:* Discussion and prioritization of new issues,
   including clarification on OAuth scopes, expected callers in API component
   overview, clarifying authority between frontend and backend coordinators
   (addressed by referencing OWASP security best practices), and specifying
   optional client profiles for multiplexing (to support different credential
   formats and ISO 18013-7 compliance).

*Key Points:*

   - *VC API High Priority:* The community strongly supports prioritizing
   the VC API specification in the upcoming W3C WG charter.
   - *Specification Renaming:* The specification was renamed to "Verifiable
   Credential API for Life Cycle Management" (VCOM).
   - *Workflows are Fundamental:* Workflows were highlighted as fundamental
   for managing complex credential exchanges and interactions across trust
   boundaries.
   - *Security Best Practices:* The need for clear security considerations
   was acknowledged, particularly regarding the separation of frontend and
   backend coordinator authority. Referencing OWASP security best practices
   was deemed sufficient.
   - *OAuth Scope Clarification:* The need for clearer guidance on
   structuring OAuth scopes was identified and a PR was planned.
   - *Client Profiles for Multiplexing:* The importance of client profiles
   to support multiple credential formats and compliance with standards like
   ISO 18013-7 was discussed. This is considered high-effort due to the
   complexity of the underlying standards.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-09-02.md

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

Benjamin Young, Dave Longley, Elaine Wooton, Eric Schuh, Joe Andrieu,
John's Notetaker, Kayode Ezike, Manu Sporny, Manu Sporny's Presentation,
Parth Bhatt, Patrick St-Louis, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right, everyone. Let's go ahead and get started. I think
we're expecting two or three more people today, but we can get started with
the agenda review. all right. we do have an agenda today. we're going to
cover some community updates. talk about the verifiable credential working
group rechartering poll a bit. look at some poll requests. triage some new
issues and kind of go from there. are there any other updates or changes to
the agenda today? Anything else we want to cover? All right. if not, we can
get started with introductions and community updates.

Manu Sporny: I think we know most of the folks on the call, but Elaine,
would you mind introducing yourself?

Manu Sporny: You don't have to, but would love to hear your background.

Elaine Wooton: No, I don't mind.

Elaine Wooton: I'm a forensic document examiner. spent 33 years with the,
INS and then the Department of Homeland Security. But, a few years ago, I
started advocating for putting, digitally signed printed elements onto
things like driver's licenses. So, it's kind of my thing. I retired and
basically what I do now is just run around and tell people that digital ID
isn't the only thing. There's going to be physical IDs and they need
digitally signed elements on them.

Manu Sporny: Welcome to the group,…

Elaine Wooton: So that's who I am. I did participate in some of this
earlier via DHS, but I didn't actually end up doing that much. But now I'm
here here to join you guys.

Manu Sporny: Wonderful to see you here.

Elaine Wooton: Yeah. Glad to be here.

Manu Sporny: All right. let's, go ahead and go into community updates. as
some of you have probably seen, the W3C verifiable credential working group
is currently in maintenance mode. we started meeting, last month. Right
now, the meeting cadence is once a month. for the rest of the time, we do
these meetings, which are community group meetings to kind of continue to
incubate and move some of the work along.

Manu Sporny: one of the things that came up during our first meeting was
what about all these other items? We have nine specifications that are
under active incubation in the credentials community group and there's a
question about how in the world we're going to get all of those on the
standards track and move them all forward in parallel during the next
charter. as folks know, the last two and a half years were really hard in
the working group primarily because we had to get seven global standards
all out at the same time in parallel. and we did accomplish that but it was
a lot of work and I don't think some of the folks in the group are looking
forward to repeating that over the next two years.

Manu Sporny: I think inevitably we are going to end up repeating that
because things are moving quickly and this technology is being deployed and
we have to keep up with what's happening in the markets. So no rest for the
weary. We've got to figure out a way to advance all these things because
there is a demand there's a strong pull on a lot of these technologies. So,
all that to say that there's a questionnaire out there that especially some
of the folks in this group should fill out. It's called poll. What should
the W3C VCWG standardize next? It's a simple Google form.
00:05:00

Manu Sporny: if you're in the community and you have opinions on what we
should work on, please do, fill that out. Specifically, and I hate to put
you all on the spot, but, Coyote and Parth with the VC API, it would be
wonderful to have both of you as editors on that. and one of the places you
sign up for being an editor is through this Google form. So, I'd like both
of you to, seriously consider that.

Manu Sporny: I think both of you would be great editors and we certainly
need all the help we can get. let me give me half a second and I'm going to
pull up some of the responses as great. So, Coyote already filled that out.
let me pull up the preliminary responses as they exist.

Manu Sporny: Sorry, I have to make sure I'm not sharing too much when I
bring these up. and then let me go to sharing these again. so we're getting
really good feedback. it's early days. I mean, people have only really had
a day to fill it out. We've already got 13 responses, which is good. and so
we're starting to see some patterns, in for render method here.

Manu Sporny: for confidence method these bar charts the things on the right
say that people think it's really important and then towards the left is
not really important VC API this is the one I wanted to show folks I mean
there's a pretty strong demand this is a very clear signal that people want
us to prioritize the work that we're doing in this group the barcodes perk
is also, heavily people are leaning in pretty heavily into the VC barcode
stuff. and then there's stuff like, the VC over wireless. People are not as
excited about that, So, this is going to probably be one of the things
that's put a bit on the back burner.

Manu Sporny: credential refresh again not as much fairly strong enthusiasm
for the quantum safe verifiable issuers and verifiers. kind of second tier
interest in it. I wanted to make sure to kind of show that it's important
because the W3C staff have basically said, "Hey, there are only so many of
us." what are the top four you want to focus on and commit to and then we
can put in other deliverables as tentative. but the general feedback we're
getting is and it's not really a surprise the thing that the community
decided to start incubating and the things that the community has actively
worked on. The community still continues to think we should do that work
but there is some clear priority that's falling out as a result of it.

Manu Sporny: okay. it's a good question, ot I don't think render method and
confidence method is going to count towards the top four because they're
already in scope for the current charter, which means that when we do the
new charter, they're just going to be in there in maintenance mode. and
then the top four will be VC API, wireless, barcodes, refresh, I forget
what the other ones were, a qu postquantum suite, and then we're just going
to put them in order, of, who and again, it's just input to the working
group.

Manu Sporny: the working group ultimately gets to make the decision. But
since many of us are already in the working group, we expect things to
that's it for community updates and the rechaoll. Are there any questions
on the rechartering poll or what the next steps are or any of that stuff?
Okay. and to remind people that the goal here is we get data during the
next verifiable credential working group. We're going to start on the We
hope to have a draft charter done before W3CT pack, which is I think
November 10thish around that area.
00:10:00

Manu Sporny: And ideally we would go into a charter vote before TAC, but I
mean it's a month a month and a half to it's not out of we could do that,
but I think it's going to be pushing it to try to get an entire charter
authoring and voting cycle which takes 30 days minimum. done by DPAC.
that's what we're shooting towards is that direction. Anything else on the
VCWG rechartering? Anything along that line before we move on? Next up are
and so in the current poll, the work we're doing in this group is at the
top priority. which is good.

Manu Sporny: I mean, I think some of us were a bit concerned that, we'd see
push back, but that doesn't seem to be happening next up on the agenda are
pull requests. and then we'll go triaging some new issues. The poll
requests will take an order. the first one is a decision on renaming to
verifiable credential API and life cycle management.

Manu Sporny: The reason we're doing this is because people are getting
confused between DC API and VC API and OID4 VCI and all these acronyms. So
we are trying to select something VCM or VCOM is the current shortening
that we seem to be going towards. that seems to have consensus at this
point. we have made all the changes necessary to the specification to do
the renaming and people seem to be okay to it. Nobody's objected to it. So
I think this is the week where we say okay we've had four weeks of input on
this modifications look good.

Manu Sporny: So, let me ask one last time. Are there any objections to
renaming the specification from V API to verifiable credential API for life
cycle management or VCOM? Go ahead,…

Manu Sporny: It was the A V C A LM.

Eric Schuh: Just…

Eric Schuh: because I've been out for about four weeks. just curious, was
there any discussion about putting life cycle management before verifiable
credential life life cycle management API just reads a little bit strange
to me that API is in the middle of the description.

Manu Sporny: That's the reason it moved to the middle.

Eric Schuh: Gotcha.

Manu Sporny: Yes,…

Manu Sporny: there was discussion around that. We were like, we not this A.
But, that's where we ended up.

Manu Sporny: Go ahead,…

Dave Longley: We also liked the advantage of still being able to continue…

Manu Sporny: Dave. Yep.

Dave Longley: if we wanted to in conversations saying BC API for short. and
so we haven't changed

Eric Schuh: Okay. Yep.

Eric Schuh: No objection. Just was curious if it had been discussed.

Manu Sporny: Good question. all right. okay. I think that's it. We are
good. I'm going to rebase and merge this. Done. All right. So, names
changed. We will go on to the next one is update API component overview to
include workflows. this was an issue that was raised by Dave Longley. we
added this concept of workflow API workflows so that you could have complex
workflows where you request a credential and then you respond back with a
credential and then you request another credential and you can ping pong
back and forth or the set of credentials they initially give you leads to
another set of credentials that you need to ask for.

Manu Sporny: But we have a section in the specification at the top that
talks about the components which components call…
00:15:00

Eric Schuh: What is that?

Manu Sporny: which other components. Let me see if I can get the preview up
here. Is this going to work? Nope, it's not going to work. Let me get and
then we see API. So at the top of the specification we have this section
API component overview where we list the API endpoints and then the
expected caller of that endpoint is like who's going to call the credential
issue endpoint. it's the issuer coordinator that ends up calling that
because they're coordinating the issuance of a credential.

Manu Sporny: however, Dave Longley mentioned that we needed to say that,
workflows are actually the ones that end up calling a lot of these more
foundational service endpoints. So, that's what this 525. while I was going
through here, I know Dave, you've got a couple of modifications here. and
we can go through each one, but while I was going through here, there were
a couple of these where I was not quite sure if we were doing the right
thing. So, I'm expecting us to have to do another pass on this maybe.

Manu Sporny: Dave, I don't know if you want to talk about your change
requests or we should just I think they're all fine, but go ahead.

Dave Longley: I think what I would add to the conversation is that
workflows and the exchanges that you create off of them are a little bit
more fundamental than just enabling more complex processes. It's also about
covering what we use we have boundaries in the API where you're either
talking with trusted components or you're talking with external or
untrusted at the start of an exchange components. And so when you're
crossing those trust boundaries what you're using to do that is a workflow
service.

Dave Longley: And a workflow service is used to create exchanges that can
speak multiple different protocols because you don't always know what
protocol a wallet might speak. And when an issuing or verifying party is
talking with a wallet, they're crossing those trust boundaries. And a lot
of the credential delivery protocols and so on need to have a layer where
you're speaking with the wallet. you might need to get information from the
wallet before you can actually issue a credential and so on. And so when we
added workflows and exchanges a couple years ago to the spec, we didn't
revise this section. And we really need to go in and show that for a lot of
these API endpoints that you're going to call, especially if you're
verifying a credential or issuing a credential, probably the majority of
flows are going to be doing that through a workflow service.

Dave Longley: because an issuer verifier coordinator will have created an
exchange and handed that off to a wallet for them to do the credential
exchange at that point over whatever protocol the two parties speak in
common and so I would expect it to be far more rare for an issue
coordinator to be directly just calling to an issuer to issue something
because once they have the credential in hand how do they deliver it and
the delivery mechanism might be insufficient and they don't know what the
protocol that the wallet speaks is. The issuance process might need
something from the wallet before you can issue the credential and so on.
And so I would say the workflow exchange stuff is a little more fundamental
and…

Dave Longley: the expected callers are probably more often workflow
services than the other way around though the other way around is still
possible.

Manu Sporny: Okay. …

Manu Sporny: sounds good. I applied your changes. and I refreshed at least
my local copy so that we could actually see what's associated. I want to
make a pass through this just to make sure that we're getting this one of
the things the PR does is we used to have the coordinators all split out.
So, holder coordinators, verifier coordinators, they used to be split out,
but I think they are all effectively the same thing when it comes to what
endpoints the coordinator exposes.

Manu Sporny: and and I guess the other thing is that these are the things
that are kind of exposed to the outside world, are these expected callers
expo correct? And are these the only two endpoints that coordinators expose
to the outside world or at least expose at all?
00:20:00

Dave Longley: they don't get exchanges one they post is exposed because
that is what digital wallets use to interact when they're speaking the VC
API protocol if the exchange supports other protocols like oid for VCI or
for VP or DIDCOM there might be additional endpoints off of the end of the
exchange…

Dave Longley: but that's the root path that anyone would generally interact
with. Just real quick, the piece we're missing for coordinators there is
the interactions that is certainly interacted with by anyone

Manu Sporny: The coordinator does expose that.

Manu Sporny: Yeah, it's not. I think you're working on a PR for that maybe.
Go ahead, Eric.

Eric Schuh: Yeah. …

Eric Schuh: not that in particular though that was in the list. I was kind
of working on updating these tables. I think you guys beat me to it while I
was on my trip. but yeah, the interactions endpoint was certainly one. and
we do have some example YAML for that I put together for the …

Manu Sporny: Mhm.

Eric Schuh: the Kexus wallet interaction working group. so hopefully we can
pull that in as well for the endpoint. and then my other comment was I do
think there's also a couple of bugs in the table rendering code here or at
least if we look at the bottom of the screen, the issuer service that
delete endpoint. I believe on the issuer service the holder coordinator is
not expected to be calling delete on the issuer service. it's the issuer
coordinator that should only be listed there. And then if you scroll down
the holder service has a similar pattern or at least it used to. so that
delete presentations.

Eric Schuh: So that's where I've sent the message before leaving on my trip
that I needed to edit the respect table generation code. I believe to fix I
guess the way that I might suggest going about this is let's get the tables
nominally correct and then I can come through and fix the table generation
bugs if there's any such as this.

Eric Schuh: But if we have the YAML with the correct expected callers for
all the endpoints, which I think as Dave pointed out, the interactions
endpoint is currently missing. if we get all that right, then the bug
fixing should be relatively straightforward.

Manu Sporny: All right.

Manu Sporny: Yeah, plus one to that. I had to fix some bugs in the table
rendering code over the weekend, and I think there's One of the bugs here
is that you can only specify a URL. you can't specify an HTTP verb. So get
and post, which is why both of these are showing up, And you just list this
in the resp. And we don't want that to happen. So we're going to have to
figure So just a note, Eric, we're going to have to figure out some way of
including the verb here.

Eric Schuh: Yeah, I think I have some ideas. it's all doable.

Eric Schuh: I think once we get the expected callers right in the YAML
files for all the endpoints, I think then we can easily triage the bugs and
it shouldn't be too hard.

Manu Sporny: Yeah. And I'm wondering…

Manu Sporny: if the way to do that is not to go I was going to go through
all of this on the call today. we probably don't want to do that. we
probably want to create a Google doc or something and then have people go
in and type async instead of eating through, 30 minutes of call time doing
that. So, I'm going to skip that today.

Manu Sporny: and I think our next step here is we're going to need to
create a Google doc or something so that we can just do the allocation once
and for all instead of going around and around on this stuff. so Let's say
that's the PR for today. and we'll move on to All right. the next one
explains that controller and authorization can be used at the same time.
and then I think Coyote, you had an update here that makes perfect sense to
me. So we should do that. that's the only other change that's been made.
00:25:00

Manu Sporny: one of the things, actually, yeah, Benjamin, since you're here
today, I want to show you this one thing. I need to check this out and
update my branch. One sec. Okay, so if we look at controller. So, we used
to not explain the difference between controller and authorization, what
those two fields are.

Manu Sporny: Kyote mentioned that hey is this one or the other or can you
use both what are they used for and so I've added documentation here that
explains that you can use the two values together so this value can be used
in conjunction with the authorization property to allow other authorization
mechanisms I think coyote you have some modifications on the authorization
capabilities code to say that's not the only one you can use you can use
other ones and then there's this OOTH 2, stuff that we're talking about
here. so this is where the language is being put. I'm interested if folks
think that this is the right place to put it. go ahead, Joe, you're on the
queue.

Joe Andrieu: I was just wondering if the distinction should be made that
you pick one I don't think you would have both a controller value and…

Joe Andrieu: an authorization value.

Manu Sporny: You could.

Manu Sporny: That's the purpose of the PR. Go ahead, Dave.

Dave Longley: Yeah, you could certainly have both of these and that enables
client You might have clients that need to use this that only speak one or
the other and by having you enable both protocols to be used.

Joe Andrieu: I thanks.

Dave Longley: So that's certainly a valuable use case. sure your question
Mon about where these two fields should probably appear on any instance
configuration, but we only ever talk about so far anyway. We've only
specified the workflow configuration schema. We haven't said to anyone else
they have to do it, for issuer instances and verifier instances. We haven't
said you have to do it this way. You can do whatever you want.

Dave Longley: So if we wanted to be more deliberate there, we could do Or
if we wanted to mention that these two fields could be used in any instance
config or something along those lines, we could do that.

Manu Sporny: We don't have APIs for instance configuration.

Manu Sporny: I don't think this is the only place where we Yep.

Dave Longley: We don't have any APIs to date in the spec that say you must
have these administrative APIs for creating instances.

Dave Longley: We've shied away from doing so in the

Manu Sporny: No. we do talk about instances up here. So, we could always
put that commentary up here, although it' be a bit weird. Benjamin, you're
on the queue.

Benjamin Young: Yeah, you had mentioned me somewhere in this.

Manu Sporny: Yes. Sorry, I had Yeah.

Benjamin Young: So, I wanted to see if we could come back to that. It's
fine though. Joe needs to speak to the thing at hand.

Manu Sporny: Yep. Go ahead,

Joe Andrieu: Okay.

Joe Andrieu: Yeah, I don't know if headbutting is too strong of a term, but
we had talked about are we specifying config at all? And early on because
when we put together the role diagram for the VC API, whether or not there
were API level stuff for config was contentious. I think it's reasonable to
do it for workflows, but only for workflows. but your mileage may vary. I
mean, I don't think it feels weird, but maybe we should talk about why we
keep that out of scope in this section on instances.

Manu Sporny: Yeah, I think that's fair. I don't think we have any super
strong desire to try to say how the administrative interfaces need to work.
so maybe a comment,…

Joe Andrieu: Yes, I will create an issue.

Manu Sporny: Joe, would you mind raising an issue and say something like we
need to specify why we did not specify administrative interfaces why we
chose not to do that in this version of the spec.
00:30:00

Manu Sporny: Thank All Benjamin, as someone that's deeply involved in the
testing stuff, there are 253 must statements in this specification. but
don't worry, the vast majority of them exist here. And Don't worry,
Patrick. these are autogenerated from respec from the respect OAS stuff and
are entirely within So JSON schema covers to 90% of these must statements.
So anything that's in here we really don't need to care about too much.

Manu Sporny: It's the must statements like this one that are outside of
those blocks that we need to pay attention to. So I wanted to make sure
that anyone that's doing testing has a heads up on this this is a side
effect of autogenerating a lot of this code or converting the YAML open API
specification files into human readable text. it autoinserts all these must
statements and we don't need to test for that because the YAML OAS stuff
will test for it. so while it might seem very daunting I don't think this
one's that difficult to use because JSON schema will catch the vast
majority of the statements.

Manu Sporny: Unfortunately that means that we will manually need to comb
through the specification looking for must statements that fall outside and
even I'm trying to find one here. Must statements that fall outside of the
JSON schema these must statements are outside of a JSON schema.

Dave Longley: Is there a mechanism to cause it to not render those JSON
schemas to find that more quickly?

Manu Sporny: It's a great idea. Yeah, you break you can make it not include
the script and that'll make it not render all the stuff in here. there are
nuances there, but I think we can talk about that after in a year, which is
when we're actually probably going to have to get serious about the test
suite here. go ahead, Patrick.

Patrick St-Louis: Just looking at this one difference when it's rendered
and this table the whole sentence is just a string as the rest of the code
it's got a specific ID the must keyword they have a specific class name as
in these little code block it's really just a string so that could be a way
to differentiate Yeah,…

Manu Sporny: Yep. Yep. Yeah. this RFC 2119.

Patrick St-Louis: the EM as in the box that's not there.

Manu Sporny: Yep. …

Patrick St-Louis: It's just like a Yeah.

Manu Sporny: I see what you're saying.

Patrick St-Louis: So, if it's outside the box,…

Manu Sporny: Got it.

Patrick St-Louis: it's going to have that EM Inside the box, it doesn't. So,

Manu Sporny: Okay, good I mean, I think it'll be fairly straightforward as
long as we all know that, that's the way we're going to do testing here.
okay. I think that's it for that PR.

Manu Sporny: We'll wait and get some more feedback on it and then merge
after a week if there's no additional feedback. okay. that's it for our
poll requests. We have four new issues that I think and Dave have raised.
So, we need to triage these to see if we can get to what language we're
going to put in the specification. So, Pyote, do you mind going over 521?

Kayode Ezike: Hold on one second. So, yeah, I think the thing here that I
was alluding to explaining is that when I was looking into the OOTH
authorization process for DC API, what I noticed is that we made a
reference to what the format of the scope should be. for example, there's
an example that said, read colon/credentials. It basically referenced a
path that the scope specified that the caller would have access to with
that scope.
00:35:00

Kayode Ezike: the one thing I've realized as I was implementing it is that
there wasn't example a particular instance for example workflow slash an
actual ID that you can access through the use of scopes and so when I was
implementing it I was wondering okay should I just use the literal term
like ID and then that means that anyone who has the scope can access any
workflow. I think eventually I came with the help of David to Dave to
realize that the expectation that you would have to spell out a specific ID
that you want the caller to have access in order to convey that. And so I
think maybe that should just be clarified a little bit. And I don't know if
it's necessary for us to exhaustively list out all the potential scopes.

Kayode Ezike: And obviously we have to list the list of little IDs, but
just maybe one example that actually shows one with an actual ID. but just
wanted to call out that it's a little bit unspecified at the moment how
that should be done.

Manu Sporny: So, we should raise a pull request that explains how the OOTH
scopes should be structured. that PR should be raised to explain how the EO
scopes I guess must should be structured. Won't deal with the RC language.
this seems like low effort and…

Manu Sporny: it's ready for PR.

Kayode Ezike: Yeah, I think so. Any…

Kayode Ezike: Any door?

Manu Sporny: All right. That one's easy. We can get to that one. next up,
it's auto updating. Nice.

Manu Sporny: Next up is fix expected callers and API component overview. I
think It's a side effect of the PR that we just discussed on the call today.

Manu Sporny: Cody, is that right?

Kayode Ezike: I believe that's right.

Kayode Ezike: That 3.7 section I believe is section that was being targeted
by that one synchronically.

Manu Sporny: All And then we'll take a look at your bullet items as we go
through that one as well. All right, that's that one. let's Clarify
distinction of authority between backend and frontend coordinators. could
you go over this one, Cody?

Kayode Ezike: So I think where this came up is whenever there's an
implementation that has a front end and backend component of a coordinator,
the two should not have the same level of authority. the back end one is
the one that should be able to actually directly access for example a
workflow service and issuer services etc and so that was something that
came up too just through discussion with David so I guess I think I was
looking for a little bit of feedback to understand if that's worth
clarifying explicitly or if that's just a general thing that we think
people would understand the current state of the stick.

Manu Sporny: Yeah, it's a good question. I'm wondering if it's something
that because if you implement it, if you give your front end access to the
stuff that only your back end should have access to, you're going to get
owned pretty quickly, I mean, I think it leads to almost an immediate
security compromise vulnerability. and I would imagine that most people
building a site will recognize that, a developer that's putting this stuff
together would understand that. I don't know what language we would put in
there, because it's pretty general website development stuff, right? It's
like don't allow the people visiting your website access to all of your
backend super, dangerous APIs.

Manu Sporny: interested to hear what other thoughts I don't think we need
to say anything about this but yeah I don't know if there's other lang I
don't know if there's language that would address your concern coyote
interested in others thoughts on This.
00:40:00

Dave Longley: If we were to say anything at all, it feels like it would be
a general security consideration. if you're designing a system on the web
and remember that a web app runs in a user's browser and they have full
control over it. But you were saying that feels like it's a general
security consideration for any web application.

Joe Andrieu: She's

Dave Longley: So I don't know how, maybe there's something we could link to
in other specs, follow these usual web design security considerations.
there might be something like

Manu Sporny: And there's the OASP, standard like OWASP security guidelines.
securing Yeah.

Dave Longley: Yeah, that might be a good idea to a link to

Manu Sporny: Where's the secure coding website? Where is it? Is it their
secure coding practices? and this is somebody else's blog. here it is.
yeah, this is it.

Manu Sporny: So, we should probably say a PR should be raised that refers
to the OASP security best practices document. instructs implementers to at
a minimum follow the checklist with that.

Manu Sporny: looking at the other and then test against the testing guide.
Would that address your concern? Yeah.

Kayode Ezike: Yeah, I believe so. I think too I'm remembering the more
context behind it too is the current 3.7 table. because of the fact that we
kind of lumped the two together basically the implementers basically need
to know where each of those calls would actually be coming from. but I
guess it's true that maybe that can just be intuited just by understanding
the general best practices. here. But yeah, I think something like this is
probably good enough for folks to work with

Manu Sporny: wondering if we should provide people with a diagram of what
hold on one second I'm wondering if we should show people in our
architecture overview we don't have a website sitting in front of the
assure coordinator back

Kayode Ezike: Yep.

Dave Longley: We might be able to get double duty out of this once we have
a diagram showing one of these coordinators talking pulling its back end to
get workflow to get exchange updates. You could have a diagram that shows
the front end of such an application asking for updates and it would go
through the coordinator which would then make a request to the exchange
service using its permissions to do that and…

Dave Longley: then it would return back to the front end some kind of
filtered data based on whatever the issuer coordinator is willing to serve
up. So we could get double duty by doing

Manu Sporny: Yeah. Yep.

Manu Sporny: So, something like where do we have sorry, there's bugs there.
yeah, maybe we do something like this and break the issue coordinator down
into multiple components. this is the front end, right? and the presumption
is there's a whole bunch of backend stuff that's happening here.

Manu Sporny: Okay, we'll this one or…
00:45:00

Joe Andrieu: I'm not sure you should break it up,…

Joe Andrieu: That diagram was already complicated enough. No, the one with
all the components on it.

Manu Sporny: you mean the …

Joe Andrieu: And if you swap out every coordinator for two parts,…

Manu Sporny: yeah. Yeah. absolutely. Yeah. I completely agree. I think what
we're going to try and do is we're going to try to even simplify this
diagram and…

Manu Sporny: just talk about one component at a time. I don't know. I think
there's future work to be done on simplifying this diagram if possible.
yeah.

Joe Andrieu: Yeah, plus one of that.

Joe Andrieu: So, I'll let you come back with some imagination.

Manu Sporny: What do you mean me, Joe? I thought it was going to be you.

Joe Andrieu: I heard a wei in your statement.

Manu Sporny: All we know that work needs to be done there. we can draw
straws on who's doing the work later. okay.

Manu Sporny: So this is low effort and ready for PR. All right, that's that
one. And then specify optional client profiles to provide multiplexing.
Joe, I'm going to run to your one first. This one feels like it's low
effort and ready for PR. group discuss. yeah, I think you specify what the
PR should be up here, Joe. So we can just take a shot at that and go from
there. Okay, last one left. We've got six minutes left.

Manu Sporny: Dave, help us through this,…

Dave Longley: So,…

Manu Sporny: this one.

Dave Longley: in some versions of OID forVP, that's open ID for verifiable
presentations. in some versions of that and in some versions of profiles
that use it such as ISO 18013-7 which is for a protocol that is specific
for presenting MDLs mobile driver's license and mobile documents there are
certain requirements in some of those specifications such as certain client
ID schemes and the URLs that you pass to digital wallets to trigger and use
these schemes. They make it so that you need to present to wallets
different options.

Dave Longley: so if you were to create an exchange, as an example, if you
were to create an exchange and you wanted to ask for from a digital wallet,
either a verifiable credential expressed, a driver's license expressed as a
verifiable credential or a driver's license expressed as an MDL, and you
wanted to ask for either of those, you're willing to accept either. that
exchange has to be able to present itself in different ways. And in order
to enable that there's a concept of client profiles that's presented here
that can enable it to happen. Otherwise you can't use certain standards to
accomplish this task.

Dave Longley: So the main goal is make it so that you can put out an
exchange so that you can create an exchange so you could accept either one
of these things and be able to comply with the standards that have been
designed to present those things. And so that's what this R is about. It's
about adding an option called client profiles. If you have an exchange that
implements OID for VP and if you want to ask for certain verifiable
credentials or allow a wallet to choose to present an MDL on the same
thing, you need to be able to specify different profiles to present the
wallet. That was a lot to take in, but that's the gist of this.

Manu Sporny: Is this if you want to ask for an MDL and a verifiable
credential at the same time, you need this feature. I want your MDL to so
that you can prove that your license to drive and I want a vehicle
registration to prove to me that you and the vehicle registration is a
verifiable credential in the MDL is the driver's license.

Manu Sporny: Is that what this feature is for?

Dave Longley: No, it's a little more complicated than that.
00:50:00

Dave Longley: So, this is so if you wanted to do that,…

Dave Longley: I don't think that that's something that's supported with ISO
180 13-7 today. So, I don't think you could present both at the same time.

Manu Sporny: That's right.

Manu Sporny: So, you can only use Dackle. The thing I was talking about,…

Dave Longley: Yes. The thing that correct…

Manu Sporny: you need to use Dackle

Dave Longley: if you want to use oid for VP and you want to present
credentials of different formats, you need to use oid forVP version 1.0 O
and use the DALE language DCQL. If you want to use the ISO standard to
receive an MDL and you want to allow a wallet to present either a
verifiable credential driver's license or an MDL or maybe some other
variety of credentials.

Dave Longley: the ISO 18013-7 doesn't let you combine that in the same
request from oid forvp because it's built on draft 18 of oid forvp. and
since you can't ask them in the same request and you have to generate a
different authorization request to make it work, then you need a way to
sort of profile that so that a wallet can either choose and it's really an
issuer.

Dave Longley: It's really a verifier coordinator is going to somehow know
whether to offer a MDOC exchange or to offer the MDO protocol or to offer
the oid forVP protocol. And by having this client profile mechanism,…

Dave Longley: they can offer both of those. That's what it's for.

Manu Sporny: Getting the hint that this ISO 1803-7 and…

Manu Sporny: no ID4 VP were not thought through. is this ready for PR?

Dave Longley: Yeah, I think so.

Manu Sporny: I don't know if I know…

Dave Longley: I put a couple of …

Manu Sporny: what to do. Yeah.

Dave Longley: I put a couple of JSON schemas in here for what could go into
workflow step to support this. So, if you have these schemas in there and
you have these properties in here, you can implement an exchange that would
allow you to ask for one or the other while also being ISO 18013-7
compliant. So, that's really the key there. If you want to ask for either
of these and you want to be ISO compliant, you need this feature. If you
don't care about that ISO compliance and you're able to use a newer version
of OID for VP that isn't ISO compliant,…

Dave Longley: then you can ask for both of those things or either of them
in the same request. Otherwise, you can't. So this feature is really here
because if you want to be ISO compliant and flexible with the wallets that
your system talks to, you need this feature.

Manu Sporny: got it.

Manu Sporny: I am trying to think of what I'm going to put this as effort
high primarily because it's kind of like whoever is doing this is probably
going to need to understand either talk with someone that has had to
implement this which I think Dave you might be the only person on the
planet that has had to actually make all these systems

Manu Sporny: work together. or they're gonna have to go and learn the spec.
so I'm going to say this is ready for PR. Effort high. I will try and
tackle it. I will probably have to talk with you for hours to figure out
what to actually write into the spec to get this to work. Okay.

Dave Longley: Yeah, I will say most of what needs to happen in the spec is
just updates to the schemas for a workflow step with what's in this issue.
making all those rest of those details work in an implementation is it's
same level of effort as any of the other things that are in the spec today.
that might not be strictly true about doing this, but we don't speak to in
our spec today. We just say these are the primitives and inputs you need to
make something work, and then you can take that information and implement a
protocol. And that's the same thing we're saying here.

Dave Longley: It's just to implement this protocol, it's a little more
challenging.

Manu Sporny: Yeah, I mean it feels like we're injecting a giant hack into
and…

Manu Sporny: not it's a hack created by ISO 18013-7. So it's a hack created
by the ISO working group. We're injecting this giant blob hack thing into
the specification and it is going to be rendered as f five pages of
guidance to an implementer, right?
00:55:00

Dave Longley: It is an ISO standard and there are a number of people who
are implementing that and a number of people who are implementing
verifiable credentials verifiable or…

Dave Longley: digital driver's licenses expressed as verifiable
credentials. so given the ecosystem, anyone who wants to work with either
of these would benefit from this feature and advice on how to do

Manu Sporny: Yeah, I'm wondering…

Manu Sporny: if we just bury it in an appendix somewhere. All right. I
think it's a little clearer to me what, would need to happen there. We are
three minutes Apologies for that. yep, we could also do it as a separate
speck or note, Benjamin. We'll have to figure out where to do that. that's
it for the call this week. Thank you all very much for the time and
intention today.

Manu Sporny: if there are a bunch of loweffort PRs, so if any of you are
looking for something to do over the week or the weekend, please feel free
to take some of these. reminder to fill out the poll if you haven't
already. and we will meet again next week to discuss PRs and changes that
come up over the next week. Thank you everyone. Have a great rest of your
day and a great rest of your week. Take care. Bye.
Meeting ended after 00:56:51 👋

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