- From: Joe Andrieu <joe@legreq.com>
- Date: Mon, 02 Aug 2021 12:23:33 -0700
- To: "Credentials Community Group" <public-credentials@w3.org>
- Message-Id: <747d62b6-395e-42c1-8829-c0eb2f2fe3fb@www.fastmail.com>
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. -j 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