VC API meeting summary for 2025-03-11

VC API Weekly Call - 2025/03/11 Summary

*Topics Covered:*

   - *New Meeting Infrastructure:* Transition to a new system providing
   auto-transcription and recording (Google Meet). Chat will not be included
   in the transcription.
   - *Community Updates:*
      - Patrick St-Louis: Announced a proposal at the Open Wallet
      Foundation for Pidentity Wallet, a mobile PWA leveraging the VC API and
      Hakapai framework. He's also starting work with the Alonreds V2 library.
      - Upcoming Open Wallet Foundation wallet get-together in Geneva (July
      1st & 2nd).
      - Several VC specifications moving to Proposed Recommendation in the
      next two months.
   - *Pull Request Processing:* Several pull requests were reviewed and
   merged, including updates to the VP request spec, guidelines for status
   retrieval, API design guidelines, and changes related to exchange creation
   and response handling. One pull request required further changes before
   merging.
   - *Issue Triage:*
      - *Issue 458 (Content Type):* Discussion centered around supporting
      application/ld+json. The current practice of using plain JSON was
      affirmed; however, an error in the get credential endpoint returning
      JSON-LD was discovered and needs correction.
      - *Issue 459 (Service Discovery):* Concerns regarding security
      implications of allowing service discovery for challenge endpoints were
      raised. Further clarification on the use case is needed.
      - *Issue 460 (Workflow Step Property):* Discussion focused on adding
      a property to indicate whether a domain should be included in a workflow
      step. This was linked to the broader topic of managing variables within
      workflows, specifically the use of global variables based on
exchange IDs.
      The issue was considered a duplicate of a previous issue (Issue 398) and
      closed.

*Key Points:*

   - The meeting successfully transitioned to a new meeting infrastructure
   offering automated transcription and recording.
   - Several pull requests were processed and merged, advancing the
   development of the VC API specification.
   - Several issues were discussed, highlighting areas that require further
   investigation and clarification, particularly concerning security and
   content negotiation.
   - The need for improved clarity and consistency in the specification's
   handling of verifiable credentials, particularly in terms of response
   formats, was emphasized.
   - The use of global variables within workflow templates was identified
   as an area requiring further specification and potential standardization.

Video: https://meet.w3c-ccg.org/archives//w3c-ccg-vc-api-2025-03-11.mp4
*VC API Weekly Call - 2025/03/11 14:59 EDT - Transcript* *Attendees*

Benjamin Young, Dave Longley, Eddie Dennis, Joe Andrieu, Kayode Ezike, Manu
Sporny, Manu Sporny's Presentation, Patrick St-Louis, Ted Thibodeau Jr
*Transcript*

Eddie Dennis: Hey, Manu. How are you doing?

Manu Sporny: Hey Eddie, doing well. How are you?

Eddie Dennis: Doing all right. Okay.

Manu Sporny: I'm going to check the other link because people are probably
still showing up in the old link. Pull me right

Ted Thibodeau Jr: Will this be the same link for each week going forward?

Ted Thibodeau Jr: So I can Great.

Manu Sporny: Yes. Yep.

Ted Thibodeau Jr: Yeah. Perfect.

Manu Sporny: If we decide to move over to this system, you will get a new
link once the CCG creates the new event. But until then, this will be the
one we use.

Ted Thibodeau Jr:

Ted Thibodeau Jr: Come on. Sew it.

Ted Thibodeau Jr: possibly more important and better. Can it get thrown
into the CG calendar always?

Manu Sporny: Yes, that is the plan. there are a number of annoying
complexities that, in order for that to happen, the CCG needs to get a
Google Enterprise account so that they can do transcription and recording.
they're large dollar dollar signs associated with this migration and…

Manu Sporny: yep all the fun let me see I think in all of the rush I forgot
to send out the actual agenda for this call so apologies for that.

Ted Thibodeau Jr: All the fun. Okay.

Manu Sporny: but it's going to be our standard agenda. Okay. I'm going to
get started. welcome everyone to the VC API call. we have our standard
agenda for today but there's the new infrastructure you can pretty much
ignore Anything that you put in the chat channel will be lost forever. So
just remember that technical issues with they don't include the chat
channel with the transcription. we will use raising hands for queuing
because's queuing There's no advanced real time integration or any of that
stuff.
00:05:00

