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: Moses Ma <moses.ma@futurelabconsulting.com>
Date: Mon, 2 Aug 2021 18:18:05 -0700
To: Kaliya IDwoman <kaliya-id@identitywoman.net>, Credentials Community Group <public-credentials@w3.org>
Cc: Joe Andrieu <joe@legreq.com>, Adrian Gropper <agropper@healthurl.com>
Message-ID: <b105c1be-943f-12c4-7c9e-8265d100c827@futurelabconsulting.com>
Wow Kaliya, this is spectacular. +1 to you too.


On 8/2/21 5:43 PM, Kaliya IDwoman wrote:
> 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 
> <mailto: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
>     <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
>     <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
>     <mailto: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
>         <mailto:moses@ngenven.com>|moses.ma@futurelabconsulting.com
>         <mailto:moses.ma@futurelabconsulting.com>
>
>         /v/ +1.415.952.7888 <tel:(415)%20952-7888> |
>         /m/+1.415.568.1068 <tel:(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
>>         <mailto: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
>>>         <mailto: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
>>>>             <mailto: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?
>>>>                       o The Subject does need to understand what
>>>>                         the capability represents before deciding
>>>>                         to pass it on.
>>>>                       o  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?
>>>>                       o Browser
>>>>                       o App
>>>>                       o 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
>>>>                 <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
>>>>                 <mailto: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/
>>>>                     <https://www.linkedin.com/in/manusporny/>
>>>>                     Founder/CEO - Digital Bazaar, Inc.
>>>>                     News: Digital Bazaar Announces New Case Studies
>>>>                     (2021)
>>>>                     https://www.digitalbazaar.com/
>>>>                     <https://www.digitalbazaar.com/>
>>>>
>>>>
>>>
>>>             --
>>>             Joe Andrieu, PMP joe@legreq.com <mailto:joe@legreq.com>
>>>             LEGENDARY REQUIREMENTS +1(805)705-8651 <tel:+1(805)705-8651>
>>>             Do what matters. http://legreq.com
>>>             <http://www.legendaryrequirements.com>
>>>
>>>
>>
>>         --
>>         Joe Andrieu, PMP joe@legreq.com <mailto:joe@legreq.com>
>>         LEGENDARY REQUIREMENTS +1(805)705-8651 <tel:+1(805)705-8651>
>>         Do what matters. http://legreq.com
>>         <http://www.legendaryrequirements.com>
>>
>>

-- 

*Moses Ma | Managing Partner*

moses.ma@futurelabconsulting.com | moses@futurelab.ventures | 
moses@ngenven.com

v+1.415.568.1068 | skype mosesma | /linktr.ee/moses.tao/ 
<http://linktr.ee/moses.tao>

FutureLab provides strategy, ideation and technology for breakthrough 
innovation and third generation blockchains.

Learn more at /www.futurelabconsulting.com/ 
<http://futurelabconsulting.com>. For calendar invites, please cc: 
mosesma@gmail.com


Or whet your appetite by reading /Agile Innovation/ 
<http://www.amazon.com/Agile-Innovation-Revolutionary-Accelerate-Engagement/dp/B00SSRSZ9A> 
| /Quantum Design Sprint/ 
<https://www.amazon.com/Quantum-Design-Sprint-Application-Disruptive/dp/1799143864> 
| my blog at /psychologytoday.com/ 
<http://www.psychologytoday.com/blog/the-tao-innovation>.

NOTICE TO RECIPIENT: THIS E-MAIL IS MEANT FOR ONLY THE INTENDED 
RECIPIENT OF THE TRANSMISSION. IF YOU RECEIVED THIS E-MAIL IN ERROR, ANY 
REVIEW, USE, DISSEMINATION, DISTRIBUTION, OR COPYING OF THIS E-MAIL IS 
STRICTLY PROHIBITED. PLEASE NOTIFY THE SENDER IMMEDIATELY OF THE ERROR 
BY RETURN E-MAIL AND PLEASE DELETE THIS MESSAGE FROM YOUR SYSTEM. THIS 
EMAIL SHOULD NOT BE CONSIDERED BINDING; HARD COPY DOCUMENTS ARE REQUIRED 
TO CREATE LEGALLY BINDING COMMITMENTS. FOR CALENDAR INVITES, PLEASE CC: 
MOSESMA@GMAIL.COM
Received on Tuesday, 3 August 2021 01:18:40 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 3 August 2021 01:18:42 UTC