Wallet Instance Attestation for OpenID4VCI

This issue is about adding the option for authenticating the Wallet/Client for high assurance use cases to enable e.g. regulated use cases.
This is especially useful for issuance of PID in eIDAS 2.0 or more general the Type-1 configuration, but may be used for all kinds of situations, where the Issuer wants or needs to authenticate the wallet and/or requires device-bound keys.

In a short summary the added functionality covers the following aspects:

adding optional metadata for the issuer to communciate his requirements on client authenticaiton with wallet instance attestation
adding guidance for wallet implementers how to do a client instance authentication
a) before interacting with the token request (ad hoc wallet authentication)
b) in advance, e.g. after install of wallet app and regular intervals
and describe the basic ideas or doing a remote wallet attestation with the wallet/client backend or a trusted third party, e.g. with device-bound keys, key attestations and app attestations refering to or extending Chapter 11.1 on Trust between Wallet and Issuer and receive a
define a credential format and schema for wallet instance attestation and list/refer to possible values/a registry
adding the option to Token Request to send the client instance attestation and Proof of possession
add guidance to combine this approach with DPoP

I have presented the concepts at multiple conferences, for more informations on the ideas behind this and first examples with OpenID4VCI check the slidedeck from last IIW~~#36~~ (https://www.linkedin.com/posts/paul-bastian-1970b1195_slides-on-wallet-security-concepts-activity-7056179875635724289-pDXM)) or a Whitepaper for full background (https://nextcloud.idunion.org/s/qPZHPNa8MQJgkDP)..)

As this might be an intresting topic, I opted for raising issue for discussion first, before starting a PR.
For the steps above I propose:

Adding subchapter to chapter 10.2 Credential Issuer Metadata or as Appendix example, like:

{
  ...
  "token_endpoint_auth_methods_supported": [
    "urn:ietf:params:oauth:client-assertion-type:verifiable-presentation"
  ],
  ...
}

Further text may be required by the issuer to signal whether he needs device-bound keys and which user authentication methods he expects.

2. The actual protocol between client and client backend are deliberatly out-of-scope and shall not be standardized, as these probably differ between implementers, architctures and used technologies. The needed text are mostly informative and may refer to https://vcstuff.github.io/draft-looker-oauth-attestation-based-client-authentication/draft-looker-oauth-attestation-based-client-authentication.html#name-introduction

3. This is the actual point of interoperability and a common format/schema shall be used. In https://vcstuff.github.io/draft-looker-oauth-attestation-based-client-authentication/draft-looker-oauth-attestation-based-client-authentication.html#name-introduction we are currently using plain JWT.
Possible alternatives that have already been discussed:

plain JWT
SD-JWT with no disclosures for easy key binding
SD-JWT-VC or other VC formats

Moreover, a schema is required.
A current JWT example body is:

{
  "iss": "<https://attestation-service.ssi.tir.budru.de",>
  //no audience here for privacy reasons
  "sub" : "<https://lissi.org",>
  "iat": 1541493724,
  "exp": 1516247022, //expiration ~30 to 90 days..
  "type": "WalletAttestation",
  "wallet_name": "Lissi Dev",
  "wallet_version": "1.6.0",
  "key_type" : "STRONGBOX",
  "user_auth_mechanism" : "6_DIGIT_PIN
  "supported_LoA" : "<https://eu-trust-list.eu/loa/substantial",>
  "cnf": {
    "jwk" : {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }

with a registry specifically describing possible values for key_type and user_auth_mechanism

5. Refer to work that is created here: https://vcstuff.github.io/draft-looker-oauth-attestation-based-client-authentication/draft-looker-oauth-attestation-based-client-authentication.html

Happy to get feedback of what belongs to OpenID4VCI!

Comments (7)