Manu Sporny: So what we do get out of this is auto transcription and auto
recording. So there will be a video recording that we can extract audio out
of and there will be a Google doc and a markdown file and a text file that
exists. All of this stuff will be auto emailed to the mailing list
afterwards. we can't edit that thing before it's sent out without great
pain. so that's kind of the new system that we're dealing with today. let
me go ahead and share this window here. this is an old agenda, but on the
agenda today, we've got community updates. we will look at and process pull
requests for the specs.

Manu Sporny: we will then look at issues that are ready to assign any other
updates or changes to the agenda before we get started. go ahead, Cody.

Kayode Ezike: Yeah, just a quick one. So, I wasn't able to attend last
week, but I do know that notably this call was directly soon after the call
on the digital credentials API. So, just wondering kind of if it's on the
radar for that group to include this as one of the supported APIs.

Kayode Ezike: This generally is

Manu Sporny: Yeah, that's a great question.

Manu Sporny: In general when the new charter happened we made sure that the
digital credential API would be protocol and data format agnostic which
means that it should allow the oid4 protocols and it should allow for the
API protocols. you would have probably noted that last week they didn't
talk about VC API at all. which is problematic and a bit troubling. But we
mentioned in the CCG call today, this API will be suggested as a work item
for the new rechartered verifiable credential working group. We've got
plenty of implementations.

Manu Sporny: DC digital credential API should be completely agnostic to
protocol and data format. and so we expect that it will end up in the list
of supported protocols for the digital credential API. it is also up to the
platforms to actually implement that. So even if it's recognized W3C, it
doesn't mean that the platform vendors will implement support for it. So
that's kind of where we are. right now we will be taking that theory for a
test run in Q4 of this year. I think that's where we are coyote on digital
credential API and VC API being supported in there.

Manu Sporny: I will note that even if it's not supported in DC API, we've
got mechanisms that go outside of digital credential API to use the VC API
specifically in the retail industry. They're code engagement mechanisms and
exchange mechanisms that are purely VC APIdriven. So, we're not entirely
beholden on the digital I to verifiable credential API. the other thing to
note is that oid4 is just a delivery mechanism. It doesn't take life cycle
management into account which the VC API does do. So VC API does issuance
verification status modification presentation generation all kinds of
back-end services that are needed by organizations deploying a full life
cycle.

Manu Sporny: So all that to say that the digital credential API is just a
subset of what we'd need but ideally we would be supported by digital
credential API and if it's not then the question is okay what other
protocols would make it if not for this one. Did that answer your question
coyote?
00:10:00

Kayode Ezike: Y thanks.

Manu Sporny: All I guess, next up, we can go into any relevant community
updates. does anybody have any relevant community updates for the group? Go
ahead, Patrick.

Patrick St-Louis: Yeah, I opened a proposal at Open Wallet Foundation for a
project of mine called the Pidentity Wallet. so that's a sort of mobile
progressive web app that's meant to work in tandem with the Hakapai
framework and…

Joe Andrieu: Excellent.

Patrick St-Louis: the three interpretability starting point one of them
includes the VC API. So this sort of thread project will become a open
wallet foundation lab. Then I look forward to keep maintaining it and…

Manu Sporny: Great to hear,…

Patrick St-Louis: keeping interperability with the VC API style issuance
and exchange.

Manu Sporny: Patrick. I guess on that note, we did have in the main weekly
credentials community group call today, a review of all the work items,
that were being worked on. one of the announcements was that the Open
Wallet Foundation is putting together some kind of wallet get together in
Geneva this July 1st and 2nd I think. We don't have any more details on it
but they've been asking for people from this community to participate. so
that's the first item.

Manu Sporny: the second item is we've got a number of VC verifiable
credential specs going to recommendation around in the next two months. So,
we're going into proposed wreck in 9 days with seven specifications in the
verifiable credential working group and then we've got global standard
after that if it's ratified and approved. So, we'll have to make sure that
we go around and get folks to vote in favor of the publication of the
verifiable credential specs. okay, I think that's it for any other
community updates before we move on?

Manu Sporny: Go ahead, Patrick.

Patrick St-Louis: I'm also starting work with the Alonreds V2 library. So
they have a BBS implementation and as well PS signatures. So the library
that exists right now is meant to be modular and you can swap the
underlying cryptography. so I'm having a look at that trying to think how
it could fit as a sort of data integrity crypto suite and…

