[MINUTES] VC API 2025-09-23

VCALM Meeting Summary - 2025/09/23

*Topics Covered:*

   - *Verifiable Credential Working Group (VCWG) Priorities Poll Results:*
   The poll (40 responses) strongly favored prioritizing work on the
   Verifiable Credential API for lifecycle management. While other items
   received support, VC API had the highest impact rating and significant
   implementation interest. This will likely be included in the next VCWG
   charter proposal.
   - *Pull Requests (PRs):* Several PRs were reviewed and discussed,
   including:
      - PR525 (Eric Schuh): Updating tables in the spec; linking to
      sections planned for a future update.
      - PR549 (Kayode Ezike): Defining reserved exchange variables;
      discussion focused on clarifying the results schema and adding a step
      template example (future PR).
      - PR550 (Eric Schuh): Adding YAML support for interaction mechanism
      endpoints; ready for merge after minor updates.
      - PR554: Warning against putting protocol details in interaction
      URLs; advocating for short, concise URLs.
      - PR555: Warning about unknown proof types in security
      considerations; preventing exposure of holder secrets.
      - PR556 (Kayode Ezike): Adding an issueRequests field for defining
      credential issuance in workflow steps. This requires
clarification and will
      likely need a future PR for a step template example showing
usage with the
      VC API.
   - *Issues:* Discussion centered around adding examples for OID4
   integration with the VC API and other interaction mechanisms. A callback
   URL mechanism for workflow steps was proposed, allowing asynchronous
   notifications, with a focus on minimizing complexity. The need for better
   structuring and clarity in the specification's introduction, architecture,
   and workflow sections was highlighted.

*Key Points:*

   - The VC API for lifecycle management is the top priority for the VCWG.
   - Several PRs are progressing towards completion, requiring further
   review and minor updates.
   - The spec's complexity, particularly in workflow configuration, was
   discussed, with YAML suggested as a potentially more user-friendly format
   for human editing, while JSON remains the API standard.
   - Appendix sections will be added to the spec with examples showing the
   interaction with OID4 and other protocols. Additional examples are needed
   to fully illustrate workflow steps.
   - A simple callback URL mechanism was proposed and accepted for workflow
   step completion notifications, prioritizing minimal complexity and avoiding
   authorization overhead. Future additions may include more parameters.
   - The specification's introduction, architecture, and workflow sections
   require significant restructuring and improved clarity.

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

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

Dave Longley, Eric Schuh, Joe Andrieu, John's Notetaker, Kayode Ezike, Manu
Sporny, Nate Otto, Otto Mora, Parth Bhatt, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right. Hey everyone, let's go ahead and get started. we
were I think expecting Dimmitri as well today. Hopefully he'll be able to
join in Coyote. but let's go ahead and get started with just the
boilerplate and then we can move on to the poll request for all so the
agenda for this week is basically to cover the results of the verifiable
credential working group priorities process some poll requests and discuss
any issues that might need discussion to raise poll requests. there are a
couple of things that we've marked as ready for PR that I went and I tried
to write PRs for them and I was like I don't know what to write here.

Manu Sporny: So, we will want to cover any update? Anything else we want to
discuss today? All right. with that, let's go ahead and talk about the
priorities poll. I will just focus on the results for C API stuff. so we
did get good feedback. we got 40 responses which is good data. largely they
came from people that have been pretty deeply involved in the ecosystem.

Manu Sporny: meaning that the people that were filling the poll out knew
what they were talking about and understood probably the implications of
each one of the things that were being kind of rated. so I think we got
good data. I did provide kind of thoughts on the poll to the mailing list.
I won't go over those here. but happy to hear other people's kind of
interpretation of the data.

Manu Sporny: there's multiple valid ways to interpret this data. but going
down to verifiable credential API for life cycle management. this was by a
slim margin the most supported work. I think there's arguments that maybe
we could look at the data slightly differently and something else came out
on top but VC API was very much very strongly favored. no one is saying
it's unimportant or not really important. most of the other things got some
hits down here. this item didn't. And then on top of it, there were 20
people that said it had the maximum amount of impact of the VC ecosystem.
so that's good. and was a little surprising to me.

Manu Sporny: I didn't think as many people kind of understood what the VC
API work was about or thought it was as important as it is but that's a
good signal. about 3/4 of the people said that they will depend on VC API
if we finish it meaning they'll implement it they'll use it they'll
recommend the use of it that sort of thing. and we got a healthy number of
people volunteering to be editor on the specification. so overall, good
signal. what this is probably going to mean is that, we're going to put it
in the next charter proposal. I am unfortunately expecting formal
objections on it. but we'll see. I hope I am wrong there.

