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

So, to be clear, are we saying that the wallet can always be compiled from
source?

On Wed, Nov 15, 2023 at 11:30 AM Daniel Hardman <daniel.hardman@gmail.com>
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>
> wrote:
>
>> On Wed, Nov 15, 2023 at 4:33 AM David Chadwick
>> <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/
>>
>>