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

On Sun, Aug 1, 2021 at 3:35 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> 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".
>
> Why would we want to make the verifier talk to the issuer - isn't one of
the main points of SSI and the VC flow that the holder/individual gets the
credential from the issuer (the tester in this use case) and that THEY
transfer it ot the cruise ship or any other verifier of their choices - and
NEVER the shall the verifier and issuer shall meet about subject X.

As Manu said above the EDV can hold this in the cloud if it is standards
based it should be fine from a human rights perspective.

Maybe I'm just slow but why are we trying to get verifiers to talk directly
to issuers - isn't that what we are trying to end/upend by SSI.

- Kaliya




> 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/
>>
>>
>>