Relation of WTE in EU ARF and key attestations in OpenID4VCI

[szmeti]

We are currently in the process of adopting OpenID4VCI in our national EUDI wallet solution for issuing PIDs. We have reviewed the latest version of the OpenID4VCI spec in relation to key attestations, and we are a bit unsure how the WTE defined in the EU ARF maps to key attestations in OpenID4VCI.

The ARF defines the WTE as the following:

After its installation, a new EUDI Wallet Instance will need to be activated by the Wallet Provider. The EUDI Wallet Provider issues a Wallet Trust Evidence (WTE) to the Wallet Instance.

It describes the capabilities and properties of the Wallet Instance, the User device and the WSCD(s). This allows a PID Provider or an Attestation Provider to verify that the Wallet Instance complies with the Provider's requirements and therefore is fit to receive a PID or an attestation from the Provider.

The above happens during activation. A device key pair is generated along with an attestation certificate so that the Wallet Provider can verify the device's capabilities and can verify that the device can appropriately protect PKI keys.

Then, during PID issuance:

When the Wallet Instance sends a request for a PID or an attestation to a PID Provider or to an Attestation Provider, it includes the WTE in the request.
The WTE contains a WTE public key. During the issuance of a PID or an attestation (see Section 6.6.2.3), a PID Provider or Attestation Provider can use this public key to verify that the Wallet Instance is in possession of the corresponding private key. Moreover, at that time, the Wallet Instance will send another public key to the PID Provider or Attestation Provider. The Provider will include this public key in the issued PID or attestation. By using a concept called public key association, described in [Topic 9], the PID Provider or Attestation Provider can verify that the private key belonging to this public key is protected by the same WSCD as the private key belonging to the WTE public key.

We can see the following issues:

• In the ARF the WTE is a static one-time attestation created during the activation of the device, whereas in the latest OpenID4VCI spec, the ITE/WTE seems to be treated as a key attestation that is specifically created for an individual credential request (for the key that is to be bound to the credential).
• The ARF uses the concept called Proof of Association instead of generating an ITE/WTE for each credential request. The Proof of Assocation shall prove that the PID key and the WTE key are managed by the same hardware, making it unnecessary to provide a fresh ITE/WTE for each credential request.
• If the WTE as defined in the ARF is sent as a key attestation in the credential request, then it seems to be in conflict with the purpose of key attestations as defined in the OpenID4VCI spec. The spec states that "The Credential Issuer SHOULD issue a Credential for each cryptographic public key specified in the attested_keys claim within the key_attestation parameter." In this case the WTE was created during the activation and contains a key that is not related to the Credential that is to be issued, so the Credential Issuer should not issue a Credential for the key within the key_attestation parameter.

What are your views on the above? Are we misinterpreting something? We don't see how the dynamic nature of the ITE/WTE as defined in OpenID4VCI maps to the static nature of the WTE as defined in the ARF.
Do you have any plans to handle Proof of Assocations in the spec?

[paulbastian]

We are currently in the process of adopting OpenID4VCI in our national EUDI wallet solution for issuing PIDs. We have reviewed the latest version of the OpenID4VCI spec in relation to key attestations, and we are a bit unsure how the WTE defined in the EU ARF maps to key attestations in OpenID4VCI.

The ARF defines the WTE as the following:

After its installation, a new EUDI Wallet Instance will need to be activated by the Wallet Provider. The EUDI Wallet Provider issues a Wallet Trust Evidence (WTE) to the Wallet Instance.
It describes the capabilities and properties of the Wallet Instance, the User device and the WSCD(s). This allows a PID Provider or an Attestation Provider to verify that the Wallet Instance complies with the Provider's requirements and therefore is fit to receive a PID or an attestation from the Provider.

The above happens during activation. A device key pair is generated along with an attestation certificate so that the Wallet Provider can verify the device's capabilities and can verify that the device can appropriately protect PKI keys.

Then, during PID issuance:

When the Wallet Instance sends a request for a PID or an attestation to a PID Provider or to an Attestation Provider, it includes the WTE in the request.
The WTE contains a WTE public key. During the issuance of a PID or an attestation (see Section 6.6.2.3), a PID Provider or Attestation Provider can use this public key to verify that the Wallet Instance is in possession of the corresponding private key. Moreover, at that time, the Wallet Instance will send another public key to the PID Provider or Attestation Provider. The Provider will include this public key in the issued PID or attestation. By using a concept called public key association, described in [Topic 9], the PID Provider or Attestation Provider can verify that the private key belonging to this public key is protected by the same WSCD as the private key belonging to the WTE public key.

We can see the following issues:

* In the ARF the WTE is a static one-time attestation created during the activation of the device, whereas in the latest OpenID4VCI spec, the ITE/WTE seems to be treated as a key attestation that is specifically created for an individual credential request (for the key that is to be bound to the credential).

The concept of a single, static WTE is heavily flawed and was criticized by many memberstates. In the following iterations, the ARF authors therefore modified this a little bit (but not yet enough), you can see that Section 6.5.4 Wallet Instance management says "update the WIAs or the WTEs as necessary; see [Topic 9].2", talking in plural. So the fact that the wallet activation issues a single WTE doesn't state that this is the only one being used lateron, otherwise we have a supercookie for all PID/EAA Providers. So I don't see a contradiction here.

* The ARF uses the concept called Proof of Association instead of generating an ITE/WTE for each credential request. The Proof of Assocation shall prove that the PID key and the WTE key are managed by the same hardware, making it unnecessary to provide a fresh ITE/WTE for each credential request.

As before, for unlinkability reasons you need a fresh WTE for every Issuer anyway. As there are no Proof-of-Association methods described yet, we currently rely on putting multiple keys within the key attestation, which is the basic form of a PoA. The current design of the key attestation and other parts of OpenID4VCI are making it possible to add PoA at a later stage.

* If the WTE as defined in the ARF is sent as a key attestation in the credential request, then it seems to be in conflict with the purpose of key attestations as defined in the OpenID4VCI spec. The spec states that "The Credential Issuer SHOULD issue a Credential for each cryptographic public key specified in the attested_keys claim within the key_attestation parameter." In this case the WTE was created during the activation and contains a key that is not related to the Credential that is to be issued, so the Credential Issuer should not issue a Credential for the key within the key_attestation parameter.

As before, I don't see a conflict, as the ARF doesn't strictly say that there is only one WTE.

What are your views on the above? Are we misinterpreting something? We don't see how the dynamic nature of the ITE/WTE as defined in OpenID4VCI maps to the static nature of the WTE as defined in the ARF. Do you have any plans to handle Proof of Assocations in the spec?

There are ideas for how to integrate PoA as a new proof_type in the future, but right now its not ready yet.