w3c-ccg / vp-request-spec

Specification for a query language to request Verifiable Presentations from wallets etc.
https://w3c-ccg.github.io/vp-request-spec/
Other
9 stars 3 forks source link

Mediated Presentation clarification #17

Open jrhender opened 2 years ago

jrhender commented 2 years ago

Would it be possible to clarify the meaning of the Mediated Presentation interaction type and how a holder should react to this interaction type?

My understanding is that this interaction type is intended to signal that review of the submitted VP will require mediation, which means that the result of the processing of the submitted VP will may not be available for the HTTP response to the client. My assumption that use of this interaction type could result in a flow like this one:

sequenceDiagram

participant H1 as Holder-1 Client
participant H2 as Holder-2 Service

H1->>H2: submit presentation 
activate H2
  H2-->>H1: reply with "mediation in progress" VP Request
deactivate H2

par review presentation
  H2->>H2: process presentation and store result
and query presentation status
  loop At some polling interval...
    H1->>H2: query presentation review status
    activate H2
    alt presentation is processed
      H2-->>H1: return review result (possibly including VP with VCs)
    else presentation not yet processed
      H2-->>H1: return "mediation in progress" VP Request
    end
    deactivate H2
  end
end

Is this how others see "Mediated Presentation" as well? If not, is it envisioned that VP Request (and VC API) would support asynchronous presentation review flows (via duplex client-server HTTP) through some other means?

Regarding the flow above,

If I've misunderstood Mediated Presentation, my apologies!

msporny commented 3 months ago

The group discussed this on the 2024-07-30 telecon:

@dlongley noted that this question might not matter as much anymore in the current design because selection of a protocol may or may not include human interaction. We could just point to the VC API section on exchanges that involve human interaction and those that don't. The VPR spec can provide ONE example of human interaction (by pointing to the VC API specification).

A PR should be raised to point to an example that demonstrates a "human in the loop" exchange, most likely by pointing to the VC API specification and an exchanges example that includes a human in the loop.