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

Since you all are talking about "the cruise ship" use-case relative to
COVID credentials.
 I will attach the recently completed and approved Good Health Pass
blueprint by the Interoperability Working Group for Good Health Pass at
Trust over IP.
 We are now shifting into the implementation phase.
 There is within what we have articulated no way for the verifier to talk
to the issuer by design - to protect the individual.
 The document I am attaching is completed - the press/PR announcements will
be next week on August 10th. So I would ask that folks not post about it on
social media etc until those announcements
  - Kaliya


On Mon, Aug 2, 2021 at 5:07 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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