What does the Exchanger Service do and who uses it?

[msporny]

During the VC API call a week ago, the topic of an "Exchanger Service" came up -- https://github.com/w3c-ccg/vc-api/issues/295#issuecomment-1182482405 . What is it, what can you do with it, and who is expected to use it? This issue is designed to track that conversation and result in a PR that can provide some clarity to the current specification.

[msporny]

We discussed this in the 2022-08-09 call. @dlongley noted that we might not need to have an "Exchanger Service", but perhaps an "Exchanger endpoint". What's important is that there is an API for exchanges and it's important for setting up your infrastructure. @jandrieu wondered what component this lived in, didn't understand it as a service. Which component uses this to do what? It feels potentially that it's an overgeneralized capability that might be overkill. @David-Chadwick noted that this looks like "Trust Negotiation" -- it's also been talked about as "Progressive Trust" in the community.

@dlongley noted that there is a difference between delivery of the VC and issuance of the VC. In the VC API space, we're talking about producing/putting signature on a VC so it can be delivered. OIDC4VCI focuses on the delivery part and not on how the issuance part works -- OIDC4VCI is really a delivery API. The Exchanger API is close to a delivery API, the user goes to a website and authenticates, they are given a URL so they can get a VC delivered to them. When they interact with the delivery URL, the exchange endpoint can do other things in the background, like talk to issuance service to issue/get other credentials. Ultimately, the exchanger concept has to do with VC delivery and pushing issuance into the background and dealing with negotiation with other VCs from the user.

@jandrieu noted that it maps more closely to a flow than a service. It seems that if we deal w/ any request may have a response of "you have to do X first", then we can construct arbitrary flows in that flow. Thinking about this as a concrete service, or specific endpoint, any time I go to web page might be redirected. Might be a different way to realize use case of @David-Chadwick, but not sure.

@David-Chadwick in OIDC, there are two services AS/RS -- you get authorized at AS, you get delivery at RS. How you authorize to pickup VC later, you might provide VP or other credentials to AS to pick up VC at RS.

@dlongley noted that when we started on this concept, we called these Workflows, we needed to change it, so we ended up with Exchanges. A particular flow, or something that can help deliver VC and coordinate how you go through that flow, until ultimately you end up with VCs you were looking for.

@jandrieu said that both "exchange" and "service" makes it seem like there is a static thing, more flexible approach, additional steps may be required, all we might need is the ability to, as you go thorugh the process, direct to other locations. There is not a central place where you go to do an exchange. A technique to enable this transfer is important. It might be more fluid so you could embed it in each step.

[PatStLouis]

Here's a few questions I have:

