Issuer Trust Evidence / key attestations for OpenID4VCI

[paulbastian]

In the context of eIDAS 2, we require a Wallet/Issuer Trust Evidence, basically a key attestation made by the Wallet Provider ensuring that keys used for keybinding really reside in a trustworthy key store (called WSCD in eIDAS). In earlier iterations the construct that has so far been called "Wallet Attestation", consisted of two statements:

• The app/wallet instance is authentic/valid (through app attestation)
• The key is really is authentic/valid (through key attestation)

After disussions at EIC 2024, we propose to split this up and match with current eIDAS directions, i.e. have two attestations:

• Wallet Instance Attestation (WIA) -> authenticating the Wallet Instance
• Issuer/Wallet Trust Evidence (ITE/WTE) -> authenticating the WSCD

The WIA could be tested with Attestation-Based Client Authentication at the PAR or Token Endpoint. What's remaining then is to convey and integrate the ITE/WTE concept to OpenID4VCI.

The proposal is to send the ITE/WTE at the Credential Endpoint, because this is where the keys are transmitted. The easiest and least breaking possibility is to create a new proof type, this could potentially also address other issues like #305 which increase the scalability of batch issuance.

The diagram gives a rough idea:

Diagram

A new proof type could like this:

POST /credential HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: DPoP czZCaGRSa3F0MzpnWDFmQmF0M2JW

{
  "credential_identifier": "CivilEngineeringDegree-2023",
  "proofs": {
    "ite": {
      "attestation" : "<base64encoded JWT signed by wallet provider>",
      "proof" : "<JWT proof for cnf key inside the attestation>"
    }
  }
}

{
  "typ": "ite+jwt",
  "alg": "ES256",
  "x5c":  <trust chain of the wallet provider>
}
.
{
  "iss": "<client_id of Wallet Provider>",
  "iat": 1516247022,
  "exp": 1541493724,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    },
    "key_type": "strong_box",
    "user_authentication": "system_pin",
  },
  "device_keys" : [ //optional
      "eyJ0eXAiOiJvcGVuaWQ0dmNpL...Lb9zioZoipdP-jvh1WlA",
      "eyJraWQiOiJkaWQ6ZXhhbXBsZ...KPxgihac0aW9EkL1nOzM"
    ].
  "status" : { //optional
    "status_list" : {
      "uri" : "<uri>",
      "idx" : <index>
    }
  }
}

The ITE may include device_keys public key array that the Credential Issuer could trust directly without additional PoPs. The ITE may also include status information to communicate possible WSCD compromise.

Lets start the discussion :)