Manu Sporny: and then it'll take couple of months for the formal objections
to be worked out but that doesn't slow our work down here. We can keep
going until it's put in scope. We are making a good healthy progress on the
specification both in mashing issues down in doing implementations. as I
said in the email probably over incubated this specification it should have
probably gone under the standards track a little earlier but anyway good
position to be in good feedback. Let me pause there see if there are any
other questions or insights or thoughts people wanted to share on the poll
results. go ahead Dave.
00:05:00

Dave Longley: Yeah, I want to make a general comment about the poll results
that I don't think the absence of many other options on here that other
people that whoever responded to the poll might have thought were less
important should mean that the fact that what was in the poll everyone kind
of generally thought was important to do. And there's a spectrum for each
of those items that's in the poll. But generally speaking, what was in the
poll were things that we expect that I expected people to think were
important in the community. because these are all specs that have been
incubating and things that people have been working on and they're probably
the furthest along. That already signals that there's probably support for
them.

Dave Longley: But, I imagine there could have been a lot of other ideas and
things that could have been put in here that people hadn't thought about
and then you probably would have seen greater differentiation. But I think
the criteria for what went into the poll was already things they've been
work items in the CCG for I think every single one of them was at least a
year or…

Dave Longley: more in the CCG as a work item.

Manu Sporny: Plus one to that.

Manu Sporny: And to give a balance there were things that got lower the VC
over wireless thing. I mean there were only 12 people that said it was very
important. and then you kind of see the shift down. I'm trying to think of
the quantum safe stuff there was strong support 20 same as the VC API but
then you kind of saw this drop off here where people were just kind of like
maybe not as there was a more different opinion here. but yeah plus one I
think that's right.

Manu Sporny: We didn't have a really bad idea in here so that we could take
a measurement of how strongly people would rate that bad idea. should have
probably put in some kind of direct phone home spec that always calls back
when you use your credential and see how that would have fared. yeah, plus
one I agree. I think a lot of people just support most of the work that's
been incubated. any other thoughts before we move on? so that's the poll
result. We have sent that over to the VCWG chair and the staff contacts.

Manu Sporny: I am sure we will talk about this at the next VCWG meeting and
my expectation is that shortly thereafter we'll draft a new charter for the
VCWG which we would then maybe get input at TAC and things like that.
probably too late to get a vote in on that unfortunately. So, okay, back to
our agenda. Next up is, pull requests. so let's go ahead and com pull that
up. I will note that I did refactoring of the table of contents.

Manu Sporny: we had a bunch of stuff just slammed together in the front
part of the spec. It was just all kinds of things and not in any particular
order. So, I tried to lay the spec out to talk about an introduction,
design goals, rationale, architecture overview. So, Joe, Eric, I took kind
of the architecture overview here and kind of stopped it at this point,
right? and just said, "Here's the overview of the architecture." And then
split all the rest of the stuff, discussion about coordinators and services
and instances and configurations down into a more detailed section on
architecture. to kind of go over these things, it is imperfect.

Manu Sporny: I would appreciate, at least both of you taking a look at it
and thinking about how we might, lay it out more effectively. but it seemed
to flow fairly well here. I did add this new concept, a new section on
instances because we were talking about instances, but we didn't really
call them out. And then this thing around configurations, how you can
configure the software, the base how you do authorization, oth, the options
that you send to the endpoints, how things are serialized, payload sizes,
this thing pro we mention payload sizes twice in the specification, once up
here, and once in security considerations. So, we should probably try and
compress that.
00:10:00

Manu Sporny: So just a heads up that there was significant kind of
restructuring here and then, we get more and more detailed as we get into
the specs. So then we talk about the HTTP API and…

Manu Sporny: then all of the components and the tables here. Eric, I'm
sorry. I probably messed up your PR with it It might not be, but hopefully
Okay.

Eric Schuh: Yeah, I'll make sure to check.

Eric Schuh: It's still in progress, so I'm working on it this afternoon.

Manu Sporny:

Manu Sporny: Great. And then we go into verifying, requesting, and
presentation and so on so forth. So I think that structuring is better than
it was, but it still needs improvement. so please help if you have the time
for So let's go into oll for the pull requests. I'm going to skip this one…

