Mediated Holder Exchanges

[troyronda]

Cross-posted from w3c-ccg/vc-api#176 as I mentioned universal wallet.

[OR13]

I am excited to see this added to the universal wallet interop spec, we've been working on VP Request Spec JSON based APIs for exchanging content.

I see capabilities to a mediator a natural next step... summarizing:

1. Notify a VP (receive a domain and challenge)
2. Submit a VP (sign over the domain and challenge)

Consider the case where the VP contains an EDV authorization capability:

Receiving party can now invoke the capability and access all data associated with the requestors flow.

You can see a similar proposal we made here: decentralized-identity/confidential-storage#157

[OR13]

Its especially advantageous to rely on a mediator if the data is too large to pass over a browser or QR Code.

[OR13]

Here is a snippet from our universal wallet plugin for vp exchange:

it("alice notifies bob of intent to present", async () => {
  // request
  m0 = aliceWallet.createNotificationQueryRequest(
    "IntentToSellProductCategory"
  );
  // alice.send(m0, bob)

  // response
  m1 = bobWallet.createNotificationQueryResponse("bob.example.com", m0);
  // bob.send(m1, alice)
});

it("alice responds to bobs challenge and query with a vp", async () => {
  // normally alice might have this vc, in this case
  // for testing here, we create it on the fly
  m2 = await getVp(m1);
  // alice.send(m2, bob)
});

it("bob verifies and stores alice's vp", async () => {
  await bobWallet.verifyAndAddPresentation(m2, {
    suite: new Ed25519Signature2018(),
    documentLoader: documentLoader,
  });
  expect(bobWallet.contents[2].type).toBe("FlaggedForReview");
});

[OR13]

we're still experimenting with the interfaces, but we'll be making sure to align them in the spec here, based on feedback we receive.

[OR13]

ping @sudeshrshetty @dmitrizagidulin

[sudeshrshetty]

@OR13 I guess you are were designing interfaces for credential exchange APIs for holders as part of #75 & #76 .

In this mediator holder exchange flow, I believe only wallet holder comes under universal wallet's core interfaces. Rest of the features can come as part of plugin interfaces.

Universal wallet core interfaces might need to cover these steps:

• pushing encrypted presentation to mediator holder.
• returning presentation to verifier containing authorization code & mediator URL .
• registering mediator holders.
• registering service holders.
• for encrypting presentation we can make use of query.recipients from credential request.

also we need to consider the fact that a verifier may or may not have infrastructure to pull presentation at later stage from mediator.

[OR13]

I'm struggling to grok this exactly.

It feels like there are a couple things, which each might be connected to wallet apis:

Simple Presentations initiated by the sender pushing

1. wallets can present to each other over http. ( VC-HTTP-API / Traceability API / VP Request Spec )
2. wallets can present to websites ( CHAPI / VP Request Spec )

(this is what we have implemented today, with CHAPI and HTTP).

Mediated Presentations initiated by the receiver pulling

In both cases, there is some setup / registration that the wallet likely needs to have done.

Here you can see the setup we consider for the simple push oriented presentations:

• https://github.com/transmute-industries/verifiable-data/blob/main/packages/universal-wallet-vp-exchange-plugin/src/__tests__/vp-exchange.spec.ts
• https://github.com/OR13/simple-presentations

Can we perhaps label the steps in mediated presentations in terms of vp request spec and edv's?

[OR13]

@troyronda @sudeshrshetty

There are arrows with no labels, but I will try to add labels to the stuff that is numbered.

1. VP-Request Spec, Alice Requests Credentials from Bob.
2. Bob's front end wallet, tells his back end wallet (Service Holder?)... to construct and store a VP
3. Bob's Backend wallet (Service Holder?) pushes the VP to Mediator EDV.

...

I am stuck, I don't see how step 4 is triggered by the verifier (there is no response to them to step 1)

and EDVs don't push data, so the verifier is left in a state of waiting...

[OR13]

Case 0

The simplest meditated exchange is one where the mediator only collects encrypted presentations from a front end user agent / wallet.

[OR13]

Case 1

Is like case 0, but instead of directly submitting the encrypted VP to the mediator, the holder user agent requests a backend service do so.

[OR13]

Both case 0 and case 1, assume a verifier can decrypt.... this requires the verifier to do key management.

If we remove this requirement, the mediator can observe the presentation content.

For the sake of completeness, here is the original exchange API proposal (the one the traceability api supports today).

Case 2

[OR13]

Personally, I prefer case 2 as a starting point, not just because its what we support today, but because we have no real need for yet another word for holder... a mediator is a holder who aggregates presentations they can't even read, and then submits them as an unsigned presentation.... mediators don't do encryption or signing and they don't need to since they can't cheat if the verifier supports encryption.

For folks wondering how CHAPI fits into all this, CHAPI uses an iframe as a mediator...

https://github.com/digitalbazaar/credential-handler-polyfill/blob/0395b0c51f25bab2c0b2e727a44df0932dde5142/index.js#L18

Without encryption, which is safe as long as the polyfill isn't compromised.

There are 2 show stoppers in this flow.

1. Verifier Front End
2. Mediator iFrame

