Re: new ACLU Legislative Guidance

On Fri, Oct 11, 2024 at 1:07 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

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

A very nice summary.  Just to prove that I read the whole thing, I have a
question about #9.

A “right to paper" talks about the widespread use of fakes.  The reported
ages of the fraudsters makes me wonder what fraction of this use succeeds
because the verifier simply doesn't care or actually benefits, such as at a
club serving alcohol.  If enforcement of the law is lax, these venues
benefit from the fraudulent use.

What are the uses of such fakes that have actual victims?  Are they
widespread enough that such credentials will stop being accepted without
something like VCB?

--------------
Alan Karp


On Fri, Oct 11, 2024 at 1:07 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

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