Re: Authorized Issuer Lists

Joe, you said:

> 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.
>

Maybe I am missing something, but that doesn’t seem possible in many use cases.  Since a DID has to be resolved and then accessed, whomever is holding that DID document (which I am going to assume sits behind some form of service responding to the DID Resolution) can track access.  This is no different than a web server doing analytics/tracking.

If the DID could be issued by the issuer, and not provided by me (for various reasons), then the issuer would know every time that VC/DID is accessed.

Am I missing something??

Leonard

From: Joe Andrieu <joe@legreq.com>
Date: Saturday, August 20, 2022 at 12:18 PM
To: Credentials Community Group <public-credentials@w3.org>
Subject: Re: Authorized Issuer Lists

EXTERNAL: Use caution when clicking on links or opening attachments.


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/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c-ccg.github.io%2Fvc-status-rl-2020%2F&data=05%7C01%7Clrosenth%40adobe.com%7C8e5764d80c074fc1f50a08da82e0a1da%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637966198976171338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SZY7V748UBz7si5IW9mnNU0gUmX33j6iFMsSilVzsnU%3D&reserved=0>, 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__http%3A%2Fwww.hpec.io__%3B!!BClRuOV5cvtbuNI!QLgr-9v0mEJ0bGW0SLDNYF_8dYw-BYV4teeTJkQSpL9kk1vSkctKrZpyXc4B6oEJ6MP1%24&data=05%7C01%7Clrosenth%40adobe.com%7C8e5764d80c074fc1f50a08da82e0a1da%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637966198976171338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aq7U%2BYwDTwldGp3%2FoaO1vmnE%2Fesuh9QZW032hL8%2FlF4%3D&reserved=0>
Humanitarian Physicians Empowerment Community
Humanitarian Physicians Empowerment Coin



--
Joe Andrieu, PMP                                                                              joe@legreq.com<mailto:joe@legreq.com>
LEGENDARY REQUIREMENTS                                                        +1(805)705-8651
Do what matters.                                                                            http://legreq.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com%2F&data=05%7C01%7Clrosenth%40adobe.com%7C8e5764d80c074fc1f50a08da82e0a1da%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637966198976171338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oOGy%2BP9sypSbwsB0Ys%2Bksff1Kx8Do6iFd8vtvlKi95U%3D&reserved=0>