Consider allowing a client to request information about an exchange via non-empty post body

[dlongley]

When a client is starting an exchange, it should be able to send a signal in a non-empty post body to request information about what action the exchange will perform prior to triggering that action. Some exchanges do not send a VPR and immediately issue one or more VCs -- and issuance is performed immediately in response to an empty post body. It would be nice to have an optional feature to show what will be issued to the client prior to issuance, even though a client or user should have received contextual information about that exchange prior to using it.

[dlongley]

An alternative to this is to allow a non-authorized GET on the exchange endpoint, but this might be more complex.

[msporny]

The group discussed this on the 2024-06-18 telecon:

@PatStLouis noted that a GET might make more sense and @msporny mentioned that its not clear why a GET would be more complex. A concrete use case was also not provided so it was difficult for the group to determine how this feature would be used. @PatStLouis noted that if a client wanted to continue an exchange, but doesn't know what state its at, but tried to move exchange forward but it didn't work, could be useful for client to know current state of exchange. @jrhender wondered how this is different from the "Get Exchange State" endpoint -- perhaps that endpoint could be extended for the use case that @dlongley has in mind. @wes-smith noted that this issue is not proposing a solution to status. POST'ing an empty body will say what the exchange wants and @wes-smith noted that that might not be the concrete use case that we need to look at.

The group needs more information from @dlongley on this issue before we can discuss the benefits of each solution.

[dlongley]

A concrete use case was also not provided so it was difficult for the group to determine how this feature would be used.

Usually, when an exchange URL is received by a client, information about what that exchange URL is for (or what can be expected to happen when posting to it) is also included with the exchange URL. However, a client that does not trust this information (or that does not receive it) might want to ask the exchange what will happen if the client executes the exchange, prior to executing it.

For example, if POSTing an empty JSON object to an exchange URL will immediately issue a VC, but this was unexpected by the client, then this might be an undesirable outcome. A client might instead desire to see some information about what will be issued / what the exchange will do prior to executing it.

Note: This scenario can be contrasted to an exchange that returns a VPR when posting an empty JSON body to it, which provides some information about what is required to proceed with the exchange before any VCs might be issued. However, even here the client relies on external context / out-of-band information to know what it will do once the VPR has been satisfied in a subsequent POST.

So, while a lot of use cases are covered by relying on trusted out-of-band information being associated with an exchange URL, it might also be nice to enable exchanges to report this kind of information when queried by consumers of (as opposed to creators of) the exchange. Notably, these consumers do not need to have an existing relationship with the exchange server (workflow service) nor do their clients need any authorization credentials. So the kind of information returned in response to such a query must be appropriately tailored for the consumer, i.e., it should not reveal information intended only for the creator of the exchange.

@msporny mentioned that its not clear why a GET would be more complex.
...
@jrhender wondered how this is different from the "Get Exchange State" endpoint -- perhaps that endpoint could be extended for the use case that @dlongley has in mind.

The current way to get the full state of the exchange (as the creator of the exchange) is to use GET <exchange-url>. This is an authorization-required endpoint, intended for privileged use. If a non-authorized client / user (i.e., a consumer of the exchange) could use this to get some minimal portion of the exchange state, then we have a single endpoint that behaves differently based on authorization level, which seems unnecessarily complex. I also don't think we have that complexity anywhere else in the VC API. Adding in that this endpoint is expected to be interoperable across many different clients (digital wallets), it seems like a less than ideal approach -- and one that is prone to costly implementation mistakes because of the lack of separation.

[msporny]

The group discussed this on the 2024-06-25 telecon:

There was general agreement that this could be supported via the client requesting a VerifiablePresentationRequest to the server, which can then respond with a VP or an error. The text should be added to the section on initiating an exchange.