Manu Sporny: because Eric, I think you're currently working on it, unless
you want to go into the PR525.

Eric Schuh: No,…

Eric Schuh: I mean I could just give a quick update. So, I merged all of
the suggestions in the Google doc that's linked in the comment thread in
that PR. so the Google doc currently reflects what I plan on updating the
tables to be. I'm still working on the PR. So, if anyone gets any
additional comments or changes into this Google doc before I,…

Eric Schuh: finish, I'll obviously try to incorporate them. If not, we can
do, minor PRs afterwards to correct anything.

Manu Sporny: Excellent. Awesome.

Manu Sporny: That's great news and thank you very much for working on that
and updating the tables. what I was also wondering, this is not for this PR
Eric, but maybe what we could do is link to the sections. Sorry, I know I'm
clicking all over the place. I lost my spec. let me rec so in the spec we
have this stuff…

Manu Sporny: but we should probably link to the section that it's defined
in the table. yeah,…

Eric Schuh: That shouldn't be too hard.

Eric Schuh: I can take a look as I'm finishing up this PR and if it feels
easy, I'll just modify the tables in the current one and if not, I'll leave
it for a future PR

Manu Sporny: that to totally fine. It's nice to have. but I was just hit
struck me as I was looking at this section and I was restructuring the
other stuff. And thank you very much, Eric, for working on that API
component table all anything else on PR 525 before we move on to All Next
PR is PR 549, define reserved exchange variables. Coyote, do you want to
give us an update on this one?

Kayode Ezike: So, I addressed a number of the feedback comments that I got
that I can recall. Basically, mostly just removed the inputs field that was
originally the variables as well, added a last error field to the exchange
schema. I saw that there was some feedback around that I'll address soon.
and then other just editorial things that I've started to incorporate. I
also just earlier today added an example of a sample like workbook config
just so that I just feel like it useful to have an example of that. So I
added that as well because that was also something that was mentioned in a
few issues in the past. So yeah that's mostly the update that I have.
00:15:00

Kayode Ezike: So, right, the other thing I wanted to say, so I made a
comment as well that I think is still not been addressed. this is around
the results schema and let me just see. So, not sure if you have it open.
So, if you were to look for in the conversation section for let me see how
I can search for it. One second. So, Let me just get a link to it. So, if
you can open that. So, all right. So, yes.

Kayode Ezike: So last week we spoke about the reason why the inputs fields
are necessary which makes sense to me right we basically can just reference
that from the issue request property and then just have the coordinator
send the appropriate data to the appropriate variable properties for the
results field is a little bit unclear to me how that's supposed to be
referenced because I think at

Kayode Ezike: the use case that stands out to me as an obvious one is,
potentially hard coding some potential fields like verify presentation
response or challenge even embedding that within the BPR response, but it's
not clear to me how you would enable the ability to put arbitrary fields,
which is something that was referenced by Dave somewhere. being able to use
fields from previous steps as X and Y inside of results. I think that is
still ambiguous to me how exactly that something like that would work. So
that is there. I don't think it'll change necessarily. I guess it wouldn't
really change the text of this k I don't think but I think it would still
since we're talking about it be good to

Kayode Ezike: f***.

Manu Sporny: Okay, thank you Cody.

Dave Longley: Yeah, I was typing up just a really quick example which I
will put on into the issue there so that we can show that so that that'll
be there in just a second on the screen. If you refresh that mono, I think
there should be a reply this just off the top of my head, something I just
threw in there. If you had a template somewhere in your credential requests
or you could put this in a VPR as well, you could reference since results
is written.

Dave Longley: And I looks like I messed up some syntax in there. But since
results is available in your variables for your exchange after your first
step and you've written the result in that step. Yeah, thank you Monu. you
can then reference any variable in there to put something into your next
step.

Dave Longley: You can put it into a credential template. You could put it
into another VPR for the subsequent step for something else you're going to
request. whatever it is you would like to do.

Kayode Ezike: kind of I think I mean it's still how do I put it? so I guess
you're saying the workflow configuration, it has something like this where
it references the results and it has a step name and it has the data
expects to be there. I guess my question is you had mentioned that this can
be like the property after step name. You mentioned that that can be
arbitrary, right? I recall u in the com.

Kayode Ezike:

Kayode Ezike: So how would that something like that …

Dave Longley: It can be arbitrary,…

Dave Longley: but it's decided by the workflow designer. So, if you scroll
up to your example I think you have to in the PR that you just made,
there's an example that has some steps in it. it might be a different tab
for that.

