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

Out of curiosity, how are people looking to support “Capability detection”
while still keeping the wallets and web platform open? By the common
definition of web openness, it usually means I have the capability to
modify and fully control my device and the browser client I run. Making a
tradeoff that limits the web openness will likely face the same issues that
WEI ran into for providing client integrity attestation to a web page.

I’m not sure if people on this list followed that debate, but let’s just
say it had no chance of making it to a WG or forming consensus. Is the VC
wallet ecosystem planning to propose a different solution that addresses
this pattern without the pitfalls[1] or are they planning to never deploy
this capability via the web platform?

 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. As pointed out via the WEI debate they’re the
only ones who guarantee the device attestation isn’t tampered with which
would centralize and close the wallet ecosystem. Similarly are we going to
require users to run one of these OS in order to expose this information
via a browser platform API as well and close the openness of the web? I
don’t see that going much differently than how the WEI debate went if so.
In fact, I find it hard to believe that any web platform API could ship
with this capability after seeing how quickly people brought their
pitchforks out for WEI.

Additionally, looking at other prior art the closest we came to this was
webauthn being capable of requiring device attestations for the
authenticator. However, even today most passkey developers recommend as a
best practice not to do this because it limits deployment capabilities out
of the gate. Looking at this paper [2] it’s typically well understood that
an auth/authz system that lacks in deployment capabilities will hurt the
adoption of said system.

So, with these concerns about the affects on web openness and deployment
limitations, it’s surprising to see that capability detection is still
being discussed given most similar systems discovered the squeezing isn’t
worth the juice. Am I missing something here?

-Kyle

1:
https://github.com/RupertBenWiser/Web-Environment-Integrity/issues
2:
https://ieeexplore.ieee.org/document/6234436

On Mon, Nov 13, 2023 at 11:34 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/
>
>