Patrick St-Louis: yeah so we'll likely be update updating on that in the
weeks to come. There's a presentation happening I think in two weeks and
it's very interesting.

Manu Sporny: Awesome.

Manu Sporny: That's awesome. all right. if there's, no other announcements,
let's go into our pull request processing. first up is the VP request spec,
which doesn't have any new PRs, which is fine. And then let's look through
our VC API pull requests. we have quite a few of those. looks like we've
got, seven. so let's just kind of work through them. the first one up is,
pull request 461461.

Manu Sporny: verify envelope credentials and envelope presentations. We
were waiting for John to respond, but it looks like he hasn't yet. So, we
might need to ping him to make sure that he kind of respond so that we can
do so that we can merge this. It's been two weeks waiting on a response.
next PR up is PR 464. add guidelines for status retrieval. I think we made
a suggestion here, Patrick, last week. Doesn't look like you've integrated
it yet. thoughts on this one.

Patrick St-Louis: Yeah, I can sorry I did not take the time to go through
it. So I think that suggestion was ready to be accepted as is. I just had
to accept it.
00:15:00

Patrick St-Louis: So I can do this right now. Guidelines here should be in.

Manu Sporny: Okay.

Manu Sporny: Me refresh my side. Okay. given this does anyone have any
updates or changes to it or should we go ahead and merge it? Okay.

Joe Andrieu: It's cool.

Manu Sporny: not hearing any objections. We'll go ahead and merge. let's
see. We got two commits. I'm going to compress this into a single commit.
sign off. I don't think we need authoring. Okay, that one's done. Thank
you, Patrick, for that P next, PR is, pull request 465, add API design
guidelines.

Manu Sporny: I think we needed some modifications on…

Manu Sporny: what guidelines we point to and these I don't think have been
updated yet. Is that right, Patrick? Okay.

Patrick St-Louis: Yeah, this one's still going to need a bit of work.

Patrick St-Louis: So, we had a discussion about the restful API in the
controller section which was, take it out and advise against and need to
add a bit of text to explain this.

Manu Sporny: All right.

Manu Sporny: Okay. So, this one still needs to be a time. next, pull
request 466, add validation guidance. I think this one also had a couple of
changes proposed that I don't think have gone in yet. So, this one needs a
little bit more time, I think. Patrick, is that right?

Patrick St-Louis: Leave it open.

Patrick St-Louis: Yes, same thing.

Manu Sporny: All right.

Patrick St-Louis: I'll need to take your time to go through it.

Manu Sporny: And then next item up is Coyote, you've opened pull request
467. and this is to add the active state to ex the exchange creation
process.

Manu Sporny: Looks like Dave's given it a plus one. Fairly straightforward
change. anything you want to add to this coyote?

Kayode Ezike: It's right.

Kayode Ezike: Nope, it's good.

Manu Sporny: Okay, sounds great. That one looks good. So, we'll merge 467.
it is one commit. So, looks good. Thank you, Coyote for that one. And then
I guess we should be closing these ones as well.

Manu Sporny: Also the R existed. and then I guess what one is this PR 467
has been merged to address this issue. Then we'll close that one. That's
good. Next up is embed exchange creation response in the exchange property.
let's see go ahead if you can take this through.

Manu Sporny: Yeah. Take us through this.

Kayode Ezike: Yeah. …

Kayode Ezike: so the main thing to change here was actually originally
going to be to change exchange ID to just be see that line 320 over there.
but then in addition to that, Dave had a comment in the issue that said
that it would be preferable in addition to that to just put it inside of
the exchange property. and so it also does that as well. And then I just
tacked on at the end something that was missing for the sequence in so the
main thing is just in including the response inside of the exchange scope.
but I did have a comment or two in there as well that was actually directed
towards Dave. but I see Dave's hand is also
00:20:00

Dave Longley: So, I don't know what other implementers are doing right now.
when you create the exchange, we don't return the exchange object. but I
wanted if anyone else was doing this to make it an optional field for
people to return it. If we're reusing the schema elsewhere, I want to make
sure we don't accidentally define it such that exchange property has to
always be present. if you did a get on the exchange, it's not going to nest
the exchange underneath that property. if you scroll up on this monu, I
don' This is underneath object containing information about a created
exchange. I don't know. I guess you'd have to Keep going up there and Okay.
So, this is just create exchange response.