Kayode Ezike: index html file should have an example workflow in there.
00:20:00

Dave Longley: But if we go take Yeah, I think there's something in this one
that you just added. And is there a template in here?

Kayode Ezike: Where is Yeah.

Dave Longley: There's not a template for the step. So, if you make your
step a template, you can use the step template property for that.

Dave Longley: Then your step will be generated from the variables as well.
So you can have your second step for example use a step template and it
would include in those results. And since you're designing the workflow you
get to pick what the step names are. They're only arbitrary with respect to
an observer. Whoever's building the workflow is going to say what those
step names are because they're building it. So they'll pick them and when
they pick them they would know what to reference in their steps. So you can
see from this example you picked some step names like credential delivery
and did all something or other I think were the step names that you picked.

Dave Longley: And so you would know what they were.

Kayode Ezike: So maybe then what I wouldn't need and something else I can
add is a step template example as well or would that be too much to add to
this?

Dave Longley: We should definitely have one in the spec. It doesn't have to
go in this PR, but that might be a useful way to show how to use it. It
could be a follow on PR or this PR. That's good,

Manu Sporny: think we have an issue to add a step template example meaning
we can do it in another PR…

Kayode Ezike: Okay.

Manu Sporny: unless it's easy for you to do it in this one coyote then we
can close two issues but I think one of the questions I had today was like
I don't know how to do a stat template can we have an example all right
thank you coyote it's a lot of work so much appreciated there are some
things that are you still working on the PR or…

Kayode Ezike: All Sounds good. Yeah. how to respond to editorial stuff and…

Manu Sporny: are we trying okay all right we'll come back to it next week…

Kayode Ezike:

Kayode Ezike: what we just discussed now. So yeah.

Manu Sporny: but thank you for continuing to move that one forward it's
defining a good part of the spec that was missing all right next PR up is
go ahead Dave

Dave Longley: Before we move on to that one, when we do that step template,
it might be a very useful thing to show how you can use the VC API to
request credentials and then issue, which is a common use case that comes
up. and so it would be good to and you could also in that step template
reference the credentials that you had verified in the previous step to
include information in this subsequent request. and it would be good to
highlight that, not just have a step template example, but highlight how
you would do something like that with the API. and then for bonus points,
if we could figure out how to say and…

Dave Longley: with the same workflow, you can do this with a combination of
oid for VCI and oid for VP. but that might be asking a lot all at once.

Manu Sporny: Yeah, we also have issues that I was not able to write PRs for
that were asking for full OID4 VCI and…

Manu Sporny: OID4 VP flows. I think we probably need an appendix to
highlight here are the back and forth flows and then here are the messages
that are passed back and forth to just make it crystal clear about so
people have some solid examples to go off of work for later but I think
that's probably where we end up putting a lot of this stuff is because
otherwise the spec just gets junked up with all kinds

Manu Sporny: gigantic JSON objects that are really hard to read. anything
else on PR 549 before we move on?

Manu Sporny: All right. PR 550 is Add YAML to support the interaction
mechanism endpoints. Eric, do you want to take us through this one?

Eric Schuh: Sure.

Eric Schuh: So, not too much has changed from last week. I basically just
came in and fixed the YAML errors that the llinter was giving. and then
also incorporated Ted's one language suggestion. so I think this is ready
to go.

Manu Sporny: Okay, you've got a couple more requests.

Eric Schuh: Unless you know.

Manu Sporny: I think Nate just added something five minutes ago and…

Eric Schuh: Okay.

Manu Sporny: Ted I think has one from an hour ago. but other than that,
you're feeling I mean I think these are Nate's requests looked fine and
then Ted's request looked fine as well.
00:25:00

Manu Sporny: So maybe once you make those modifications, we can just merge,
over the weekend or something. Okay.

Eric Schuh: Okay. Yeah,…

Eric Schuh: sounds good.

Manu Sporny: Let me make a note of that so I remember to do it.

Manu Sporny: All Okay, great. thank you, Eric, for working on that one.
next one. yeah, I just opened these a little bit ago. we won't merge today
but we need some reviews on them. there was an issue that we wanted to warn
people not to put stuff like protocol details in the interaction They're
meant to be small and compact and that sort of thing.

