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

Manu,

Your list of different capabilities is about as user-hostile as I can
imagine. It makes today's shrink-wrap licenses and multi
page privacy policies look like scripture. We know users will trade privacy
for convenience. When faced with such esoterica, I'm likely to look for a
solution from EFF or maybe Apple to protect my interests.

Please consider working with civil society groups and avoiding euphemisms.

Adrian

On Mon, Nov 13, 2023 at 3:32 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Mon, Nov 13, 2023 at 2:06 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
> > From a human rights perspective, is there any difference between
> Capability Detection and Product/Vendor detection in the context of Holder
> Binding?
>
> Yes, there is a significant difference.
>
> "Capability Detection": This answers questions posed by the Verifier
> of the following form:
>
> "Prove to me that the software you're using can do a specific
> operation or has a specific quality".
>
> For example, "Prove to me that you have the ability to perform a
> digital signature on a challenge". The Verifier provides a challenge,
> the Holder software performs a digital signature on that challenge and
> returns it to the Verifier. At no point did the holder software need
> to identify which digital wallet  vendor created it.
>
> Now, contrast that with:
>
> "Product/Vendor Detection": This answers questions posed by the
> Verifier of the following form:
>
> "Prove to me that you're a Foo Wallet." The Verifier provides the
> challenge and that's counter-signed by Foo Wallet's corporate
> cryptographic key. Once that's done, all of the capabilities for the
> digital wallet can be known because the Verifier has pre-vetted that
> wallet. In other words, "Product/Vendor Detection"'s outcome is a
> bunch of capabilities, but it's all bundled together as an association
> with the Vendor's platform.
>
> > I hope we can stop using euphemisms like Capability Detection when
> talking about people.
>
> "Capability Detection" isn't about the person. It's about what the
> piece of software is capable of doing.
>
> There is a primer on why this matters here (when reading the article,
> every time you read "Browser" replace it with "Product/Vendor"):
>
>
> https://blog.maximerouiller.com/post/Browser-Detection-is-bad-Feature-Detection-is-better/
>
> > Let's start by calling Holder Binding what it is.
>
> The VCWG came to the conclusion that the term "holder binding" was an
> imprecise and confusing term and we should all stop using it :). It
> was replaced with the term "confidence method" -- that is, "As a
> Verifier, what is the method I'm going to use to build confidence that
> the person I'm dealing with is who they say they are?".
>
> When some Verifiers ask for "Holder Binding", what they're hoping for
> is: "Prove to me that the VC you're supplying to me hasn't been cloned
> to a different device and the person that's presenting it is highly
> likely to be the person that received the credential in the first
> place."
>
> This often jams together the following capabilities:
>
> * The private key used is bound to a hardware device and is not
> extractable (private key lives on mobile device Secure Enclave /
> Hardware Security Module).
>
> * The digital wallet software can identify itself and has not been
> compromised (because the platform vendor has verified the application
> software running on the mobile device has not been tampered with).
>
> * The way the private key was unlocked is bound to some sort of PIN or
> biometric on the device that is running the digital wallet software.
>
> * Some sort of biometric match was performed between the individual
> and the digital credential being presented.
>
> * Ability to perform NFC from the device that meets all the
> qualifications above.
>
> You can probably understand why some Verifiers find the above so
> compelling -- it's WAY MORE security than we have today w/ our plastic
> DL's and EMV payment cards. It's also WAY MORE than what's required
> for many transactions that we use those DL's and EMV payment cards for
> today.
>
> In many cases, the platform vendor (or someone that has a relationship
> with the platform vendor) is the only one that can meet all of those
> requirements, so your choice for "Holder Binding" quickly evaporates
> to "only the platform vendor can do this". We're not there yet today,
> but that's been the pitch provided by some platform vendors to date:
> "Only our platform ecosystem can provide the level of security that
> you need!".
>
> Hopefully the above is helpful in differentiating the concepts of
> "capability detection" from "vendor detection" from "holder binding".
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>