Re: new ACLU Legislative Guidance

On Thu, Oct 10, 2024 at 4:02 PM Kaliya Identity Woman
<kaliya@identitywoman.net> wrote:
> The ACLU has just published Legislative Guidance around Digital IDs
> https://www.aclu.org/documents/aclu-digital-id-state-legislative-recommendations

Vendor hat off, nothing I say should be construed as a position any of
our customers are taking or support. The following statements are in
my personal capacity only.

Great find, Kaliya, and I'll echo what Drummond said -- they've done a
fantastic job (for the most part) in identifying the problems with the
current digital ID rollouts and making some solid recommendations.
Some of their criticism around some of the ISO mDL roll out is spot
on, and as Adrian said, none of this is new to many of us. It is also
true that Verifiable Credentials are capable of addressing some of
these issues, but simultaneously true that VCs could fall to many of
the pitfalls that mDL deployment have had. The guidance that the ACLU
provides, for the most part, is a restatement of what many of us in
this community have been saying (and building) for a long time now.

For those of you that might be new to the space, I thought it might be
helpful to highlight each recommendation from the ACLU, and point out
specifically how the work we've done in this community attempts to
address each recommendation:

> 1. No police officer access to phones

VCs are cryptographically verifiable and transmissible to verifier
devices without having to hand a phone over. While this might sound
strange to some, some of the "digital driver's license" deployments do
require you to hand your phone over to law enforcement, which was
recognized long ago by this community as an anti-pattern. Technologies
that combat this practice: QR Codes for device engagement (both VC API
and OID4) as well as the vc-wireless specifications.

> 2. No Issuer ability to track via “phone home” mechanism

Cryptographic mechanisms such as Decentralized Identifiers, the VC
Data Model, and Bitstring Status List, all incubated in this community
and standardized at W3C, were designed to avoid "phone home". Though,
our work here is not done, as we will continue to have to combat
"tracking URLs" that some might want to put into VCs, either
advertently or inadvertently. One of the side-effects of fully
decentralized technologies is that they don't phone home. We're not
all the way there yet, but our focus on decentralization and the three
party model is what broke the often-repeated phone home anti-pattern.

https://www.w3.org/TR/did-core/
https://www.w3.org/TR/vc-data-model-2.0/
https://w3c-ccg.github.io/vc-api/#phoning-home-considered-harmful
https://www.w3.org/TR/vc-bitstring-status-list/

> 3. Granular control over data released (selective disclosure)

The work this community and the W3C Verifiable Credentials Working
Group has done on Data Integrity has explicitly focused on selective
disclosure and unlinkable disclosure, which empowers individuals to
only share what is necessary for a given transaction:

https://www.w3.org/TR/vc-data-integrity/
https://www.w3.org/TR/vc-di-ecdsa/

> 4. Unlinkability by verifiers (no digital ID as a ‘super cookie’)

Just this week, Dyne did a wonderful presentation on BBS and
unlinkability, following on the great work that Greg Bernstein had
done explaining how we're achieving unlinkability with Verifiable
Credentials. Yes, we want unlinkability, which is what the Data
Integrity BBS spec does:

https://www.w3.org/TR/vc-di-bbs/

However, the ACLU's position on this one feels a bit underexplained,
IMHO. Yes, we want unlinkability, but perfect unlinkability leads to
mass-scale fraud. I'm not sure the ACLU understands the problem at
depth, but at the same time, the goal (with a bit of nuance) is a good
general one to have. More specifically, you need unlinkability AND
per-verifier pseudonyms, which is something we've been working on in
W3C Data Integrity using BBS work. Though, you can't achieve this item
with unlinkability alone. More on pseudonyms here:

https://www.w3.org/TR/vc-di-bbs/#pseudonyms-with-hidden-pid

... and all the ways unlinkability, improperly implemented, can go wrong:

https://www.w3.org/TR/vc-di-bbs/#selective-disclosure-and-unlinkability

> 5. An open ecosystem - a. Open wallets, b. Private wallets, c. Transparent source code