Manu Sporny: I think it's a don't do what oid4 did which is slam a whole
bunch of stuff into the query parameter and all of a sudden there have been
some issues with the amount of stuff that was being shoved into the URL
there. So, we're basically saying keep interaction URLs short and tiny and
absolutely don't put anything in them that can go into the object that's
passed back because the object that's passed back, can be very large in
size and you're not going to run out of things in it. so that's more or
less what this does.

Manu Sporny: so please review. I don't know if we really need to talk
anymore about it. so that was PR554, a warning against putting protocol
details in the interaction next PR is PR55, add a warning to unknown proof
types to security considerations. This was an issue that Dave Longley
raised a while ago to basically just warn digital wallet implementers that
they shouldn't just throw proofs across the wire if they don't know what
the proof is or means.

Manu Sporny: so specifically if you have an ECDSA SD proof and an ECDSA
proof and you only understand the full disclosure ECDSA proof, don't also
include the BBS one and the ECDSAD one in there because by doing that
you're going to end up sharing a whole bunch of information you're not
supposed to share. There's supposed to be holder secrets in there that
you'd be exposing. So, this is effectively exactly the text that you
provided longly. I need to remove the committer thing there. but yeah, it's
basically your text longly. So, if folks can review, that should be what we
need here. any comments, concerns on this one?

Manu Sporny: I think most of us know not to do this, but we're just making
it explicit. that is the last P then. the go ahead, Cody.

Kayode Ezike: So, if you refer to your page, you'll see there's actually
another PR that Len did that's in draft right now. but I figured it could
be worth just calling out.

Manu Sporny: Yep. Yep.

Kayode Ezike: Something's coming up soon. So, the purpose of this, this was
from a issue I put up some months ago and really was a desire to understand
what's the exact structure of templates field. I think since then we've
kind of had gotten a good understanding of that. But what also came out of
that is the need to define another field which was issue requests. and so I
added a definition for that as well.

Kayode Ezike: essentially this is a field that's needed for steps that
issue credentials that point to a particular template by ID or index in
some cases and optionally also provides either its own locally scoped
variables or variables reference from the exchange and so by string by
field name and you'll notice that this is dependent on the other PR that
I'm doing…
00:30:00

Kayode Ezike: because it references exchange variables which is defined in
that other one. So that one is a prerequisite to this one. Let's make sure
folks were aware of this because I feel like it's being used already by
some already and it's just good to at least let people know that's coming
up. That's the way that you're supposed to define how a step would issue
credentials.

Manu Sporny: Okay, got it.

Manu Sporny: Got it.

Manu Sporny: That is very helpful. Thank you. I don't think I've seen or
been exposed to this yet. what is issue requests expressing?

Manu Sporny: What's the semantics of this?

Kayode Ezike: Yeah. …

Kayode Ezike: so basically it goes under so the steps step name like that
scope…

Manu Sporny: Mhm.

Kayode Ezike: where it goes and it's supposed to just be an array of the
credentials that define basically that are supposed to come out of that
step. So, it's an array of objects. it can have an ID an index depending on
how you want to do it. And then it'll basically just tell you,…

Kayode Ezike: okay, which credentials do we want to release of the values
that are the credential templates field that's in the workflow. So,
basically just…

Manu Sporny: …

Kayode Ezike: how it works. Yeah.

Manu Sporny: meaning all of these are going to be issued at during this
step. Is that what you're saying? Okay. Go ahead, Dave.

Dave Longley: Yeah, that's kind of how I was going to describe it. it is a
set of instructions for VCs that are to be issued during this step. So, the
step processor will take these issue requests and…

Dave Longley: send them to the configured or there could be multiple
configured issuer instances and…

Kayode Ezike: Yeah.

Dave Longley: issue these credentials.

Manu Sporny: got it.

Manu Sporny: Okay. makes sense. just thinking out loud we're not quite well
yeah I don't know if we're moving ever closer to a domain specific language
here right it's like we've got some pretty sophisticated things happening I
don't think we're there yet but I'm wondering at what point we get there
and if we're concerned about it. and whether or not the best way to display
or work on this stuff is through YAML and not necessarily through JSON. I
don't know if either of you have put much thought into that.

Manu Sporny: because the reason I ask is there was something with the VC
API that I was working with and it was just like forest of JSON deeply
nested structures where I was just like I can barely read this and then I
put it into a YAML format and I was like wow yeah the structure is so much
simpler I can actually understand what's going on here and it was just an
easy switch from one to the other. So I'm wondering and again I don't think
we've really talked about this yet. I'm wondering if one we're concerned
about the complexity of the configuration language here and two are we
hitting any issues with providing it in JSON versus YAML or if is that even
a concern right now? Go ahead Dave.

