Verifier/Relying Parties need to be able to verify authenticity and validity of (European Digital Identity) Wallets

[tlodderstedt]

The eIDAS regulation has the following text: Article 5a, 5., (a), viii 'European Digital Identity Wallets shall, in particular (…) support common protocols and interfaces (…) for relying parties to verify the authenticity and validity of European Digital Identity Wallets;'

We need to come up with means to allow wallets to comply with this requirement.

I assume EUDI Wallets will have a credential, referred to with different terms such as "Wallet Instance Attestation" or "Wallet Attestation" or "Wallet Trust Anchor", which it could present to the Verifier along with a Proof of Possession (PoP) of the respective key in the credential. I will use the term Wallet Attestation in this text. The Wallet Attestation is issued by a trusted party, which can assert the authenticity and validity of the wallet. I also assume the Verifier explicitly requests the authenticity/validity check.

I see the following options to build support into the protocol:

1. The Wallet sends a Wallet Attestation with a PoP in the POST request to the request URI of the Verifier. That's the earliest point where the authentication can happen. It would require an extension to the POST request. The Verifier could indicates in the authorization request that it requires Wallet authentication along with a fresh nonce the PoP must incorporate. It would also be possible the Verifier responds with a 401 in the POST request (providng a nonce) and the Wallet needs to send the request again, this time with the Wallet Attestation and PoP. The syntax could leverage syntax as defined in the "attestation based client authentication" draft.
2. The Verifier requests the Wallet Attestation like any other Attestation in the Request. The Wallet Attestation is provided in the vp_token. This option would not require any change to the spec.
3. The Verifier requests the Wallet Attestation with a special parameter in the request, the Wallet Attestation's PoP key is used to sign the Response. The Wallet Attestation is provided in a JOSE header of the JARM response structure.

[paulbastian]

Public key attestations are already widely used today and there's a good support for them in JWT/JWS. (x5c header parameter)

This is not about key attestation, but wallet attestation

[alenhorvat]

It's the same :) (key attestation is issued only to a wallet that meets all the requirements/checks; name is different, data model in both cases contains a public key + additional information about the security policies)

[paulbastian]

It's the same :) (key attestation is issued only to a wallet that meets all the requirements/checks; name is different, data model in both cases contains a public key + additional information about the security policies)

In OpenID we differentiate those, see latest discussions in OpenID4VCI.

[martijnharing]

I'm still strongly in favor of option 2.

Most importantly because otherwise we would be re-inventing the wheel. We already have a protocol that allows to request and send credentials with data elements that can be linked to a key to authenticate with during presentment of those credentials.

Making a special format for the response means that compared to treating the wallet attestation credential as a regular credential, we risk encountering a situation where the credential format the wallet intends to use for the credential itself doesn’t align with the format of the wallet’s attestation. We would need to decide what credential format is it based on, SD-JWT VC, mdoc, JWT, Anoncred etc. If the credential format that we choose does not match the one it is being used with, the wallet application, the underlying secure hardware, the issuance protocol, the issuer hardware, the verifier logic etc. There are also privacy considerations for credential presentment related to tracking which different solutions are being used / proposed for (single-use credentials, limited-use credentials, ZKP approaches etc) by mandating a credential format for wallet attestation this could mean that we are also preventing or limiting support for these kind of solutions.

Making a special parameter for the request means that we still need to integrate that with the DCQL, since you want to be able te say things like. "For credential a I need a wallet attestation, for credential b I do not." A special request parameter means that we either need to define a way to request multiple different request formats (which is something we have solved as part of the DCQL) or we would only support a single format (which has issues as described in the previous paragraph).

Finally, it would mean that we need to normatively define what a "wallet attestation" is, what it attests to and what it doesn't attest to. As part of presentment of a credential, a lot of software and hardware components are involved. What exactly is and isn't part of the wallet attestation will likely not be the same for all implementations/ecosystems etc and the 'normal' credential may also contain some attestation information that could also be handled by a wallet attestation credential.

[David-Chadwick]

Treating a wallet attestation the same as every other credential is my favoured approach. It makes requesting and delivering the credential straight forward and does not require any changes to our protocols. Also I do not have a problem with this wallet attestation credential being displayed to the user like other credentials. It shows the user that they have a gold star approved wallet. It is quite common in real life to buy electrical appliances that have an electric safety approval certificate. So I think users will be quite happy to see that their wallet has an "EC approved wallet" credential.

[c2bo]

My thoughts on the wallet attestation and how to request/present it:

• We need to separate request / response - these are separate problems and I think in the discussion, we successfully started to distinguish between these
• We should also separate UI and the processing aspects:
  • There is the issue of UI/UX: We need to deal with this a bit differently from a "normal" request -> we need consent, but a different kind of displays than you would present for a credential
  • How to present and verify the attestation: This is where things should be very similar to "normal" credential requests -> we need to create a PoP over a nonce etc.

The UI/UX aspects point towards not re-using DCQL/vp_token, whereas the processing (by wallet & RP) would/could benefit from re-using those to prevent somewhat redundant implementations.

Those thoughts brought me to liking the option that was brought up in the discussion on Tuesday quite a bit more:

• Use DCQL and vp_token to convey request / response
• Have a special request parameter that signals that a specific credential request is a wallet attestation identified via id within the credentials array in DCQL
• Additionally, we would define a proposed/default wallet attestation data set & format in VCI (current PR) and reference this as the default option for the wallet attestation towards a RP.

[David-Chadwick]

Yesterday I had discussions with Nishant Anand who is doing a PhD at UCL on Interdisciplinary aspects on digital identity systems governance. In particular we discussed how trust can be increased, because he has already determined that trust is eroded through the “black boxed” nature of governing eID systems. The proposal to display to users the wallet attestation as a mark of conformance to EC standards, should help to increase users trust in the overall system and in the downloaded wallet app in particular. I believe this approach strengthens the case for treating the wallet attestation in a very similar way to normal credentials, and certainly would be against hiding this credential from the user.

For those who would like to know more about this research, or who would like to participate through a one hour expert interview with Nishant, you can contact him at nishant.anand.19@ucl.ac.uk