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

On Mon, Nov 13, 2023 at 10:06 PM Kyle Den Hartog <kyle@pryvit.tech> wrote:
>
> ...
>
>  Essentially by saying that credentials can only be issued into trusted software it leads to an ecosystem where only Apple/Google OS based devices will work in this system.

I agree strongly with this statement. I think, if we do our work
right, wallets should be considered trustless. Capability detection
should not be about whether a wallet is "to be trusted", but rather
about whether it can interoperably perform a particular exchange of
credentials (with an issuer or verifier).

This doesn't mean that a wallet is not involved in any security-based
decisions nor that it won't need to help a user, for example, create a
digital signature over a presentation (directly or via an interface
with another piece of software and / or hardware). However, wallet
selection and trust decisions should be in the domain of holders.
Issuers and verifiers should be able to have confidence that they *do
not need to trust wallets* to get trust in the VCs and their
associated presentations. This means, for example, that in high
assurance use cases, verifiers should ask for liveness check VCs along
with whatever other VCs are being requested. It does not mean that
they should have to trust a wallet; rather, they should trust the
liveness check VC issuer, whomever that may be.

I think there's been a tendency for people to conflate the purpose of
"holder binding" (ignoring the questionable naming here for the
moment) with "anti-cloning" and similar goals. I think this comes from
the fact that a verifier is the party responsible for verifying a
"holder binding" proof on a presentation. However, in my view, this is
not primarily for the verifier's security, this is for the holder's
security. It is a check that is performed *on behalf of* the holder,
to give the holder confidence that the verifier will not accept their
credentials from some other holder (if they have been leaked /
stolen).

I do not see this as particularly different from any relying party or
website that checks a user's password (or other form of
authentication). If a website does not check your password when you
log in, then anyone can log into your account. Most people will refuse
to share valuable information with a website that has this poor
security practice. Again, this is a check performed by the website, on
behalf of the user. The only way in which this benefits the website is
that the user would not use the website's service if they didn't offer
this basic protection. This is not an anti-cloning mechanism. The user
can share their password or "log in" from any browser anywhere. There
is no "trust in the browser"; it is trustless.

If anti-cloning mechanisms are sought, they must not be based on the
platform -- or the platform will absolutely be a source of lock-in. To
whatever extent the cryptography can prevent cloning while best
respecting privacy (such as through per-verifier unlinkability), it
should be used. But we should stop trying to stretch a securing
mechanism that is intended to protect holders to be one that protects
verifiers against cloning / misbehaving holders -- as it just doesn't
work. Being able to generate a specific digital signature because you,
as a holder, have access to a key API to do so... is quite different
from restricting your ability to share access to that API. The
security comes from (and is enforced) in entirely different ways with
entirely different goals.


-- 

Dave Longley
CTO
Digital Bazaar, Inc.

Received on Tuesday, 14 November 2023 18:47:33 UTC