Re: Good reading

Got it.  Is the main concern about the potential centralization (e.g. lack
of user choice) of the Holder ecosystem in the future?  If so, aren't
initiatives like CHAPI trying to solve this problem by creating an
open-wallet/holder ecosystem?

I feel that role-based access control can be thought of on 3 levels
(similar to the entity-relationship model in data):  Conceptual, Logical,
and Physical.  At the Conceptual high level, it would be good to keep the
roles (or technically, clusters of Logical roles) as simple as possible,
which is why I like the simplicity of the Verifier-Holder-Issuer model.
After all, people like and can remember the number 3.

Sincerely,
Harrison


On Sun, Jul 3, 2022 at 8:35 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> Harrison,
>
> The Service Provider (a fourth party after the Subject, Issuer, and
> Verifier) could indeed be the Holder in the sense that they are a delegate
> of the Subject but that does not do much to fix the confusion created by
> framing the discussion from the perspective of the Issuer and Verifier
> instead of the Subject.
>
> The fundamental problem with “Holder” is that in the real world there are
> many user agents:
>  - A wallet like Microsoft Authenticator for Subject or End User
> - An email or SMS inbox controlled by the Subject or end user
> - An enterprise system like Salesforce or hospital health record that the
> Subject or other end user is required to use
> - A self-sovereign delegate of the Subject like their spouse
> - A self-sovereign semi-autonomous agent of the subject in the cloud
> - A fiduciary delegate of the Subject like a physician that must
> authenticate in a non-repudiable way
> - An ankle bracelet or wallet controlled by some authority, not the Subject
>
> For each of these, we need to consider whether the Subject or end user has
> a meaningful choice of the user agent. Do we really have a choice of Apple
> App Store the way we might have a choice to use Duck Duck Go?
>
> Adrian
>
>
> On Sun, Jul 3, 2022 at 5:44 PM Harrison <harrison@spokeo.com> wrote:
>
>> 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>
>>
>