Skip to content

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

@tlodderstedt

Description

@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.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions