- From: Adrian Gropper <agropper@healthurl.com>
- Date: Sun, 1 Aug 2021 18:33:30 -0400
- To: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CANYRo8h=9V4aWgn1dGWP5YEtfyO4WPyL+svMremKg7CzedNWmw@mail.gmail.com>
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/ > > >
Received on Sunday, 1 August 2021 22:33:54 UTC