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

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

Yes, I'm generally in alignment with your thinking here @Dave. This
generally maps to how the web already works today for these sorts of
technologies as well. E.g. when I show up at some website that wants to
meet regulations today they KYC me and some perform a liveness check. In
this scenario, they don't need assurances that their JS executed properly
on my device or that an extension didn't tamper with it. Instead, they just
make sure that the response I send to them matches their criteria and if
there's a way in which I can subvert their checks that's generally
considered an authentication bypass security vulnerability.

It's worth pointing out that liveness checks will be controversial in and
of themselves too. Today, many sites don't do these checks simply because
it costs them a fair amount of money to perform these checks which
naturally filters out who actually utilizes these technologies to a very
select number of use cases who absolutely need them like financial
services. As soon as we make these liveness checks easy to perform (e.g.
make it a web platform API with browser mediated UI) we open the door for
more people to rely on it. The usability of this becomes safer and more
useful in the context of a single interaction, but in the context of a
general day of a user on the web it will likely degrade the experience
because they'll have to perform more liveness checks across more sites now
they're cheap and easy to perform. We have to be very careful about this
capability to limit when and where it's actually getting used otherwise,
this could very easily turn into a user harming technology as Adrian points
out.

In fact, I'd flip this on it's head and say we should instead be setting
restrictions within the wallet in terms of what assurances it needs from
the verifier before it's willing to submit a liveness check in the same way
a browser needs to validate a TLS certificate before they will render a
page within an isolated process, but at least the direction this is
suggesting is moving way more in the right direction and aligning with the
web architecture of keeping each roles separate rather than with
Widevine/WEI style technology which has been controversial each time it's
been proposed.

On Tue, Nov 14, 2023 at 9:47 PM Dave Longley <dlongley@digitalbazaar.com>
wrote:

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