Dave Longley: It's I don't know what other implementers are doing. we use
the location header when you post a new exchange and say where it is. We
don't return back the whole object. and…

Joe Andrieu: Okay.

Dave Longley: I would be okay with just saying that's what we do. I just
didn't want to cause a problem for anyone else who might be doing it this
way. so my actual vote would be as long as this schema is not being reused
where we get an exchange because I would be okay with removing all this and
say just set the location header to where the exchange is. If you want to
go fetch it, you can go fetch it.

Kayode Ezike: So I guess we probably …

Manu Sporny: So that no.

Kayode Ezike: Yeah,…

Manu Sporny: So J Dave, just to be clear, you're saying delete all this
stuff here.

Dave Longley: Yeah, I would be okay with that as an implement. Yeah. Yeah.

Manu Sporny: But the sequence thing stays right.

Kayode Ezike: that was just something that was missing.

Dave Longley: I don't know…

Manu Sporny: Yeah. Yeah.

Dave Longley: what that schema is under that it's kind of hidden by if you
scroll down.

Kayode Ezike: If you expand it, I think it was for the G.

Dave Longley: Yeah. If it's for the get that it absolutely needs to be
there.

Manu Sporny: Get exchange response sequence.

Dave Longley: Yep. yeah. we have properties exchanged there. that's what I
was worried about that we would start returning back a nested exchange. So,
we want to change if you get the exchange, you should get the exchange
contents.

Kayode Ezike: Okay. Yes.

Manu Sporny: So, it sounds like there needs to be multiple changes here.
meaning just the exchange contents.

Kayode Ezike: Yeah. Yeah.

Manu Sporny: So we don't return back this whole object and then the things
at the top kind of stay. Is that where we are? Okay. Okay.

Kayode Ezike: Sounds good.

Manu Sporny: And then where do we want to say that you should return it in
the location header?

Manu Sporny: We could probably put it in the spec as a note that goes
underneath the description,…

Joe Andrieu: Thank you.

Manu Sporny: I mean, you'll have to play around with the,…

Kayode Ezike: Yeah. Yeah.

Kayode Ezike: I was going to look into …

Manu Sporny: how to do that.

Kayode Ezike: if it was possible to do that here as well, but yeah, I
couldn't look into it.

Manu Sporny: You can always shove it in a description here, Coyote, but it
might be better if I forget how we've structured the spec, but it might be
better in a section around…

Kayode Ezike: Okay.

Manu Sporny: what happens, it might be better in the section that talks
about create exchange response. if that makes sense.

Manu Sporny: So let's the group discussed this on the 2025311 telecon and…

Kayode Ezike: Thank you.

Manu Sporny: requested the following changes. what are they? do not res
return the exchange object when creating an exchange.

Manu Sporny: Try to specify that the newly created exchange location is
provided via the location HTTP header and…
00:25:00

Dave Longley: and unnst the Exchange object when you're doing a get on the
Exchange location.

Kayode Ezike: Perfect. Good.

Manu Sporny: was that All right. Yep.

Manu Sporny: Remove the nest nesting on the exchange object when retrieving
and…

Kayode Ezike: Yeah.

Manu Sporny: exchange via HTTP Okay.

Dave Longley: Yep. Yeah,…

Manu Sporny: All so Coyote, we'll just wait for you to make those changes
and then look at it again next week. Does that work for you?

Dave Longley: I would raise the other point since we're making this
decision here. whatever we did with workflows where you create it and we
had a similar discussion around not returning the whole workflow during
creating the workflow, we would do the same thing there. So return back the
location of the new workflow and not put anything in the body.

Manu Sporny: All right.

Dave Longley: Yep. I think it's up to you.

Kayode Ezike: And should that be a separate issue or…

Kayode Ezike: should I just put it all in the same app the workflow? Okay.

Manu Sporny: Yeah. Yeah, I mean I'd say put it in the same PR coyote
because otherwise it's just a lot of paperwork to get something we want
done, And maybe you can update the issue if you want but again up to you.

Manu Sporny: Okay that's that item and…

Kayode Ezike: Here I Just know that there's one more here that I just
landed as well. Refresh