Dave Longley: I think you're highlighting maybe a different layer like
that's the human interaction layer with designing workflows.

Dave Longley: I think clearly the API should continue speaking JSON, but if
people want to create tools that take as inputs or allow you to work in
YAML or maybe even provide some other higher level user interface, all of
that sounds good and helpful for humans. I'm not quite sure what the
question is that's being asked, I

Manu Sporny: No,… that's fine. I mean the question's vague because it's
just general uneasiness about if a developer has to hand edit this stuff I
think they're going to have a hard time for anything other than the
simplest flows right and one of the ways that's dealt with is the developer
isn't exposed to the entire configuration object all at the same time. But
I think in this case that is kind of what's happening.

Manu Sporny:
00:35:00

Manu Sporny: and so I'm wondering what the typical and we'll have to get to
this in the appendex, but if the typical configuration for this stuff is
like 10 pages of JSON, I'm concerned about developers finding it too
difficult something of that nature. and again, I don't have a counter
approach, It's kind of like, I don't know what the alternative would be
other than just put a good UI in front of it. we've got massively complex
systems that humans have to use and if you tried to serialize those
whatever those things are to a flat file, it would be, megabytes in size.
go ahead Dave.

Dave Longley: Yeah, I think certainly if you're handwriting these things,
YAML's easier than using JSON. that's why it exists. but I don't know how
common it will be to handw write these things. can be part of a step
template and you could have your issue requests themselves be a variable
that's autogenerated through some other means. So there's a lot of
different ways to put different interfaces in front of it. so I think
what's important is that we capture the minimum number or amount of
parameters that we have to accomplish the goals to have all the primitives
you need to build these workflows. and then better interfaces can be put on
top of actually constructing the data that goes into

Manu Sporny: Plus one to that was just a idle thought about this stuff.
thank you Coyote for this PR as we'll let it hang out there until the other
one gets merged and see if anyone has other input on it, but it looks
pretty straightforward so far. that is the final PR. that was PR 556. All
right, let's jump into issues in the remaining 15 minutes or so. we have
issues that need discussion. Three of Dimmitri is not here. Some of them
are his issues. So let's skip it until we have Dmitri here.

Manu Sporny: there were a number of things where we needed examples. So
let's do this one. So I should refer to oid4. this was Christina Yasudo was
asking for details on how we use oid4 with this. We last summer in 2024
said that we should provide examples on how to use VPR over all ID4 and
over Chappie as well as over VC API exchanges.

Manu Sporny: I think this is a appendix that probably needs to be written
and it needs to be written by somebody that can effectively get a protocol
dump of an exchange. which is probably not me. Do we have anyone that would
be able to kind of add an appendix with an example of ID4 VP for example?

Manu Sporny: Go ahead Dave.

Dave Longley: Yeah, I don't know when I can get to it,…

Dave Longley: but I can generate such a thing generate the messages that go
to and…

Manu Sporny: Okay. Yeah,…

Dave Longley: then we can figure out how to get that in the spec.

Manu Sporny: if you do that, I can add it to the spec. I just need the
examples only to generate example protocol messages right into
specification and an appendix of protocol flows examples. Yeah. And I think
we just put all of that stuff, we dump all of it to the bottom of the spec
because it's going to be verbose. great. thank you for that's that item.
questions regarding query by example. That's something I need to do. this
one has a PR already.
00:40:00

Manu Sporny: Maybe it was this one that let's see. Yeah, this one was raise
a PR that details how OID4 can be integrated with V VC API exchanges. So,
this is just that this is probably a duplicate of that other one at this
point. so, let's see. 537. this is a duplicate of 537. I'm going to close
this one because this is a big meandering discussion here. and the other
one's more specific about what we need to add. So, it is ready for PR.

Manu Sporny: All right. So, that one is closed because it's a dupe. same
thing. Call back URL to exchanges. this one I was confused about because
come on, GitHub. You can do it. There we go. okay.

Manu Sporny: So Dave you provided kind of callback URL and then there's
something posted back is so the first question is this what we want to put
in the specification?

Dave Longley: That is my proposal.

Manu Sporny: Does anyone have a counter proposal or would like to do it
differently? we're not committing to this. It's just, we just trying to get
something in the spec and then we can bike shed names or whatever or does
anyone have objections or serious concerns about this approach where
basically this is to put a call back I think it's in an exchange step. no,…