Thats pretty much game over for mobile application and machine to machine use cases for presentation exchange.

[troyronda]

Thanks very much @OR13 for creating these diagrams!

Personally, I prefer case 2 as a starting point.

For us, the case where we encrypt the VP through the back-end is quite important. We also have cases where we want to aggregate multiple VPs prior to the Verifier pulling. Agree that this has the complexity where the Verifier needs to decrypt. Of course, they already need to verify signatures so they have crypto work to do regardless.

We want to be able to support:

• Web Wallet producing VP (based on a link).
• Mobile Wallet producing VP (based on QR code).
• Service producing VP.

With the same integration for the Verifier.

a mediator is a holder

Yes - I think we should view this component as a Holder.

[OR13]

If case 2, step 6 used an encrypted VP, its essentially the same exact flow as case 0.

except for the fact that the VP is originating from a web wallet... whereas in case 1, it originates from a backend holder wallet.

[OR13]

It seems like the main things missing from the universal wallet spec to support these flows are:

1. JSON models for queries, with mediator addresses, and encryption keys (partially described in VP request spec)
2. An encrypted presentation object format, compatible with JWE.

[troyronda]

Another one:

In these "non-interactive" cases — like user agent creating the VP and/or asking services to create the VP, I assumed domain and challenge goes with Step 1. (and of course, in the final verifier pulls step, the back-end holder can have additional controls regarding domain before supplying the result).

[OR13]

yes, in case 2,

if the domain and challenge are part of the step 1, we can skip step 4, and go right to step 5.

[OR13]

Case 2.1

^ If we assume verifiers can decrypt.

[OR13]

In case 2.1, the verifier an receive an unsigned VP directly from the backend holder wallet... which in turn may hav collected VCs and VPs from an unknown number of intermediaries, before encrypting the aggregated VPs.... while its possible for 5 to use a signed VP, its not necessary, since each encrypted VP inside may be signed.

And the verifier will need to decrypt and verify each VP anyway.

[sudeshrshetty]

@OR13 about cases with mediator involved.

in some scenarios where a query can produce multiple credentials and we may have case 0 & case 1 combined. In that case, mediator has to wait for service holder to finish generating encrypted presentation. How mediator will know to wait for service holder before pushing notification to verifier?

[OR13]

@sudeshrshetty lets look at case 2.1 for the answer to that,

in step 4, the service agent gathers all VPs necessary to reply to the initial query... those VPs might come from the User Agent, or the might come from other backend services that the Service Agent as access too.

In either case, the Service Agent has the query, and knows when they have enough to proceed to step 5.

You might also have an unbounded number of untrusted mediators in step 5. this would align with original picture, except that now they no longer need to be stateful... since the Service Agent handled aggregation.

The question arises, can the Service Agent be trusted to handle aggregation.

I am asserting yes, since it can aggregated encrypted VPs as well as produce its own.

[troyronda]

those VPs might come from the User Agent

Yup - Part of "Collect Encrypted VPs" needs to allow a User Agent to push encrypted VPs to the Service Agent.

[sudeshrshetty]

Consolidating all the points from case 2.1,

• 1 verifier sending query to user agent holder: Any query from existing vp-request-spec can be supported. query.recipient can be used to supply encryption keys. In case of CHAPI, a response can be returned to notify verifier that request is successfully accepted.
• 2 notify await mediator
• 3 push query: user agent holder can push query or presentation (from locally found credentials) or both(for partially found results) to service agent holder. user agent may also need to send authorization (ex: zcap headers) to authorize service agent for pulling presentations from backend services (or agents). User agent may also need to forward encryption keys it received from verifier to be used by backend holders. A service agent can also be customized to act as mediator holder.
• 4 backend holder wallet gathers VCs and VPs: Service holder can call n number of backed services(or holder agents) to collect the results.
• 5 push unsigned presentations of encrypted signed presentations over domain and challenge: Can also have an unbounded number of untrusted mediators here.
• 6/7 presentation exchange complete:

@OR13 @troyronda let me know if I have misinterpreted or missed something.

Here are some assumptions:

• All backend holders including service holder are already registered to user agent holder. To enable user agent holder to choose right backend holder for incoming query, some kind of metadata exchange should happen during registration between user agent holder and backend holder. OR all backend holders can get registered to service holder instead to hide complexity from user agent holder.
• In case of multiple simultaneous queries sent from verifier front end to user agent holder: domain and challenge are enough to correlate response from verifier backend OR user agent holder should return some kind of token as a response to step 1 for correlation.

[OR13]

I'm at a session in IIW reviewing https://specs.bloom.co/wallet-and-credential-interactions/

[OR13]

@sudeshrshetty I think you got all the points... the main one we've been struggling with is how to support the registration phase, and how it relates to discovery...

I think naively, we assume from a public organization registry, like BCGov org book, a holder discovers credentials they may receive or present, does some setup phase, maybe related to "connections"... and then the protocols we are talking about here kickoff.

[sudeshrshetty]

@OR13 how about using credential manifest during registration of backend holder with user agent holder? Backend holders can send credential information in similar data format during registration.

[OR13]

@sudeshrshetty yeah, I think its possible that we might move faster building on top of the DIF / Bloom specs in this regard.