Re: Supporting VC-JWT and BBS+ Presentation Exchange in the VC-HTTP-API

Delegation is the essence of both the Cruise Ship use case and the Law of
Agency perspective on human rights. So, in principle we're on the right
track.

In the use case as you describe it:

   - The healthcare provider is an Issuer - they clearly have the data in
   the clear.
   - The Issuer gives a capability to the Subject (patient) that they can
   store in a mailbox or a wallet or anywhere else.
   - Cruise ship booking software as Verifier makes a request to the
   Subject.
   - If the Subject agrees to the request, they return a capability and a
   pointer to "someAPI".

Based on the above:

   - Why would the Subject care if someAPI was a an EDV, Hub, VC-HTTP or
   anything else? It's the Verifier that has to deal with someAPI.
   - Why would anyone care where the Subject processes the request?
      - The Subject does need to understand what the capability represents
      before deciding to pass it on.
      -  The Subject may want to attenuate the capability before passing it
      on.
   - What is the user-agent that the Subject uses to display the request,
   inspect the capability, maybe attenuate it, and pass it on to the Verifier?
      - Browser
      - App
      - Authorization Server (may act autonomously, based on policy)

My point is that the Subject should have minimum constraints on how and
where they process requests while the Issuer and Verifier should be
maximally constrained because they are the sovereigns. I think the
Robustness principle applies:
https://en.wikipedia.org/wiki/Robustness_principle The Issuer and Verifier
APIs should be conservative in what they send (capabilities and VCs) so
that the Subject's user-agent or delegate has a relatively low cost of
processing.

The human rights perspective aims to reduce the Subject's costs or barriers
to delegation and reduce the risk of lock-in even if the costs to the
Issuer and Verifier are increased. The Subject's costs are the sum of
processing the request (helped by the general purpose RAR standard) +
understanding and attenuating the capability. The Subject's choice of
Browser, App, or Authorization Server should be opaque to the Issuer.

By definition, the Subject is forced to trust the Issuer. To reduce the
Subject's cost, Issuers might provide a UI for requesting capabilities. The
Subject can then use a less sophisticated user-agent or just pass the
capability along to the Verifier or to an Authorization Server that they
trust.

The Issuer should have no say in what the Subject does with the capability.

- Adrian

On Sun, Aug 1, 2021 at 3:31 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 8/1/21 1:22 PM, Adrian Gropper wrote:
> > we might summarize your argument as economic and mine as human rights.
>
> I certainly wouldn't summarize the argument in that way; it's misleading.
>
> Adrian, don't EDV's solve your Cruise Ship use case without violating any
> human rights?
>
> * EDVs store Verifiable Credentials.
> * EDVs support cryptographic delegation via ZCAPs.
>
> Digital Bazaar's backing store for our Digital Wallets use EDVs, which
> means
> that the controller of a digital wallet can cryptographically delegate
> access
> to any party the controller wants to.
>
> This means that the EDV controller (healthcare provider) can delegate
> access
> to an invoker (patient), who can then further delegate access to another
> invoker (cruise ship booking software) to get access to a specific
> healthcare
> record (for an appropriate time period).
>
> Why doesn't that address your Cruise Ship use case?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>