W3C home > Mailing lists > Public > public-credentials@w3.org > August 2021

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

From: Joe Andrieu <joe@legreq.com>
Date: Mon, 02 Aug 2021 12:23:33 -0700
Message-Id: <747d62b6-395e-42c1-8829-c0eb2f2fe3fb@www.fastmail.com>
To: "Credentials Community Group" <public-credentials@w3.org>
I'm with Kaliya and Manu on this. A verifier should never have to talk directly to an issuer, especially about specific credentials. We have indirect mechanisms for checking revocation status and that's it. By design.

Adrian, phone-home anti-patterns are some of the most egregious in the book and they aren't needed for delegation, as Manu already discussed.

-1 to standardizing means for verifiers to directly reach issuers about specific credentials.


On Mon, Aug 2, 2021, at 12:18 PM, Kaliya IDwoman wrote:
> 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/

Joe Andrieu, PMP                                                                              joe@legreq.com
LEGENDARY REQUIREMENTS                                                        +1(805)705-8651
Do what matters.                                                                            http://legreq.com <http://www.legendaryrequirements.com/>
Received on Monday, 2 August 2021 19:24:10 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:21 UTC