Manu Sporny: what is it So in each step you can have a call back. Yep.

Dave Longley: That's right.

Dave Longley: In a workflow step, yes. And that it can be populated by
variable. So when you're creating the exchange, you can provide the call
back URL that will be used in whatever step you want to have a call back
in. And when the step processor sees that call back, when the step
completes, it does that an HTTP post to that call back with that data. And
this keeps it as a very minimal ping back service that should not in theory
require any authorization to use that callback In fact, you can make the
callback a capability URL that's bound to the exchange which solves a lot
of problems.

Dave Longley: so you don't have to worry about giving your workflow service
like o ooth tokens and access tokens and refreshing them anything of that
nature. because the payload is so small, you also don't have to worry about
opening up special firewall rules to ping back to coordinator systems. So
the design is around avoiding all those big constraints that create
problems in big deployments and production environments. And if you hand
over the exchange ID to your capability that should be enough information
for that other system to do whatever it wants to. And once it responds with
a which could be fast or slow depending on whatever design you want, the
workflow will continue.

Manu Sporny: Excellent. Thank you for the explanation. do we want to
support an array of URLs or just one?

Dave Longley: I think if you have an array of URLs, I don't think what to
call. And I think if you want to hit a system,…

Manu Sporny: All of them.

Dave Longley: yeah, you would call all of them. But I don't think you need
to put that complexity in the workflow service. I think you can hit that
URL and…

Dave Longley: then that URL can hit other URLs if that's the system you
want to have.

Manu Sporny: Okay. …

Manu Sporny: all And the property names we're okay with. So, I guess let's
see. It's going to post the exchange ID here.
00:45:00

Dave Longley: It posts an event. Yep. If you want information on the
exchange,…

Manu Sporny: It's going to post an event, but you have to go and get
something from here if you want to figure out

Dave Longley: you can get whenever you want to. You don't have to do that
in the middle of your callback, which allows it to be fast. You can go
fetch that. this can be used as simply a refresh your polling service to go
ahead and pull something new if you want to. That's the simple ending.

Manu Sporny: And then the use case here is a human being is going through a
manual process and then you don't want to keep polling for the 15 minutes
the human's doing the thing. You just want a ping when they're done.

Dave Longley: Yeah, I would yeah,…

Manu Sporny: As an example, I mean,…

Dave Longley: I would tweak that a little bit to say you've got…

Manu Sporny:

Manu Sporny: it could be used for all this. Yep. Got it.

Dave Longley: if you want a robust system, you're going to have to pull
anyway because you might fail to receive this message for any number of
reasons. But, you can speed up that process or know that it's safe to pull
again when you've received a push message that says the exchange has
changed.

Manu Sporny: Go ahead, Nate.

Nate Otto: I can think of several different use cases for extra data that
might be nice to have inside the callback. And one of those is the state
parameter. Of course, tell me, what the progression of states is and I will
go and do the work of fetching the full state once it reaches complete. I
imagine that would be a slippery slope of adding more stuff. And I see the
sense in putting nothing in here other than the exchange ID, but there may
be a few things that are also worthwhile.

Dave Longley: Yeah, for the specification I left that intentionally out
other than the bare minimum so to avoid that slippery slope sort of thing.
systems might experiment with this and find that it's really helpful to
have that one state field and maybe that's good enough and that could be
added to the spec later. but I didn't want your concerns that you just
highlighted were the same ones I had. I don't want to overengineer it to
begin

Manu Sporny: So, with that said, Nate, are you okay with us just starting
with this and then we can raise other issues if folks want additional
parameters or whatever in the future? Okay. Thumbs up from Nate.

Nate Otto: Yes.

Manu Sporny: Okay. all then this is literally the thing that'll be put in
the all right. So PR should be group this on the 923 telecon and agreed
that the example above is which should be raised adding the example and OS

Manu Sporny: Definitions example above. Go ahead Cody.

Kayode Ezike: Yeah, I just wanted to mention that they've also mentioned
the possibility to include variables in there. So maybe you should add that
to include text on that as well.

Manu Sporny: Text the talks about the usage of variables in the event that
is sent back. for an example, a capability included in the URL was
generated from a previous step something like that.

Kayode Ezike: Yeah, I think so. Yeah.

Manu Sporny: All right, we'll do that. 523 minutes left. Let's see what
else we can get here. we need a presentation definition. This might be
overcome by events. Yeah, it's either my connection or there's a stuck
server at GitHub or rather a stuck cloud. There we go. yeah, this one I
didn't know what to do with. So, this is super old.

