Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GET Exchange Response endpoint #429

Open
jrhender opened this issue Nov 7, 2024 · 0 comments
Open

Add GET Exchange Response endpoint #429

jrhender opened this issue Nov 7, 2024 · 0 comments

Comments

@jrhender
Copy link
Contributor

jrhender commented Nov 7, 2024

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant