Add clarifying statements about VC API Workflows (and exchanges)

[msporny]

This issue is tracking some clarifying statements that need to be made about VC API Exchanges in the specification, based on the following VC API meetings:

https://w3c-ccg.github.io/meetings/2023-02-28-vcapi/#topic-5 https://w3c-ccg.github.io/meetings/2023-03-07-vcapi/#topic-2

[msporny]

@dlongley said: in the spec today and you know we might still need to tweak it a little bit but there is a there's a simple protocol that's defined for how what the Met what messages you need to send and how what what you're going to get in return When you communicate with these URLs and that that gives clients something to do to that they know how to process to ultimately wind up for example with a verifiable presentation that has credentials in it at the end of the day.

@dlongley said: the exchanges defines one slit one such type and so it provides a type and and days a protocol that people can Implement against whereas it's certainly true that the coordinator at any time could just send you an interact filled with some other type that could happen and it wouldn't have to be bound to exchanges in any way but this exchanges feature in the spec says here's one way to do it that will get through flows common flows from picking up theses.

@jandrieu said: Try and frame it in the positive way but it seems like you're defining an extension point but we haven't been calling it that and maybe that's why it feels like feature creep because it's an extension point because you're saying you want exchanges to be able to through the back end that because someone programmed it that way satisfy the capability URL through other apis right now VC API. I've got an interface here and exchanges that will let me do you know it will let me expose some complicated functions through a simple capability URL and it will do some of the heavy lifting in terms of what's the flow about all of that but the flow of which it is coordinating not as a coordinator let me use the word conductor this exchange is conducting this flow and I mean that like a symphonic or Jazz conductor. Are conducting operations on the rest of the API is what I'm trying to get confirmation that that's the architecture that there isn't a functionality that the exchanges magically have access to that you have to go through an exchange for other than the conducting roll.

@dlongley said: Yeah I think you are right I think I think what we can say is the in exchange always provides the VC API and we might want to in this spec say and you can there is an extension Point here where you can have that same stateful information and flow and everything that you backed in your exchange you could expose that through another protocol and we because of oh I DC for VC is popular right now.

[jrhender]

@msporny I get a 404 for both https://w3c-ccg.github.io/meetings/2023-03-07-vcapi and https://w3c-ccg.github.io/meetings/2023-03-07-vcapi/#topic-2

[msporny]

@msporny I get a 404 for both https://w3c-ccg.github.io/meetings/2023-03-07-vcapi and https://w3c-ccg.github.io/meetings/2023-03-07-vcapi/#topic-2

The build is happening right now... it'll show up in the next 15-30 minutes or so.

[TallTed]

I'm pretty sure that these call notes were generated by the auto-scribe (oh I DC for VC is something of a giveaway) .

It would be very helpful if someone who was on that call (or even each quoted speaker) could review those notes, and translate them from auto-scrib-ish to English. I'm not quite versed enough in the topic to decipher the notes myself.

[msporny]

The group discussed this on 2023-04-14 and wanted to add the following points to the spec:

Raise a PR that does the following to the Workflows section:

• Concept of workflows.
• Concept that you can configure a workflow, but those APIs are probably out of scope.
• You hit a workflow endpoint, which creates an exchange URL (which if hit by a client either speaks the VC Exchange API protocol OR alternatively a different protocol)
• An exchange URL is an HTTPS URL, if you post to that URL, you get back a VPR and/or a VP. If you get back a VPR, it can optionally have an interact field which is where other protocols could be listed. If do not get a VPR, you are done. If you get a VP, you have received credentials. If you get a VPR, you get instructions on what to post back and which protocol you can use to continue the exchange.
• When an Issuer Coordinator creates an exchange, they give the Workflow Service some information that might be specific to the implementation (how that is done is out of scope), they get back an exchange URL that they give to a client. When Issuer Coordinator gives the URL to a client, they might a) just give the client the URL, or b) give them a VPR that includes the exchange URL in the interact field. When you hand a VPR off to a client, they might know how to respond since they have the entire VPR and respond to the interact field.
• You can configure what a workflow does: it can be single-step or multi-step.
• An Issuer Coordinator creates an exchange using a Workflow Service endpoint, a client uses the created exchange to transfer credentials.

Also consider: There are instances of things that are configured, workflows, people would set up configurations for a workflow, you'd set up a workflow, configure it, and it would sit there ready to be used, when Issuer Coordinators hit the endpoint. That concept needs to go into the spec, then optional set of APIs on how to create workflows. The details about those things and how you configure them could be different, don't need to get interop on workflow setup. What is not open ended is, once you have a workflow configured, you should be able to make a call to create an exchange, which creates a unique exchange URL that you hand to a client, then client knows how to hit endpoint and speak VC API Exchanges protocol. It could also optionally speak other protocols, because this is an extension point.