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

On Mon, Nov 13, 2023 at 2:06 PM Adrian Gropper <> 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"):

> 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

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

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 -
Founder/CEO - Digital Bazaar, Inc.

Received on Monday, 13 November 2023 20:32:09 UTC