• Is it fair to say that types of exchanges could be "request-credential", "request-proof", "present-proof", "send-message", "initiate-connection", "did-exchange", etc?
• If so, how would these manifest in a real interaction?
• Which url would be called (how to map an exchange_id to what it's actually doing?
• What would be returned when I hit GET /exchanges?
• How could we create a parallel between exchanges and DIDComm messaging?
• Is there a defined concept of states for each agents throughout these exchanges/interactions?

[msporny]

The group discussed this again on the 2023-07-18 telecon:

@dlongley noted that we have "Exchanges" and "Exchangers", and need to differentiate. An Exchanger allows you to create exchanges, any particular Exchanger is a factory that builds exchanges. An individual exchange is one interaction between a particular client and exchange surface, facilitated by the coordinator. When a user visits an issuer-coordinator, issuer-coordinator, based on interaction, creates an exchange that results in a URL that they hand over to end user, which interacts w/ exchanger service to complete exchange.

Is it fair to say that types of exchanges could be "request-credential", "request-proof", "present-proof", "send-message", "initiate-connection", "did-exchange", etc? If so, how would these manifest in a real interaction?

@dlongley noted that out of the whole list, some make sense, others don't. You might have an exchange that just does did-auth. If user is on website and they just want to prove control of DID to website, they can perform action on website to do that, website uses website to use DID Auth Exchanger, to create an exchange, so user could do that. Exchange is set up with state that indicates, has VPR, provides challenge, asks for DIDAuth, hands VPR to user, wallet uses Exchange URL to perform DID Auth. Website gets DID presented at that exchange, that's one exchange that could work.

"request-credential" isn't specific enough. "Request an Employee Credential" would be specific enough. issuer-coordinator would use "Request an Employee Credential" Exchanger to create exchange to get employee credential.

@dmitrizagidulin noted that "request-credential" isn't specific enough... what are the general categories was asked and some of these are proper general categories. Problem might be about calling it a specific type of Exchanger.

@dlongley noted that "When would you use an Exchanger?" -- perform did auth, request credentials, issue credential, endpoints that just issue VCs w/o any authn necessary, etc. When you create an Exchanger, you create one or more steps that individual will go through and Holder will be expected to provide VCs, at end of exchange either you get back presentation with VCs in it, or exchange is complete (and you don't receive anything).

@dmitrizagidulin noted that at MIT DCC, they've been discussing diploma credential issuance workflow based on Exchangers. Wrote up 3 phase step through of how student picks up diploma using Exchanger. Other thing of note, increasingly seeing need for challenge manager/transaction manager service in VC API diagram, needed when implementing issuer coordinator app to use exchangers to pick up authenticated credentials.

@dlongley An exchange is intended to be transactional, bound to a particular transaction, that is what's going to keep track of state of particular transaction... @dmitrizagidulin noted Exchanger for transaction manager, need separate component, challenge manager. @dmitrizagidulin noted more word smithing required on naming and explaining how this works. @dlongley noted that "issuer instances" have state information needed to issue VCs w/ combinations of parameters, particular instance has capability to issue w/ specific key, cryptosuite, status mechanism, etc.... all of that is bound up in issuer instance configuration. An Exchanger works similarly, it would have configuration information... template for one or more credentials, credentials for talking w/ issuer instance, credentials for talking w/ verifier instance, general state information and set of steps that an exchange would take an individual through, has general information. When particular user shows up at website, website uses exchanger to create exchange for user (includes sending any variables to exchange that's being created, passing those in state data for new exchange, for that specific transaction, rest of information is inherited from exchanger).

@dmitrizagidulin noted that they came up w/ same design w/ different names and would like to talk through w/ the VC API group, scheduled for next week.

@dlongley Another way to think about Exchangers is that an exchanger defines a specific flow, and an exchange is an instance of that flow, where a user is going through the flow.

Which url would be called (how to map an exchange_id to what it's actually doing?

@dlongley noted that a website would have access to N exchangers, each defining different flows that a user could go through, based on user selection on website, one exchanger would be chosen and used to create new exchange URL to take user through the chosen flow. That new exchange URL is the exchange_id.

What would be returned when I hit GET /exchanges?

The group hasn't defined this yet and doesn't know if they want to define it yet... the URL path would probably be

.../exchangers/EXCHANGER_ID/exchanges/EXCHANGE_ID

We could return all exchangers if GET ../exchangers or return all exchanges for a particular exchanger if GET ../exchangers/EXCHANGER_ID/exchanges is called, but utility of both calls is unknown at this time.

How could we create a parallel between exchanges and DIDComm messaging?

The group didn't feel it had enough expertise in this area to comment, and @PatStLouis is probably the best person to map between the two mechanisms. @dlongley's best guess is some DID Comm Agent would send a message that results in an exchange being created and an exchange URL being returned, which you could then use to complete a DID Comm flow. An exchange could be interacted with using a number of different protocols.

Today, we know of implementations that use VC API Exchangers and exchanges that complete OID4VCI flows. The same should hold true for DIDComm.

@brianorwhatever noted that sounds about right, you could start with VC API Exchanges and complete w/ DID Comm, or start w/ DID Comm and complete w/ VC API Exchanges.

Is there a defined concept of states for each agents throughout these exchanges/interactions?

@dlongley noted that there is state associated with the exchange. @dmitrizagidulin was talking about transaction managers earlier. There is state associated w/ exchangers/exchanges, but use of "agent" is DID Comm specific, if completing process on DID Comm, there would be state (both on server and in agent in flow).

@dmitrizagidulin noted that there is a notion of explicit states, even for purposes of documentation, there is, after each phase of workflow, there is state that each actor in the flow keeps. @dlongley one goal is to try and make implementation details of how state is tracked isn't prescriptive, ideally, we can define interaction w/ endpoint using VPR and VPs and POST or you are using another protocol that defines messages you use... in any case, how state is tracked within an implementation, can be implementation specific. That would be ideal. However, we might have to say something about retrieving result of an exchange and what that might look like. When website creates exchange, website will need to get result of exchange. Could get very complicated w/ callbacks from exchange, if we don't do that, we might need to define GET method on exchange, that's authorized, where you have to get result of exchange. It might be better for every implementation to make it look the same, might be additional info ... result of GET on particular exchange should provide state on particular exchange, saying if it's complete, and result (data that is received from user, VCs, DIDs, etc. that were verified).

Some of the content above is going to have to find it's way into the specification. Marking as ready for PR so that it can be incorporate in time, when we document Exchangers and exchanges in the specification.