Re: VC API meeting summary for 2025-03-11

Looks like the new Google Meet automation worked. The AI-generated summary
of the VC API meeting we had yesterday was automatically delivered to the
mailing list (included below) as well as the AI-transcription of the
meeting. All the meeting files are archived on a server that the w3c-ccg
controls (with nightly backups and recovery).

There are features that are missing in the new Google Meet system, that we
will most likely not get back: Preservation of inline chat history, links
to things people shared in chat, ability to link to specific lines and
resolutions, advanced queuing (with reminders of why you put yourself on
the queue in the first place), linking to people's LinkedIn profiles, and a
variety of other items we could do in the old system, but can't do in the
new system because Google Meet doesn't allow for the sort of fine grained
control we had with Jitsi.

All that said, the benefit we get with the new system is reduced
operational costs (especially wrt. to the maintenance team), automatic
software upgrades, and full automation of recording, transcriptions, and
archival.

We'll keep testing the system between the VC API, Render/Confidence
Methods, and Data Integrity meetings over the next couple of weeks to work
out the kinks, but the test yesterday went very well with no technical
issues of consequence.

----------

On Tue, Mar 11, 2025 at 7:20 PM <msporny@digitalbazaar.com> wrote:

> 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.*
>


-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/