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

 <mailto:d.w.chadwick@truetrust.co.uk> @David Chadwick, thanks for re-focusing my perspective. My mindset has been (primarily) thinking in terms of the verifier having the greatest exposure in a trust transaction since the verifier is ultimately the party that needs to respond to the information they receive. The perspective you seem to be putting forward has more (I think) to do with a potentially coercive dynamic in which the holder may be prodded/forced into providing information to a verifier who may be asking for it without proper need or authority. I believe these are both legitimate potential-core scenarios and it is good for me to keep these distinctions in mind.

 

From: David Chadwick <d.w.chadwick@truetrust.co.uk> 
Sent: Wednesday, November 15, 2023 8:50 AM
To: public-credentials@w3.org
Subject: Re: How much is it reasonable to generalize from the TruAge implementation?

 

Daniel

we are addressing this issue in the OpenID DCP WG. The proposed advanced flow allows the wallet to determine if the verifier is trustworthy before sending any data to the verifier.

Kind regards

David

On 15/11/2023 16:28, Daniel Hardman wrote:

Every assertion that a verifier needs to know something about the nature of a holder's software implies a corresponding need that a holder has to know something about a verifier's stack. Why should a holder have to prove something sensitive or high-stakes to a remote party who claims (typically with evidence far weaker than a VP) to be verifier X, without any confidence in the capabilities of the verifier's stack or indeed the verifier's identity? 

 

I agree with many concerns articulated previously on the thread and just want to add this additional one: if assertion of need for trust are one directional (we only standardize how verifier qualifies prover stack), we will create or worsen "big desks, little people" power imbalance problems and undermine the ethos of SSI.

 

On Wed, Nov 15, 2023, 4:42 PM Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> > wrote:

On Wed, Nov 15, 2023 at 4:33 AM David Chadwick
<d.w.chadwick@truetrust.co.uk <mailto:d.w.chadwick@truetrust.co.uk> > wrote:
> Since trust is personal, trust in wallets (and browsers) is also personal. So I guess that market forces and social networks will determine which wallets (and browsers) users should trust.

In an attempt to be even more controversial than David (I can try, David!)... :P

Yes, exactly this, and the sooner some misguided issuers, wallet
providers, and verifiers understand this, the sooner we can move past
some of the security theater that's being proposed as "high security
wallet" features that "need to be certified".

Kyle's commentary is also quite important to pay attention to. This
discussion over certifications has been had at the W3C over the past
several decades. Certain vendors are asserting that adding these "high
security features" for digital wallets actually result in a more
secure ecosystem w/o proving that is so; where are the attack and
mitigation models? It's largely marketing at this point in time.

In a number of cases, these "high security wallet features" can be
bypassed with a simple proxy application that sits between the digital
wallet and the verifier. People are presuming that security comes from
the digital wallet in some cases where it makes no sense for that to
be the case -- "certified wallets" doing local biometric/PIN checks
being one of those cases. HSM-protected keys being another.

To put it another way -- how many of us are using "certified browsers"
or "certified apps" when we:

* Upload a photo of our driver's licenses to perform eKYC processes?
* Upload a photo of our passport to book an international flight?
* Access our bank account?
* Perform an e-signature on a contract?
* Use WebAuthn or Passkeys to log in?

I expect a very large percentage of us use whatever browser we'd
prefer to use, and the reason we can do that is because of 1) browser
feature/capability detection that websites use, and 2) the Verifier
has a trustless relationship with the browser.

The world works just fine without requiring browser certifications
today, so why do we think we need digital wallet certifications (which
are just another class of user agent)?

-- manu

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