- From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
- Date: Tue, 3 Aug 2021 15:03:29 +0000
- To: Kaliya IDwoman <kaliya-id@identitywoman.net>, Credentials Community Group <public-credentials@w3.org>, Moses Ma <moses.ma@futurelabconsulting.com>
- CC: Joe Andrieu <joe@legreq.com>, Adrian Gropper <agropper@healthurl.com>
- Message-ID: <MWHPR1301MB2094AB29B275EDFF55AC6C9AC3F09@MWHPR1301MB2094.namprd13.prod.outlook.>
Adrian, you lost me in the third paragraph of your use case where you call the passport a VC and the credential a VP. IMO, you've got them completely backwards.
Is this what you intended? I believe the use case needs to be corrected.
Michael
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Moses Ma <moses.ma@futurelabconsulting.com>
Sent: Monday, August 2, 2021 7:18:05 PM
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>
Subject: Re: Supporting VC-JWT and BBS+ Presentation Exchange in the VC-HTTP-API
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 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<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?
* 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<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/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
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>
--
[cid:part26.917F39CA.C0F745C3@futurelabconsulting.com]
Moses Ma | Managing Partner
moses.ma@futurelabconsulting.com<mailto:moses.ma@futurelabconsulting.com> | moses@futurelab.ventures<mailto:moses@futurelab.ventures> | moses@ngenven.com<mailto: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<mailto: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<mailto:MOSESMA@GMAIL.COM>
Attachments
- image/png attachment: FLClogo.png
Received on Tuesday, 3 August 2021 15:03:48 UTC