You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose that a new "Get Exchange Response" endpoint be added, at GET /workflows/{localWorkflowId}/exchanges/{localExchangeId}.
The purpose of the endpoint would be to return the "response" from the current step in an exchange.
The expected caller would be "anyone" (as it currently is with the Participate in an Exchange endpoint).
The response body would a Verifiable Presentation Request, a Verifiable Presentation, or a redirect URL. (This are the same response types as returned by Participate in an Exchange)
This endpoint is therefore similar to the "Posting an empty body will start the exchange or return what the exchange is expecting to complete the next step" guidance in Participate in an Exchange. However, the proposed endpoint isn't only for "the next step" (which to me implies a VPR or a redirect) but could also return the VP that is provided from the current step.
Conceivably, the response to "POST Participate" endpoint could be simplified to just a success or error response and clients could rely on the GET endpoint to get a VPR for next steps or the results VP. Furthermore, the above "empty body" behaviour could be removed to simplify the "POST Participate". The downside to this would be that clients would need to make to calls to continue exchanges (a first one to participate, and then one to get the exchange status/response). IMO, this downside might actually be a advantage as it provimaybe des command/query separation. I think the Post/Redirect/Get pattern, though not exactly for this use case, could be a reference.
A GET endpoint is useful for:
Use in redirects (as redirects typically a GET request, AFAIK)
More amenable to caching
The use case that is prompting this suggestion is asynchronous credential issuance. In this use case, an exchange is started by a holder (they may provide credentials, for example) but the issuer needs to provide the VP with the issued credentials before it can be returned to the holder.
sequenceDiagram
actor h as Holder
participant ws as WorkflowService
actor i as Issuer
h ->> ws: POST participate in an exchange
ws -->> h: get redirectUrl to exchange
h ->> ws: GET exchange response
ws -->> h: again get GET url
i ->> ws: provide VP with credentials somehow
h ->> ws: GET exchange response
ws -->> h: return VP
Loading
The text was updated successfully, but these errors were encountered:
I propose that a new "Get Exchange Response" endpoint be added, at
GET /workflows/{localWorkflowId}/exchanges/{localExchangeId}
.GET
endpoint is useful for:The use case that is prompting this suggestion is asynchronous credential issuance. In this use case, an exchange is started by a holder (they may provide credentials, for example) but the issuer needs to provide the VP with the issued credentials before it can be returned to the holder.
The text was updated successfully, but these errors were encountered: