- From: Harrison <harrison@spokeo.com>
- Date: Sun, 3 Jul 2022 14:44:12 -0700
- To: Adrian Gropper <agropper@healthurl.com>
- Cc: Kerri Lemoie <kerri@openworksgrp.com>, Mike Prorock <mprorock@mesur.io>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CAFYh=43WFqLu1ZZi5W4rodqGx_0rYpVLUEZLRWpQ2bJ__RqFoQ@mail.gmail.com>
Thanks, Adrian, for your detailed clarification. One follow-up question: Could this "Service Provider" be the Holder (which could be different from the Data Subject), or a software agent or identity wallet that acts on behalf of (and in the interest of) the Data Subject? In the case of the Apple "App Tracking Question" example, isn't Apple basically that software agent that acts in the interest of the Data Subject (in the interest of the Verifier or Issuer)? Or in the case of mDL, if we have a software agent (or Holder) that could smartly aggregate mDL or VC or other credentials into a Verifiable Presentation, and if we could convince most Verifiers to adopt VC, then the Data Subject could get selective disclosures via predicates or ZPF or features that Verifiable Presentation supports, correct? If we could agree that the Service Provider is basically the Holder (which could be different from the Data Subject), then I think the current Verifier-Holder-Issuer model still stands. Sincerely, Harrison On Mon, Jun 27, 2022 at 6:41 AM Adrian Gropper <agropper@healthurl.com> wrote: > Hi Harrison, > > There are a few reasons and examples: > > - *Burden:* GDPR's cookie notice is an example of burdening the human > with passive-aggressive "choices" that explain "purpose" while saving the > policy state in opaque and unnecessarily diverse ways to make the whole > process frustrating and often a unsatisfying waste of time. Compare that > with Apple's app tracking question that asks you once per Verifier, always > the same way and in a simple binary choice. Apple, in this example, is > inserting itself as a fourth party to the transaction acting on behalf of > the person whether the Verifier (website) likes it or not. Apple is taking > some power away from the Verifier and effectively giving it to the person. > - *Coercion*: At Identiverse, the mobile driver's license session > https://identiverse.com/idv2022/session/841461/ described _dozens_ of > human life domains that currently use driver's licenses as part of a > transaction. All but a handful of these do not need the strong, > non-repudiable, biometric, and globally standardized information about the > human. The person has no choice or power over the "Issuing Authority" and > the general expectation that adults have a driver's license. The person may > have ways to present alternative credentials to the Verifier but, in > general, these ways are more complicated, slower, and place the burden of > "selective disclosure" on the person like GDPR above. Yesterday, I tried to > buy some food online from ShakeShack. When it came time to pay, they > insisted on GooglePay or a huge amount of personal information to use a > credit card. There was no ApplePay option or even PayPal. Because this > was Harvard Square, I abandoned the purchase and bought something else down > the street. But in the typical case, the person has little choice over the > Verifier at the point when credentials are demanded. > - *Lack of Transparency*: With rare exceptions, such as standardized > apartment rental agreements, the Issuers and Verifiers are able to produce > unique contracts and various "dark patterns" that put substantially all of > the processing cost on the person. We get "Privacy Policies" and > "Shrink-Wrap Licenses." It's almost impossible to find examples of an > alternative to this practice or a mitigation in the three party model that > we're building SSI on. > - *Delegation:* In domains where burden, coercion, and lack of > transparency are deemed a human rights issue, societies introduced licensed > delegates we call doctors and lawyers that are _chosen_ by the person based > on mandated standards that preserve the right to choose a delegate. These > delegates are paid for their time based on their expertise. For example, > many societies restrict direct-to-consumer drug advertising and almost all > societies allow off-label prescribing because they recognize that > centralized regulation of Issuers and Verifiers is impractical. > > Pretty-much all of the work on SSI has been funded by either government or > intermediaries with little direct representation of individuals and > advocates. The assumption has been that what's good for the government is > good for society. Another assumption has been that SSI has to be efficient > for transactions that do not involve people as the subject. International > customs practice is often the use-case. We discuss batch processing of > items in a container. When people are the subject, the classical example > has been a work permit issued to a refugee by an authority and verified by > an employer. Can you think of a case where the person has less power than > that? > > - Adrian > > > On Sun, Jun 26, 2022 at 4:23 PM Harrison <harrison@spokeo.com> wrote: > >> Hi Adrian, >> >> If you don't mind, can you expound more on why you think Issuer and >> Verifier hold more power than Holder in the current Issuer - Holder - >> Verifier model? >> >> In this triad, the Issuer and Verifier hold immense and, as the EFF blog >>> post points out, almost unchecked, power over the holder. >> >> >> In the current model, Holder intermediates the identity-related >> transaction, and since the middleman usually controls the multi-sided >> platform, my understanding is that Holder should hold more power than >> Issuer and Verifier. Why do you think this is not the case? And how could >> the new "Service Provider" party address the problem? >> >> Thanks, >> Harrison >> >> >> On Fri, Jun 24, 2022 at 12:26 PM Adrian Gropper <agropper@healthurl.com> >> wrote: >> >>> Today, I’m answering calls from reporters after the SCOTUS vs. Roe >>> decision. My comments highlight the lack of federal privacy laws as >>> described in this article. >>> >>> Yesterday, at Identiverse, I organized a panel “*Human Rights >>> Perspective on W3C and IETF Protocol Interaction*” >>> https://identiverse.com/idv2022/session/841489/ that calls out the >>> enhanced surveillance efficiency from standardized digital credentials >>> compounded by the tendency to user strong digital credentials like mDL >>> rather than deal with the burden of clicking GDPR-like selective disclosure >>> boxes. >>> >>> Here is the protocols sequence that Eve Maler, Justin Richer and I >>> discussed as a potential mitigation: >>> A video with my slides and the full discussion will be posted. >>> >>> Many of the talks and keynotes at Identiverse highlighted the inadequacy >>> of a simplistic Issuer - Holder - Verifier model. In this triad, the Issuer >>> and Verifier hold immense and, as the EFF blog post points out, almost >>> unchecked, power over the holder. For example, Eve Maler’s keynote, at the >>> start of Thursday Identiverse, discussed the need to add a separate >>> “service provider” party to the Issuer-Holder-Verifier model. In the >>> diagram above, this would be the Delegate Server as manager of the resource >>> owner’s policies. >>> >>> Adrian >>> >>> On Fri, Jun 24, 2022 at 2:38 PM Kerri Lemoie <kerri@openworksgrp.com> >>> wrote: >>> >>>> Thanks, Mike. >>>> >>>> >>>> On Jun 24, 2022, at 1:51 PM, Mike Prorock <mprorock@mesur.io> wrote: >>>> >>>> Good topic for CCG discussion and reading on the implications of a lot >>>> of the tech we are working on: >>>> >>>> https://www.eff.org/deeplinks/2022/05/what-companies-can-do-now-protect-digital-rights-post-roe-world >>>> >>>> Mike Prorock >>>> CTO, Founder >>>> https://mesur.io/ >>>> >>>> >>>> >> >> -- >> *Harrison Tang* >> CEO >> LinkedIn <https://www.linkedin.com/in/theceodad/> • Instagram >> <https://www.instagram.com/spokeo/> • Facebook >> <https://www.facebook.com/TheCEODad> >> > -- *Harrison Tang* CEO LinkedIn <https://www.linkedin.com/in/theceodad/> • Instagram <https://www.instagram.com/spokeo/> • Facebook <https://www.facebook.com/TheCEODad>
Attachments
- image/png attachment: 42DEE2E3-8CF1-41E0-BE09-32E8BEE1E0CF.png
Received on Sunday, 3 July 2022 21:44:39 UTC