Yep, each of those are important, which is why some of us pushed hard
for format and protocol agnosticism in the Digital Credentials API,
because some of the current choices fall short to achieve open
ecosystem goals. For example, some of the established requirements in
Europe, while the protections desired ("trusted" wallets) sound good,
they are highly likely to lead to closed ecosystems (even though
that's not a goal). For example, always mandating the verifier or the
wallet identify itself and then hand waving over the conformance
criteria for a wallet is a dangerous thing to do if what you want is
truly an open ecosystem.

Additionally, developing these standards in "closed" standards setting
bodies and processes, such as how ISO mDL continues to be developed,
is ill-advised for a technology meant for the global population to
use, as the ACLU rightly points out in their paper. As counter
examples, that the DC API, VC API, and OID4 are developed in full view
of the public is a good thing if the goal is open ecosystem, though
it's no guarantee; systems developed in the open can still fall to
centralization and walled gardens. You can have open source software
for effectively closed ecosystems. ACLU should probably put more
thought into this particular part of their guidance, though it is one
of the trickier things to get right.

> d. A standardized provisioning process

Again, this is why we're pushing hard to include "issuing" into the DC
API, VC API, and OID4, though some of those protocols make the mistake
of enabling vendor lock by only focusing on digital credential
delivery and not the whole credential lifecycle management process. VC
API goes further, by defining credential lifecycle management APIs, to
ensure that the organizations choosing a digital credentialing
infrastructure don't get locked into their vendors:

https://w3c-ccg.github.io/vc-api/#architecture-overview

> 6. Verifier accountability

This one is a slippery slope. Not all transactions need the Verifier
to identify themselves, especially when we already have a pretty
decent mechanism for doing so: HTTPS on the Web. People use domains
for this purpose today and layering in more than that, for most use
cases, doesn't make a ton of sense. In fact, with the Digital
Credentials API, this issue becomes a fairly fringe one that is
addressed by the Verifier just giving you a Verifiable Credential.
Many of the protocols that attempt to bake this in for every (or many)
transactions feel deeply misguided. The Holder-controlled logs of what
you've revealed to whom are useful, though.

> 7. A reporting requirement

Yes, 100%. Technology such as the ones described in the paper must be
developed and implemented under public scrutiny, not behind closed
doors. While some defend the ISO process of closed sessions, with no
publicly available minutes, and no requirement to address public
feedback, perform horizontal internationalization, accessibility,
security, or privacy review, others are rightfully criticizing that
approach (and some of the related EU processes) for not being
transparent in who is participating and building technologies that
will impact global society at large. I know this has been a point of
contention in this community (and others) for a while now, but the
criticism does not seem to be going away.

> 8. No remote government “kill switch” to disable people’s IDs

This one is a bit more nuanced because VCs can support this via
Bitstring Status List and "revocation", or one that only law
enforcement can access by gating access to the bitstring status list
(which would seem to meet ACLU's requirements), to not having a status
at all, which seems like it might also support ACLU's requirements.
Calling the capability "unnecessary" though seems a bit over the top.
There are also ways to selectively disclose this information and even
to unlinkably disclose the information that this community is working
on.

Fraud is perpetrated today because we don't have real time access to
credential validity, though the counter-point is taken as well --
exposing this to everyone might not be good for many use cases. It
also seems to be overly concerned with foundational identity documents
and doesn't call into where that sort of revocation might be more
appropriate, like for single use credentials (e.g., access to a ride
at an amusement park).

> 9. A “right to paper”

This is largely what the Verifiable Credential Barcodes work is about;
an individual's "right to paper" -- to continue to use physical IDs if
they so desire (but enabling those physical IDs to be more
trustworthy). What I haven't seen a lot of discussion around is how
easy it is to fake these traditional pieces of paper and plastic (59%
of people between the ages of 15-20 have a fake ID, and 70% of them
have successfully used that fake ID at least once, with at least 20%+
of them using it successfully on a weekly basis)[1], and if the fraud
levels keep going up, they'll stop being accepted and we'll be forced
into digital due to fraud costs. So, how do we keep using paper, but
gain some of the anti-fraud features of Verifiable Credentials to keep
paper around? That's what the VCB work is about:

https://w3c-ccg.github.io/vc-barcodes/

> 10. Restrictions on ID demands, 11. Restrictions on data use, 12. Enforcement through a private right of action

Yes, big +1 to this, though much of it is out of our hands... all of
those items require reasonable regulation at the federal and state
level.

IMHO, the ACLU did a solid job on the legislative recommendations.
There are only a few items in the write up that don't get into
important nuances that could end up having the opposite effect of what
is desired. It'll be interesting to see what ends up getting traction
both in the US, and the EU.

-- manu

[1] https://greenhousetreatment.com/blog/news/fake-id-usage-survey/
-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Friday, 11 October 2024 20:04:16 UTC