Mediated Holder Exchanges

[troyronda]

Goal: VC HTTP APIs that enable the exchange of verifiable presentations between back-end services. This exchange should work for both scenarios that require a User UI and also for those that do not. A single exchange should also facilitate scenarios where VCs from multiple Holder services are needed to fulfill the request.

There has often been an assumption that a Wallet (or similar) is the Holder of the VCs, and that the VP flow occurs in the front-end. As an example, a protocol such as CHAPI can make a JavaScript request for VPs to the Wallet and receive back the VP response via JavaScript. More recently, there has also been additional effort applied to define APIs for service-based Holders where, eventually, the flow could occur in the back-end.

Defining the data flow purely in the front-end raises some complications:

• Holder exchanges that do not involve UI - example: services running based on defined rules.
• Holder exchanges that cross user devices - example: working on the web but using a mobile wallet.
• Holder exchanges that involve credentials that should be generated just-in-time (JIT), or are otherwise not appropriate to be held in a Wallet app.

To enable back-end flows, we could define APIs to enable:

• Holder services to create encrypted presentations that could be pushed to a (mediator) Holder for later pickup by a Verifier.
• Enable a (mediator) Holder to store encrypted presentations.
• Enable the Verifier to pull stored encrypted presentations from the (mediator) Holder.

Likewise, we could also enable the universal wallet to create encrypted presentations that can be pushed to a (mediator) Holder and facilitate presentation requests.

[jricher]

We've been having conversations in the Grant Negotiation and Authorization Protocol (GNAP) working group in the IETF recently about how to incorporate exactly this kind of thing. There's a PR for this here:

ietf-wg-gnap/gnap-core-protocol#242

And you can read the relevant section with proposed changes here:

https://deploy-preview-242--gnap-core-protocol-editors-draft.netlify.app/draft-ietf-gnap-core-protocol.html#name-determining-authorization-a

Essentially, in OAuth 2 the assumption is that the user gets redirected to the AS on a web page, where they log in and interact through their browser. GNAP intends to be much more flexible here, reflecting how people use OAuth-style protocols today and how they could be used in the future. I personally see a system like the above fitting into GNAP really well. I'm fuzzy as to how exactly it would be connected together, but I'd love to see some bits-on-the-wire proposals of how these can be connected.

My strawman take:

1. GNAP client instance is the mediator acting on behalf of the wallet holder
2. GNAP AS is the verifier, needs to have credentials presented
3. client instance indicates to AS that it can facilitate a connection with the wallet
4. AS and client instance negotiate the exchange about what's needed, and things are presented
5. AS issues an access token to the client instance based on the rights presented by the holders

Now I'm not convinced this is exactly the right mapping, but I feel like the general pattern holds up well and there are enough similarities between the situations that we should pay attention and align them. I think the protocols solve different and complementary problems.

[OR13]

What is the "Service Holder" ? An API with access to data that will be provided to the mediator on behalf of the wallet holder?

[troyronda]

@OR13 yes, that's how I think of a service holder.

But, for more clarity: The service holder can create encrypted presentations based on the data it can access.

So it is acting as a holder that is authorized by the wallet holder.

[OR13]

See my comment here: w3c-ccg/universal-wallet-interop-spec#84 (comment)

I don't understand how the mediator can notify the verifier to pickup, or without being notified, how the verifier knows how to pull... I think step 1 may need a response arrow.

[bumblefudge]

On today's VHAPI call, need/desire for a holder-to-holder diagram in the architecture.md page of VC-HTTP-API spec was expressed, as well as an exploratory conversation about architecturally-complex holders (which might, separately, justify a PR adding more boxes to the starting-point holder diagram).

[msporny]

We discussed this on 2022-04-05, @mkhraisha gave us an update, we need to make sure that the diagrams in the specification have been updated -- we need a holder->holder direct exchange w/o issuer in the middle, but we don't have that diagram.

The next step here is to create a diagram that demonstrates holder->holder flows.

[jandrieu]

I don't think Holder -> Holder makes sense with our given definitions. Holder is a role. Anyone can play any role. So whoever is a "holder" can also be a "verifier"

So, in a Holder->Holder flow, the second holder is acting as a verifier, which is a flow we already have.

[msporny]

The group discussed this on the 2023-12-05 call:

@jandrieu noted the above. That there is never Holder->Holder exchanges, but noted some concern about fully understanding the diagram at the top. @dlongley noted that Workflows and Exchanges provide a complete answer and that we will revisit this issue once that section of the specification has been written.

The group noted that it will come back to this issue once we have workflows and exchanges more completely documented in the specification.

[msporny]

The group discussed this on the 2024-06-11 telecon:

@msporny noted that we have defined exchanges and workflows now, so we can pick this back up for discussion. @PatStLouis noted that Anoncreds style flows with mobile wallets do establish connections w/ mediator, messages go through mediator (that's how it works for DIDComm). Wallet can communicate with mediation between different systems (non-browser API driven). @msporny noted that the specification now has the concept of "coordinators" and "workflows and exchanges" allowing any role in the ecosystem to achieve what @troyronda noted above as an "emerging capability".

There were no objections to closing this issue as the group felt that we had achieved the functionality originally contemplated when the issue was raised. Closing.