Manu Sporny: then last item we have as a request is a pull request 469
which is create challenge that property from a string to a boolean
addresses issue 455 fairly straightforward any objections to merge I will
take care of that right after we deal with this one. So, this one is
rebased and merged and then it addresses issue 455.

Manu Sporny: PR exists maybe.

Kayode Ezike: The one thing I'll say about this I'm trying to figure out
what's going on here is basically when I view inspect text from the index
doesn't actually seem to compile the way I expect it to the I don't know…

Manu Sporny: And then PR 469. Okay, that takes care of that one. Thank you
for that, All right. Next PR is PR 470 which converts the sequence format
from a string to a number.

Manu Sporny: Dave has said that looks good.

Kayode Ezike: if it's the number type or what it is but it shows the JSON
beneath it as well for some reason. I've seen other examples of that
throughout this book as well, but that's okay.

Manu Sporny: It's a rendering bug in the thing that does the rendering.
just as a reminder to everyone that algorithm is fantastically brittle and
has just been kind of hacked on over time. It really needs a rewrite. But
Coyote I would imagine that it's just a bug in the respect OAS stuff. so
you might need to go in and look at the typing how it detects type.

Manu Sporny: I think if it doesn't know what the type is, it just prints
out the raw JSON. So, it probably just needs a little change to add the
number type, which it probably doesn't know about. any objections from
anyone for merging If not, we will go ahead and rebase and merge that one
and go to issue 447. This one PR exists and 470 and…
00:30:00

Kayode Ezike: Where is

Manu Sporny: then close this one.

Manu Sporny: All right, that takes care of that one. Thank you for that one
as well, Okay, so we've got these ones that we'll go over again next week.
going back to the list of issues, we've got three new ones that need to be
categorized. so let's go ahead and take a look at them. the first issue is
supporting the content type of application LD plusJJSON. This is issue 458.

Manu Sporny: Lauren noted that the serialization requires responses to be
application JSON and asked if this could be extended to support application
LD plus JSON. Patrick Ted, maybe you want to chime in and then we can go
from there. I just saw you that had commented here,…

Ted Thibodeau Jr: Not sure what to chime in with.

Manu Sporny: so I don't know if anyone wanted to add something. I'm still
reading the issue. okay.

Ted Thibodeau Jr: Yeah, I was just asking that for more details.

Manu Sporny: Go ahead, Dave.

Dave Longley: My comment would be that we don't have any endpoints that
return something with add context in the top level of the JSON. So every
endpoint I believe that we have is a JSON and…

Dave Longley: is not a returns a nonjson LD response.

Manu Sporny: Yep. …

Manu Sporny: go ahead, Patrick.

Patrick St-Louis: I not sure but I think there could be an exception with
some of the workflows I believe return in some cases a verifiable
credential directly not some workflow exchange more specifically Yeah.

Dave Longley: We should look at that and make sure that that's not a
mistake somewhere. my understanding if you're working with an exchange
should be that you're getting back a JSON object that has optional
properties like verifiable presentation request, redirect URL, those sorts
of Thanks.

Patrick St-Louis: Yeah, I agree that should be good. So basically copy the
endpoint return style of the issue or verify endpoints.

Dave Longley: And whenever we have what we just discussed when you get an
exchange an exchange is not expressed as JSON LLD it's just expressed as
JSON doesn't have an at context.

Patrick St-Louis: Yeah.

Dave Longley: The same is true of a workflow. So they're all just JSON
modeled. So I don't think even for any place where you would get the
objects we create in the VC API we're just using JSON for those. so I
really don't think there is any place where this is the case. this doesn't
speak to if we wanted to express something like a media type alongside
something that might be returned elsewhere. we already do that if you
express a verifiable credential with an envelope around it.

Dave Longley: But there might be some other use case. but I'm not aware of
another use case at this time where we need to do

Patrick St-Louis: I think we should definitely look.

Patrick St-Louis: So it seems to point out in the last comment that the get
credential endpoint is defined to return a credential directly. So we can
probably have a look at that. and if that's the case, just return a JSON
object with either the result key or the verifiable credible key. So, do we
want to

Dave Longley: Yeah, we should follow that link and…

Dave Longley: take a look at

Manu Sporny: So the response here,…

Manu Sporny: yep, is a top level object with an app context.

Dave Longley: I think that's a mistake here and we might even have an issue
related to that where you're verifiable credential should be getting
returned and it might be a duplicate of that one. I'm going to see if I can
find a related issue.
00:35:00

