Re: How much is it reasonable to generalize from the TruAge implementation?

On Thu, Nov 9, 2023 at 12:17 PM Adrian Gropper <agropper@healthurl.com> wrote:
> As we saw on Tuesday, TruAge is a milestone in privacy-preserving digital identity.

Thanks for your thoughtful questions during the call, Adrian, and for
your interest in the privacy architecture of TruAge.

For those that missed the presentation this past week, slide deck is here:
https://lists.w3.org/Archives/Public/public-credentials/2023Nov/att-0003/2023-W3C-Credentials-CG-TruAge.pdf

Video is here:

https://meet.w3c-ccg.org/archives/w3c-ccg-weekly-2023-11-07.mp4

> The design decisions they made are domain specific for convenience stores but the architecture seems more general in many ways.

Yes, at its heart, TruAge is a Personally Identifiable Information
(PII) tokenization system where the single-use tokens don't contain
any PII and are verifiable offline (due to the qualities of Verifiable
Credentials -- known issuer identified via a DID, standard credential
format, digital signature). TruAge goes the extra step to preserve an
individuals privacy by doubly-encrypting the PII so not even the
systems operator (TruAge) can get to the PII w/o an active subpoena
process requiring the systems operator, lawyers, law enforcement, a
judge, etc.

> Taken together, these four elements seem general and maybe essential for almost any privacy-preserving application of digital identity (standards) in a witnessed transaction like a convenience store or dispensary purchase. Sadly, TruAge does not cover the online use of digital identity but some of the four essentials will likely apply there as well.

It's possible to use TruAge tokens online (not deployed yet, but it's
a Verifiable Credential so can be sent to a website like any other W3C
VC), and that is a design goal of the system.

For example, ordering  a case of wine from an online store. Today, the
store just asks you if you're above the legal drinking age ("Ofcourse
I am!", says the under-age college student). In the future, the site
would ask you for a TruAge token... granted, there is no photo
verification like there is in a store by a sales clerk, but it's
better than asking the person if they're above age.

The delivery driver can request a TruAge token as well (just like a
clerk does in store, which is where the in-person image verification
is expected to happen). At no point does the individual have to upload
a picture of themselves (so, they continue to stay pseudonymous from
the standpoint of TruAge with the online retailer). That said, they
probably hand over at least a credit card and a shipping address to
the retailer, so their pseudonymity is blown at that point (unless we
use some other privacy protecting technologies around the payment and
the shipping location).

> 1. The witnessed link between a deduplicated gov credential such as a RealID driver's license and a digital identity could be strengthened by using federal postal workers instead of store clerks. Lying to a federal employee is very risky.

Yes, exactly.

> 2. The use of local biometrics for holder binding implies the use of a certified mobile app. What are the best practices for such apps and is the Open Wallet Foundation a good place to do that work?

Yes, and this is where it gets dicey.

I'm increasingly concerned by this whole "approved/certified app"
concept. It's going to be used for anti-competitive behaviour unless
we figure out how to create a more level playing field (and quickly
given the roll out of digital wallets and overzealous
issuers/verifiers that want higher-than-necessary assurances for a
variety of transactions.

Unless these certifications are based purely on "detecting features"
(you've proven that you have an HSM-bound private key) instead of
"detecting vendors" (you've proven that you're Apple, come on
through), I'm concerned that the road we're walking down leads to
centralization and anti-competitive behaviour wrt. certification.

Also note that "local biometrics" doesn't need to mean "on device".
Perhaps you trust a service operated by your law firm to be your
biometrics verifier, and any time there is a request for biometric
liveness, you tell the requesting party that your biometrics liveness
provider is your law firm and that check is done online, and the proof
that the check was done is the only thing the original relying party
gets. Tying biometrics to ONLY use local devices is one path to
ensuring the platform vendors are given more centralization power than
necessary; we should be careful about how this is done.

> 3. How centralized does the issue of one-time tokens need to be and what are the essential standards that will define the context for their issue?

Yes, excellent question, and in our experience with TruAge, having a
centralized token issuer is NOT a requirement. Just like there are 50
states that issue government-issued identification in the US, there
doesn't need to be ONE provider of tokens. It is important that you
don't allow double-spend on the tokens, and at that point you're
looking at some sort of centralized system or a decentralized ledger
of some kind, but the token issuance itself does not need to be
centralized.

> 4. What is the general principle for managing contextual logs to ensure Sybil-resistance as good as the link to a deduplicated gov identity (1.) without risk of privacy or cross-context surveillance?

Yes, another excellent question. Our experience was that 1) the more
sybil resistance a system has (when it comes to gov identity), the
more invasive the checks become, 2) the more invasive the sybil
checks, the less individuals will trust the system to have their best
privacy interests at heart, 3) the less trust in the system, the
higher the chances of adoption failure.

The cross-context surveillance has been the most challenging portion
of the program, any extra data that's collected has to be carefully
analyzed to see if there are cross-context correlation issues (and
there almost always are). Much of our focus was aggressive information
minimization -- don't collect anything more than the absolutely bare
minimum to meet regulatory burden, and even then, lock that data away
so it is very difficult for any single party to access it , and ensure
that there is a well known due process in place that optimizes for
privacy.

The general principle being: Every extra piece of information a system
collects creates privacy risk, and there is always a balance between a
system's Sybil resistance and its usability and trustworthiness wrt.
individual privacy.

> Answering these four questions seems essential to adoption of VCs and DIDs.

That is certainly true for some use cases, such as TruAge, though I'd
challenge whether it's essential when there is no expectation of
document privacy (such as a passport when crossing a border). I
certainly don't expect there to be anything that's off limits in the
passport I hand over when I fly into another country, though perhaps
your point is: How is that information I handed over used in the
broader ecosystem (the unseen network transactions that are behind the
scenes)? I'd argue that this particular problem isn't new to VCs and
DIDs and has existed for as long as there was the ability to "phone
home" to check the validity of a document.

To your question in the subject line: "How much is it reasonable to
generalize from the TruAge implementation?"

I expect that it can be generalized in the following ways:

* Tokenize any Personally Identifiable Information on any sort of
"official" identity document (to remove PII from flying around a
particular ecosystem)

* Vet an individual against the identity document (to provide sybil resistance)

* Use single use, non-correlatable tokens to prove association with a
valid identity document associated with a vetted individual, and
possibly, a non-correlatable attribute or two (age over, licensed to
drive, citizen of a country, shareholder).

* Perform transactions that require the proof of a particular
attribute, and possibly limit transactions based on established
regulatory limits, but in a privacy-preserving manner.

It was suggested that voting could be one such use case, and while I
trust that this system is good enough for age-gated or pharmaceutical
purchases... I would feel very uneasy suggesting that it would be
applicable to something like voting. :)

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Friday, 10 November 2023 22:58:13 UTC