Re: Authorized Issuer Lists

I agree with Joe on the principles but this thread bounces around different
practical concerns.

Broadly speaking, we’re concerned with the reputation of issuers rather
than subjects and we don’t want to compromise the privacy or human rights
of subjects in solving for the reputation of issuers.

Issuers have choices and privacy rights. They typically choose to publish
affiliation with a certifier (the Good Housekeeping seal) and the burden of
checking validity with the certifier rests with various parties.

The basis for certification itself could include traffic analysis of
subject-specific issue or verification events. In this case, the subject of
these events would be at risk of privacy or human rights compromise. The
human rights problem might be forced association with an auditor or
intermediary entity they did not choose.

Even when the subject gets to choose the intermediary (e.g. a notary) there
is a huge risk of privacy violation. For example, subjects (and issuers)
will choose the convenience of a platform oligopoly for certification over
the privacy of a decentralized reputation check. The mitigation for this
problem is to standardize the reputation audit and checking process so much
that the platform cannot offer a more convenient solution. This is very
very hard to do because issuers may also prefer the convenience of using a
platform and may even get a kickback from the (surveillance capitalism)
platform.

Adrian

On Sat, Aug 20, 2022 at 3:17 PM Joe Andrieu <joe@legreq.com> wrote:

> On Fri, Aug 19, 2022, at 4:47 PM, John, Anil wrote:
>
> >… and the volume of usage of those issues credentials by verifiers can be
> tracked so that people can infer how trusted it is by the volume and
> diversity of who is using those verifiers
>
> > … Do any of the specifications support this kind of governance? I’d be
> curious to hear peoples thoughts on this.
>
>
>
> Curious about this as well.
>
>
>
> I would like to understand approaches to track “ … the volume of usage of
> those issues credentials by verifiers can be tracked so that people can
> infer …“ in such a manner that is resistant to gaming that metric, since it
> could end up becoming a situation very similar to how folks try to game
> Google’s PageRank algorithm.
>
>
> I would suggest that the design of VCs treats the goal of centralized
> tracking as a threat to individual privacy. In no way should VCs be
> designed or constructed to enforce this kind of oversight. This is why best
> practice for the credentialStatus property is to use something like
> Revocation List 2020. https://w3c-ccg.github.io/vc-status-rl-2020/,
> allowing verifiers to verify status without leaking the nature of the
> verification to the issuer.
>
> The moral imperative is that anyone can say anything with a VC, in a
> verifiable, tamper-evident manner. At the data model and protocol level,
> any restrictions on who can say what should be treated as an attack on
> individual liberty and a violation of the fundamental purpose of the
> architecture.
>
> That said, the design of VCs also allows any regulatory or
> compliance-enforcing body to say anything they want. It is perfectly
> reasonable to use VCs to assert that a given party, perhaps identified by
> DID, is recognized as a legitimate authority by another known authority,
> e.g., a state Bar Association issuing a credential attesting to the status
> of an individual with respect to that Bar association. This is the essence
> of the decentralized model of VCs. Not distributed peer-to-peer, but
> supporting any entity in its own role, including the inevitable emergency
> of authorities who are more respected than others and the eventual reliance
> on those authorities for particular assertions.
>
> However, at no point should the issuance VCs require any usage behavior to
> be trackable by anyone *uninvolved *in the issuance, nor should verifying
> VCs require any usage behavior to be trackable by anyone *uninvolved *in
> verification.
>
> It is this separation of issuing and verifying that creates the ability of
> the individual to have agency and privacy. Individuals gather what
> credentials they desire from those issuing parties they want to interact
> with, and then use those credentials at any other verifying party they want
> to interact with, all without centralized surveillance or third party
> knowledge of these interactions. If that surveillance is baked into the
> system, no individual is free from interference by those doing the
> surveilling.
>
> Unfortunately, the centralized thinking of the 20th century has led most
> IT professionals--I include most of us on this list in that broad
> category--to reflexively think about data problems as if the data is in
> some central location, against which various kinds of analysis could be
> performed, even analysis that was not anticipated when the system was
> created.
>
> This is basically the mindset that allowed the credit industry in the US
> to standardize around social security numbers as an identifier. That
> centralized ID was not designed for that use. Importantly, it was not
> designed to protect the freedoms of Americans when used in that fashion.
> GDPR's purpose-binding is an regulatory response to prevent this pervasive
> surveillance, hoarding, and analysis of data about individuals. Of course,
> it doesn't help Americans, but its an exploration of regulatory possibility
> that should be seen as experiment we can all learn from.
>
> When my clients need the ability to surveil all activity in a system,
> without privacy concerns, I recommend a closed proprietary system: don't
> use blockchain or other decentralized technology if your fundamental goal
> is, in fact, centralized. It is too much complexity that will add zero
> value. And for many use cases, it is the right thing to do.
> Decentralization is overkill for many situations.
>
> On the other hand, for my clients who have legitimate business needs, we
> can often construct a decentralized approach that creates the end value
> they need in the form of better profit, better quality, better reliability,
> better privacy, etc., without creating the risks and harms of centralized
> architectures.
>
> DIDs and VCs are technologies that enable such decentralized
> architectures.
>
> Yes, you can build centralized systems on top of it, just as companies
> build walled gardens with web technology.
>
> However, at no point should the underlying technology itself be defined in
> order to require such centralized surveillance.
>
> *From:* Leah Houston, MD <leah@hpec.io>
> *Sent:* Monday, August 15, 2022 7:40 AM
> *To:* Adrian Gropper <agropper@healthurl.com>
> *Cc:* Kyano Kashi <kyanokashi2@gmail.com>; Manu Sporny <
> msporny@digitalbazaar.com>; Steve Capell <steve.capell@gmail.com>; Tobias
> Looker <tobias.looker@mattr.global>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* Re: Authorized Issuer Lists
>
>
>
>
> *CAUTION: *This email originated from outside of DHS. DO NOT click links
> or open attachments unless you recognize and/or trust the sender. Contact
> your component SOC with questions or concerns.
>
>
>
> I think in order to avoid a dystopian situation there needs to be a way to
> self register on these lists… Anyone should be able to register as an
> issuer, and the volume of usage of those issues credentials by verifiers
> can be tracked so that people can infer how trusted it is by the volume and
> diversity of who is using those verifiers.
>
>
>
> For the medical industry I give the example of ABMS - The American Board
> of medical specialties vs NBPAS - The the national board of physicians and
> surgeons.
>
>
>
> ABMS Was trusted for many many years, and only recently over the last 5 or
> 10 years has come under extreme scrutiny because they started moving the
> goal post on Practicing physicians and raising the cost and effort needed
> to stay accredited. (They have actually been brought up on charges for of
> racketeering)
>
>
>
> NBPAS - has recently started to be accepted by the physician community and
> hospitals alike. Insurance companies will soon start to recognize it as as
> well.
>
>
>
> In this example the instant that A new accreding body like NBPAS becomes
> available the founders of the accrediting body could add that body to the
> list. Initially it would go un-utilized, however as verifying bodies start
> accepting the new credentials the usage can be automatically tracked and
> registered under that particular accrediting body. As time went on and
> usage went up but accrediting body will gain more notoriety based on its
> actual usage.
>
>
>
> I feel a governance structure like this is absolutely necessary because at
> minimum it gives a mechanism for the people to regulate the regulators.
>
>
>
> Do any of the specifications support this kind of governance? I’d be
> curious to hear peoples thoughts on this.
>
>
>
>
>
> --
>
>
> Leah Houston M.D.
> President and Founding Partner
> www.hpec.io
> <https://urldefense.us/v3/__http:/www.hpec.io__;!!BClRuOV5cvtbuNI!QLgr-9v0mEJ0bGW0SLDNYF_8dYw-BYV4teeTJkQSpL9kk1vSkctKrZpyXc4B6oEJ6MP1$>
> Humanitarian Physicians Empowerment Community
> Humanitarian Physicians Empowerment Coin
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>