Patrick St-Louis: is the station the issue.

Patrick St-Louis: So do we want to have just a singular result property and
have the credential or do we want to say verifiable credential?

Dave Longley: I would say verifiable credential. that's what our
implementation does and I'm pretty sure that's what implementations that
just were written against a test suite that we got a bunch of interop on
issuing these things are using. So I'm pretty sure that's what everyone's
already doing.

Dave Longley: And we just need to see if there's an issue with a ready for
PR that would fix

Patrick St-Louis: Is there any mention seems kind of related here…

Patrick St-Louis: but we mention that a client can have an accept header
and is request and they can request application VC and then if it's
possible it would return it as such right.

Dave Longley: I don't think you could return a verifiable credential that
expressed an API response unless it was literally a verifiable credential
for the API response.

Dave Longley: So I think there's a conflation of the layering here.

Patrick St-Louis: Okay. Yeah.

Manu Sporny: But for this issue,…

Manu Sporny: we have a clear path. is there any other discussion we need to
have on this issue before moving to the next one? if not, let's go ahead
and take a look at issue 459, which is service discovery from controlled
identifier documents.

Manu Sporny: so Lauren is designing capability system based on verifiable
credentials when invoking capability like creating presentation targeted at
an endpoint for a specific controller. Lauren needs to obtain a challenge.
Could the spec define a VC API service in the controllers controlled
identifier document to discover the challenge endpoint of that controller.
This will require the VC API service to define a service type name. This
might be related to issue 433 which that we introduce a manifest describing
entry point static endpoints which we discussed back in January.

Manu Sporny: And…

Manu Sporny: we asked for use cases in that issue and asked Philip if he
could join us here. So go ahead Dave.

Dave Longley: My first thought is discovery of a challenge endpoint to me
seems to imply that you're some client of some I don't know…

Dave Longley: if this is an issuer or verifier or something and you're
looking to make a call to their challenge endpoint. But I don't know why
you would be authorized to access the endpoint that would allow the
creation of a challenge which often or may include the storage of
information on a service which is a denial of service attack. So, I would
not expect you to be authorized to use such an endpoint.

Dave Longley: And if you were authorized to use such an endpoint, I don't
know why you would need to discover where it was.

Manu Sporny: and I didn't catch the last thing you said longly…

Dave Longley: it's yeah I don't know…

Manu Sporny: which was Yeah,…

Dave Longley: why you would need to discover where it was if you have been
given an authorization to use that endpoint. It seems to me that those are
probably mutually exclusive problems if you're discovering something I
imagine you wouldn't already have authorization for it because you don't
know what it is and if you have authorization to use it you probably
already know what it is. Yeah, you wouldn't be doing discovery…

Manu Sporny: I couldn't keep up. Why would you need to discover where an
endpoint is when you have been given authorization to use the endpoint? If
you
00:40:00

Dave Longley: if you're already authorized to use it. you have a priori the
knowledge of that endpoint because it was given to you with the
authorization. So, it's sort of like handing someone a key and saying, "Go
find your door to use this in," which is awkward. or somebody is just
trying to find a door to get in, but they don't have a key. Neither one of
those seem to be good developer or user experiences.

Manu Sporny: Yeah, the other thing might be trying to create a capability
system based on verifiable credentials. Seems like the capability system
doesn't have denotation in it that they're designing, right? you can't
denote the resource.

Dave Longley: there could be a way that maybe they're expressing what the
resource is within the VC. but you want to invoke a presentation that has a
challenge in it based on getting that challenge from someone else. You need
the permission to get that challenge from somebody else to begin with.

Dave Longley: Otherwise you can do their system.

Manu Sporny: Okay. …

Manu Sporny: what's the next step here? I guess it sounds like the use case
has security issues and we need to understand the use case in more detail.

Manu Sporny: Can you please provide a diagram or a series of detailed steps
so we can analyze your capability?

Manu Sporny: system more effective So, we don't know what to do here yet
and we've asked for more information. anything else on this issue before we
move on to the next one? Okay. If not, we'll close this one down. and move
on to this one which is issue 460 which was filed by Coyote to add a
workflow step property to indicate whether domain should be included.

Manu Sporny: Dave Yep.

Dave Longley: Before we jump into this one,…

