Flows: Claim and Presentation

Wallet Server can process the same QR‑based flows used by mobile wallets. Flows are initialized from a QR URL and then confirmed. A flow remains active for ~10 minutes before expiring.

Initialize from QR

• POST /flows

  • Body:

    • qrContent (string): URL you scanned from issuer/verifier

    • did (string, optional): explicitly pass holder DID, if applicable

  • Response: { flowType: 'claim' | 'presentation', data: ... }

Depending on the QR type, one of the following happens:

Claim Flow (issuer QR)

1. Initialize: POST /flows returns { processId, status: 'initialized', offering }.

2. Confirm: POST /flows/:processId/confirm with body { "type": "claim" }.

3. Response: { status: 'confirmed', message: ... } after the SDK completes.

Presentation Flow (verifier QR)

1. Initialize: POST /flows returns { processId, matchingCredentialIds, matchingCredentials, status }.

   • If there are no matches, status is failed with an error.

2. Confirm: choose a credential and send:

   • POST /flows/:processId/confirm

   • Body: { "type": "presentation", "selectedCredential": { ...full VC json... } }

3. Response: { status: 'confirmed', message: 'Presentation verified' } or an error if verifier rejects.

Examples

Initialize:

curl -X POST http://localhost:3000/flows \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{"qrContent":"https://issuer-or-verifier.example.com/qrcode-data", "did":"did:example:123"}'

Confirm claim:

curl -X POST http://localhost:3000/flows/<processId>/confirm \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{"type":"claim"}'

Confirm presentation:

curl -X POST http://localhost:3000/flows/<processId>/confirm \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{"type":"presentation","selectedCredential":{ ... your VC ... }}'

Expiration & Concurrency

• Each initialized flow stores a short‑lived promise; if unconfirmed for ~10 minutes, it expires and is cleaned up.

• Confirmation must be performed by the same authenticated user that initialized the flow.

• Presentation confirmation requires the complete VC object (not just id).