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

On Mon, Nov 13, 2023 at 8:26 PM Steve Capell <> wrote:
> I didn’t think that anyone was suggesting that users would need to see or understand any of that stuff that manu lists.

Yes, correct... individuals can't be expected to understand the
details here, so they'll rely on "trust marks" and
"certifications".... but /something/ has to be behind those trust
marks and certifications, and that's where many of us come in -- to
set what the standard should (ideally) be there.

> I thought Anil was proposing an accreditation framework to certify wallet software to ensure that exactly the privacy and security concerns Adrian is advocating are met.  Users would just look for a trust mark when choosing / downloading software - which should of course be a verifiable credential itself

Yes, that's one possible solution as long as there are a wide variety
of wallet providers that can meet the requirements of the
accreditation framework w/o special deals w/ "gatekeeper
organizations" (platform vendors, governments, hardware vendors,

IOW, as long as the accreditation frameworks lead to a level playing
field with a very good privacy story, everything will be great. That
future is at risk based on what we're seeing develop in the market.

> Am I missing something ?

The thing I'm concerned about being overlooked, generally, is that the
way these accreditation patterns seem to be headed in is to take one
of these undesirable paths:

1. A government-supplied app with the sole authority to hold specific
types of credentials. This leads to tracking concerns because the
issuer gets to track when and where you use your credentials. Think of
a use case where a government issues an identity document, but you can
only use it with their app and no other digital wallet provider. Some
of the member states participating in the European Digital Wallet
initiatives seem to be hinting that this might be one of the paths
followed (a national digital wallet).

2. A platform-vendor app that is selected because the app is the only
application that has the capabilities that the government entity
accepts (because the platform vendor has convinced the government that
only they can provide a complete top-to-bottom security, because they
control the platform and don't give any other vendor the same
capabilities on their platform). Example: Lack of 3rd party NFC access
on Apple devices.

3. A mandatory anti-cloning capability that ensures that a digital
credential can't be issued to more than one device at a time, where
the proof of the anti-cloning capability reveals the device key, which
means that the digital credential is globally track-able. This defeats
some of the unlinkability use cases if used aggressively (and is what
I've seen being suggested by EU use cases as well as some US ones).

In other words, some of these accreditation frameworks seem to be
driven by an overzealous desire to "sell to" governments by vendors
proposing "maximum security" rather than privacy/assurance trade-offs
based on the use case at hand. To be fair, these are very difficult
discussions to have with some organizations and agencies because they
don't have the background training to navigate the choices. Couple
that with some overzealous vendors in the room that are promising
things that are probably not going to work out in practice, but
speaking up throws cold water on progress so vendors are reluctant to
"argue in front of the customer" and just push ahead hoping for the
best (that someone else will solve the problem before it becomes a big

-- manu

Manu Sporny -
Founder/CEO - Digital Bazaar, Inc.

Received on Tuesday, 14 November 2023 17:59:03 UTC