Dave Longley: I just wanted to put into chat here. I found this is our
schema for that other issue where we talked about there being a verifiable
credential nested in an issuance something. it seems like our OAS file has
the right thing in here. There should be a property verifiable credential.

Joe Andrieu: There's

Dave Longley: Then this is supposed to be used in the response to a
successful issuance request.

Dave Longley: So I don't know why the spec isn't rendering that properly if
it's not doing that, but it seems like the scheme is

Manu Sporny: Maybe this spec is broken.

Manu Sporny: Hold on. When was the last update? 11th of March. that's now.
what was it? Section 385. 38. 381. property credential.

Dave Longley: Yeah,…

Manu Sporny: No, that's issue…

Dave Longley: that's the input.

Manu Sporny: which …

Dave Longley: And if we go down, what's the output that is in there?

Manu Sporny: this one's right.

Dave Longley: Maybe it was getting a credential.

Manu Sporny: Maybe it's verify. No, is it? What was the Does anyone
remember That's it. It was get credential.

Manu Sporny: get credential doesn't have the top level object.

Dave Longley: That is interesting to debate because we can talk about
whether we get credential endpoint to return back the raw credential just
at the top level or nest it. I think we might have even had a separate
issue as to what we wanted to do there. So that this could be a place where
you could potentially content negotiate for a different version of
redential. At the same time, that's going to be really hard unless you're
going to ask for something like a core LD version of the credential because
I don't know, you can't just change the format of the credential. but go
ahead, Patrick.
00:45:00

Patrick St-Louis: That depends again whose get credentials if you're
calling get credential from an issuer you could very well have the issuer
store multiple sl version of the credential on format that it knows that's
something we did for the UNP work so we save the data integrity sign
credential and then we save a VC job version of that credential and
depending on what format the caller is requesting. we return one or the
other. So this is to enable our solution to work with whatever different
entities are doing for Yes.

Dave Longley: Do you do that with this?

Dave Longley: Do you do that with for the same credential? I think the
group should talk about that more in the future. that sounds potentially
messy.

Manu Sporny: …

Manu Sporny: what are we doing here? Should we raise an issue to track this?

Dave Longley: Yeah, I guess the group needs to discuss what the response to
this endpoint should be and whether it's a good idea to have the same ID
refer to

Patrick St-Louis: to I don't know if this adds anything so we take the
credential we add a data integrity proof and we wrap that data integrity
secured credential in an envelope and…

Patrick St-Louis: then if they request the envelope we return the envelope
otherwise we return just the payload of the envelope if that makes sense
but It's the same credentials saying with the same data integrity proof.

Dave Longley: It does.

Dave Longley: That sounds like the same credential, but you can put it in
an envelope or not. That's a little bit diff.

Patrick St-Louis: Yes. Depending.

Dave Longley: Yeah, that's a little bit different. So, I think that that
feels less problematic to me.

Patrick St-Louis: Yeah. We also make it so that and these are public
credentials, So that's very important. But we also make it that if they do
not provide access an accept parameter we return a HTML sort of rendered
version of the credential. so they need to configure their system to
request either a VC or a VC jot in the accept parameter if it's for machine
readable version otherwise it's expected that they just want a rendered
version of that credential.

Patrick St-Louis: So it's the idea that we can have a unique being the ID
of the credential itself being a URL someone can click on it in a browser
or they can parse it with their software…

Dave Longley: Yeah, those are all arguments to return.

Patrick St-Louis: but that's the difference Maybe.

Dave Longley: Yeah, and those are all arguments to if we're going to
support that, we would want to return the credential back and according to
the accept header to enable those use cases otherwise you couldn't do that.
So, we should all discuss that in the future.

Patrick St-Louis: Yeah. Yeah.

Dave Longley: Maybe this is the end point where it makes sense because the
actual thing you're getting is a JSON LD object. The other endpoints,
you're not ever getting that.

Patrick St-Louis: I mean our use case and endpoint right like I said it's
like a public endpoint which is not the design here. So maybe for
simplicity here we just return verifiable credential and then you put the
verifiable credential in that property. That would probably simplify thing
for the VC API and then people can build other functionalities on top if
they want to. I think so.

Dave Longley: So you would argue to include the verifiable credential
property here and have it always be JSON.

Patrick St-Louis: I think so. Yeah. Or this API back

