- 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