Mediated Presentation clarification

[jrhender]

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

Loading

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,

• What could a "Mediation in progress" VP Request look like? My idea is that it could be a VP Request with an empty credential query and an interact service where the client can query the status of the presentation review
• Could there be some way of signalling to the client what an appropriate polling interval could be?

If I've misunderstood Mediated Presentation, my apologies!

[msporny]

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.