Dave Longley: I would be okay with that.

Dave Longley: It would be consistent with the VC API spec.
00:50:00

Manu Sporny: Okay.

Manu Sporny: So, hold on. let's go back up the stack. We had a discussion.
I did not capture it. We will come back to this and hopefully you can
remember what both of you said. It sounds like we have a solution.

Manu Sporny: I just did not capture any of that. it'll be in the minutes.
Yep. I'll also point out that content negotiation is now something that the
media man working group is saying was a massively bad idea and…

Patrick St-Louis: Yeah, I think content negotiation should be treated as a
separate issue and…

Patrick St-Louis: we should just discuss it. if it's something we want to
introduce on some endpoints, all end points. Yeah.

Dave Longley: You can link to issue 39.

Manu Sporny: we never should have done it.

Patrick St-Louis: Interesting.

Manu Sporny: So this is also related to issue 398.

Dave Longley: 98. Looks like we have discussed this before. And if you
follow that link, we said it's ready for to add in the verifiable
credential property.

Manu Sporny: So this is a dupe lick it. are we done talking about it?

Dave Longley: If we're done talking at that point, yeah, I would call it a
duplicate. the other issue came to the same conclusion.

Manu Sporny: Okay, I'm going to close it as a which means that this issue
is a duplicate.

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: And it also means that one that we just previously marked,
this one

Patrick St-Louis: slightly different,…

Patrick St-Louis: but yeah, I think it's the third one, but we couldn't
probably add a link to 398 because that exact thing was And what he
describes in his last reply was discussed exactly in there. So I think it's
fair to say that he's pointing to something that is supposed to be changed
and is sort of in the backlog of issues.

Manu Sporny: All jumping all the way back up the stack. We were talking
about 460, I think. Cody,…

Manu Sporny: if you could give us a background on issue 460.

Kayode Ezike: Yeah. Yeah.

Kayode Ezike: Yeah. The main thing here I think is just to basically make a
clear directive in the workflow configuration whether or not to include
domain the same way it's done with the challenge. yeah because there is
support for that in the VPR spec. So, I just wanted to There's a little
uncertain as to how that's currently kind of being done. Yeah.

Dave Longley: So the create challenge directive for steps is predicated on
the VC API's create challenge HTTP endpoint which I believe is in the spec.
We don't have such an endpoint for creating or using a domain or something.
So I don't know how this directive would work and I think the expectation
is that a domain if you needed to include it in your step would be either
part of your template or as a static part of your template or include it as
a variable issuer verifier coordinator when they they would say create the
exchange with these variables.

Dave Longley: One of those variables could be the domain and they could put
whatever domain needs to go in there for the exchange to happen. one thing
that I think is important and I don't know how much we talk about this in
the spec. I know our implementation allows there to be global variables
that are based on the exchange ID and so you can reference those inside of
templates. maybe we want to put that in the spec and say every implementer
should expose those to templates, but that's an open question. that would
allow for you to put the domain associated with the exchange into a
verifiable presentation request.

Manu Sporny: All right.

Kayode Ezike: Makes sense.

Manu Sporny: So I guess what's the next step here?
00:55:00

Manu Sporny: Is this a noop? Is what would we need to do?

Kayode Ezike: It sounds to me that I think that Dave's last point relates a
little bit to another issue around variables …

Kayode Ezike: which Dave is saying it could be useful to give examples as
to how such a thing could be configured through a global variable for the
exchange by the coordinator. Yeah, and I do have another issue that is
around variables that we've already discussed, I think, but it seems like
it kind of details a little bit. Can probably try to Yeah. 446 is the win.

Manu Sporny: So, Of course, it's not going to open it in the right browser.
it's a schema for exchange variables. So, this is related to 446 for issue
446. Yeah.

Kayode Ezike: I think so.

Manu Sporny: Is that ready for Does anyone want to take this one? Just Hang
out there for a bit. those are all of our issues. and we're two minutes
over. thank you very much everyone for the call today. really appreciate
it. we'll see how this transcription and recording bot does with the
summary to the mailing list. we will meet again next week and continue
processing poll requests and issues. thanks everyone especially thanks to
those that are raising PRs. Thank you Patrick.

Manu Sporny: Thank you, we will continue next week. Thanks everyone. Have a
good one. Ciao.
Meeting ended after 00:58:04 👋

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