Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

Credentials that include a biometric can be self-verifying whether they are
physical or digital without requiring a wallet. In these cases
chain-of-custody is irrelevant and coercion risks are mitigated.

For a (counter) example, the recent announcement by Arizona DMV and Apple
depends on a certified app to grab a video selfie for issue and to
facilitate verification.
https://www.axios.com/arizona-lets-you-put-your-drivers-license-on-your-iphone-c69eca0a-6e2b-4f81-8a5a-0a8ec618227a.html

This certified app that binds the selfie to other verifiable components of
the DMV credential including the biometric in the credential can be
anyone’s. It could be operated by the DMV (in person), it could be on the
phone of the subject’s friend, or it could be on the phone of the subject.
Once the digital credential is signed by DMV, it can be emailed to the
subject or anywhere the subject tells them.

How the subject presents the self-verifying digital biometric DMV
credential in-person or online does not have to be tied to the app used to
create it. The verifier decides if they will verify the credential
in-person using an app they control or if they will allow a certified app
to present the credential, along with a selfie or a signed challenge,
online.

My point is that chain-of-custody and resulting coercion issues can be
mitigated by allowing the subject to move a digital credential among
wallets and certified apps are only needed for interacting with a biometric
as part of the presentation.

The relationship between the certified app(s) and a wallet is, presumably,
that the wallet has a HSM to hold the private key associated with the
subject of the self-verifying digital credential. The HSM is used to sign a
presentation.

To achieve non-repudiation, control of the private key in the HSM should be
linked to a biometric. If the (DID) identifier in the self-verifying
credential is the same or provably related to the private key in the HSM,
then remote presentation of the credential can be non-repudiate. An
impostor or a delegate who happens to hold the credential or a copy of it
would not be able to make a valid presentation.

Coercion is mitigated when the holding of a self-verifying credential does
not have to be linked to a certified app. For its part, the HSM associated
with a wallet does not have to be certified by either the issuer or the
verifier. The choice of how to store credentials and how to sign
presentations are independent of each other.

Correlation is avoided if the HSM can substitute a linked identifier in the
presentation of a self-verifying credential. If the issued credential is
just a signed combination of a biometric and some attributes then
correlation is a risk associated with the attributes of self-verifying
digital credentials and can be managed by on-demand issuance.

Adrian


On Wed, Mar 23, 2022 at 5:02 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> <inline>
> On Wed, Mar 23, 2022 at 1:14 PM John, Anil <anil.john@hq.dhs.gov> wrote:
>
>> > How do we avoid coercion?
>>
>>
>>
>> What is the current approach to avoiding coercion when it comes to the
>> use of physical credentials?
>>
>
> Physical credentials are self-contained and, when they include biometrics
> or the ability to link to a biometric registry,  physical credentials do
> not depend on a chain-of-custody design. Nobody specifies how my driver's
> license should be handled. I can have multiple passports and choose which
> one to show at the border without the potential coercion of a certified
> wallet or wallets.
>
>>
>>
>> > Another issue involves the temptation to use strong credentials for
>> trivial transactions.
>>
>>
>>
>> What is the current approach to avoid the use of strong physical
>> credentials for trivial transactions?
>>
>
> There are good reasons why CDC vaccine cards are weak credentials.
> Apologies, but I've lost track of the reference, but getting more people
> vaccinated is more important than preventing the fraud. For example, at a
> busy concert entry a few months ago, I was asked to show my biometric
> strong physical credential along with my weak CDC vaccine card. I asked the
> bouncer why he picked me. He said they check about one in ten and did not
> describe any profiling.
>
>>
>>
>> The point of my questions to your questions is very simple – I
>> acknowledge that the problem exists, but also that the problem is not
>> specific to digital credentials.
>>
>
> The problem unique to digital credentials comes the ease with which strong
> credentials can be abused in trivial situations where the verifier cannot
> be trusted by the subject to not misuse the credential. The bouncer at the
> bar does not have a chance to save my license info the way a car license
> plate reader can. The license plate reader can also combine all sorts of
> other information such as location and my face without my knowledge or
> consent, store these forever, and sell access. The individual components
> are physical credentials and relatively weak. Their combination and
> digitization is incredibly coercive and difficult to regulate. My lack of
> control is a form of coercion.
>
> But it gets worse. Our work to create standard data models for the digital
> credentials makes the problem orders of magnitude worse.  I call this
> Ambient Surveillance. https://github.com/w3c/did-use-cases/issues/113
>
>>
>>
>> As such, any solutions to both questions will not necessarily have a
>> technical answer.
>>
>
> With all due respect, necessarily, we will only get mitigation of the
> coercive aspects of our work if we document the problems and the technical
> mitigations that we apply. Right now, it is my observation that this issue
> is considered out of scope for CCG and probably by W3C as a whole.
>
> Adrian
>
>>