Manu Sporny: It's from the VPR spec from two years ago asking what the
difference is of the mediated browser presentation. So this is the
interactive thing and then an open ID thing would look like. we said we
should document the interaction types that are used today with examples. I
think this is the same thing as we should add some examples in an appendix.
and then we said, there are multiple different OID4 profile variations. I
don't think we need to say anything about it. at least I'd rather not get
into all of the complexities of OID4 in this spec. and I don't think we
need a registry.
00:50:00

Manu Sporny: So I think this is probably just show an example of OID4 VCI
and OID4VP over VCOM. Go ahead Dave.

Dave Longley: Yeah, I agree. I think at this point it's kind of the
interaction URL and returning a protocols object has replaced what this was
originally referring to.

Dave Longley: And if we have examples of how to take advantage of those
things both from an implementing them at the end of an exchange and then
using them as an exchange client. I think that covers everything. I think
we should certainly have an example with oid forvp that shows…

Manu Sporny: an appendix.

Manu Sporny: I guess let's be specific. which examples do we want in here?

Dave Longley: how to expose the necessary authorization request and
response end points on the end of a VC API exchange and how to use that and
there's something similar for oid for VCI

Dave Longley: We should certainly do those two since both of those
protocols I are becoming open ID specifications.

Manu Sporny: And this is also a partial duplicate at this point. It's
basically show us how to do OID4 over ECOM.

Dave Longley: Yeah, we don't already do it. the invite request protocol. We
might already have this in the spec from now on.

Manu Sporny: We have a couple I mean I think…

Dave Longley: And that would just be another example of another in
interactive choice you can

Manu Sporny: what we've got multiple diagram examples, and we have partial
examples…

Manu Sporny: but we don't have full flows yet.

Dave Longley: Yeah, I think we just want a full for the invite request.

Dave Longley: We would also just want a full flow that probably has most of
the content that's already in the spec, but it's,…

Manu Sporny: Yeah. Yeah.

Dave Longley: here's the protocols for it and here's where you post the
response and that's what the messages look like and…

Manu Sporny: Yeah. we have this,…

Dave Longley: and where you post the response.

Manu Sporny: Yeah. We have fragments of it. this is just the OD4 VP,
authorization request. but we need to put that into a full-blown flow. all
right. pause. I'm reading Nate your comment and then we'll end the call.

Dave Longley: This says OID for VCI, which I don't think uses the
authorization requests that I was talking about. I think OID forVP uses
that. okay.

Nate Otto: Okay, thanks. we can deal with it in comments on an issue that
gets created and not need to deal with it

Manu Sporny: All right.

Manu Sporny: Sounds good. All right. that is it for the call this week.
Thank you for the discussion. we are whittling the issues once again making
good progress. The thing that would really help at this point are people
reading through the introduction and architecture sections and just getting
it into a form that's much easier to kind of absorb. it's okay right now.
but there are still some sections in here where's there was this huge
section where it was just non-stop pros.

Manu Sporny: I forget where that Yeah.

Dave Longley: That's probably the workflow section. it's a wall of text
that's hard to find,…

Manu Sporny: Yeah. This is it. Yeah. Yeah.

Dave Longley: as a developer when you're quickly searching for…

Manu Sporny: Yeah. Yeah.

Dave Longley: what do I

Manu Sporny: This thing needs to be restructured, it's just we haven't made
a pass to do it yet. And so, it needs some diagrams. It needs a little bit
of restructuring. so, if folks have some time, that's one area of the spec.
The workflows and exchanges section needs to flow better and then the
introduction and architecture section could use some TLC.
00:55:00

Manu Sporny: Go ahead Dave.

Dave Longley: Yeah, I was going to mention that the introduction section
somewhere in the architecture it was very old text before we had the
workflow service.

Dave Longley: And so there's some things in there that say coordinators
will talk directly with services with issuing and…

Dave Longley: verifying services when they might not do that. They might go
through a workflow service. So there's things like that that need to be
cleaned up a little.

Manu Sporny: Yep. Was one of that.

Manu Sporny: So, PRs on that are certainly welcome as well. Okay, that's it
for the call this week. we will meet again next week and keep going through
any PRs and issues until we're done. thanks Have a great week. we'll chat
later in the week for some of you and then next week for the rest. Thanks
all. Bye.
Meeting ended after 00:56:14 👋

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