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

It sure would, Moses. Please ask them to consider the Cruise Ship use case:
https://docs.google.com/document/d/1Mt1m-fVaSxY6QC3mgHcrNoNH-EnOTRepcwYd9hyjmxM/edit
as also posted in
https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0031.html

- Adrian

On Mon, Aug 2, 2021 at 7:59 PM Moses Ma <moses.ma@futurelabconsulting.com>
wrote:

> Wow Joe, very eloquently stated. +1
>
> However, Adrian has a valid point too. +1 as well
>
> I’m focused on the airlines sector right now, but I could connect to
> some cruise ship operators to get more of a user perspective. Would that
> help?
>
> MM
>
> *Moses Ma | FutureLab Consulting Inc*
>
> moses@ngenven.com |moses.ma@futurelabconsulting.com
>
> *v* +1.415.952.7888 <(415)%20952-7888> | *m*+1.415.568.1068
> <(415)%20568-1068> | *skype* mosesma
>
> *blog & social media: *my blog at psychologytoday.com
> <http://www.psychologytoday.com/blog/the-tao-innovation> | linkedin
> <http://www.linkedin.com/in/mosesma> | facebook
> <http://www.facebook.com/moses.t.ma> | twitter
> <http://twitter.com/mosesma>
>
>
> On Aug 2, 2021 at 16:50, <Joe Andrieu <joe@legreq.com>> wrote:
>
> On Mon, Aug 2, 2021, at 1:52 PM, Adrian Gropper wrote:
>
> It's not for us to limit the Subject's control over a verifiable
> credential at the point of issue.
>
>
> On the contrary, it is our job to design a system that enables individual
> self-determinism rather than simply propagating the power-structures of
> existing identity systems.
>
> A fundamental point of the VC architecture is avoiding phone home.
>
> Period.
>
> If you want to develop VC-like things that rely on, and advocate for,
> phoning home, that deserves a different track of work, perhaps one at the
> OpenID Foundation.
>
> To your specific Zuboff reference: As Zuboff says: "Who decides? Who
> decides who decides"?
>
> First, we decide because we are the community that came together to solve
> the problem of overly-centralized identity systems. If someone else wants
> to come together to solve a different problem, more power to them. As
> Elinor Ostrom taught us: those impacted by the commons should be the ones
> who decide. Right now, that's us. Our startups. Our dreams. Our mutually
> invested time, effort, and money.
>
> Second, we decide because the Subjects we care about are not capable of
> doing so. They (all 7 billion of them) simply can't join our weekly calls
> or actively participate in our working groups. We decide because somebody
> has to, or nothing gets done. The best we can do is be more open, more
> inclusive, and more transparent.
>
> Third, if we give the existing power structures the opening you are asking
> for, they will simply reify their existing power roles in this new tech
> layer. That would be a failure of this effort, full stop. A firebreak
> between issuer and verifier is vital to preventing the continued
> intermediation of large institutions into every nook and cranny of our
> life. And even then, our work merely creates an opportunity for such a
> power shift. Whether or not others will deploy the systems that actually
> make the world better is up to the market.
>
> Lastly, verifier's already have a way to check the status of a credential
> and issuers *can*, if they choose to, make that mechanism a phone home
> mechanism.
>
> But that is an antipattern and there are many of us, deeply committed to
> shifting the socio-economic power dynamics in the digitized world who will
> fight tooth and nail against standardizing to support any use case that
> depends on phoning home.
>
> If your use case requires phoning home, please, just use OAuth or OIDC or
> something similar. IMO, it's not part of this work, here.
>
> -j
>
> On Mon, Aug 2, 2021, at 1:52 PM, Adrian Gropper wrote:
>
> It's not for us to limit the Subject's control over a verifiable
> credential at the point of issue. If we try to do that, an added burden is
> placed on the subject because "we" think it's the right thing to do. As
> Zuboff says: "Who decides? Who decides who decides"?
>
> - Adrian
>
> On Mon, Aug 2, 2021 at 3:24 PM Joe Andrieu <joe@legreq.com> wrote:
>
>
> 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>
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>