Draft for wallet attestation

openid-4-verifiable-credential-issuance-1_0.md

@@ -1413,15 +1413,7 @@ The following mechanisms in concert can be utilized to fulfill those objectives:
 
 **Key attestation** is a mechanism where the device or security element in a device asserts the key management policy to the application creating and using this key. The Android Operating System, for example, provides apps with a certificate including a certificate chain asserting that a particular key is managed, for example, by a hardware security module. The Wallet can provide this data along with the proof of possession in the Credential Request (see (#credential-request) for an example) to allow the Credential Issuer to validate the key management policy. This requires the Credential Issuer to rely on the trust anchor of the certificate chain and the respective key management policy. Another variant of this concept is the use of a Qualified Electronic Signature as defined by the eIDAS regulation [@eIDAS]. This signature will not reveal the properties of the associated private key to the Credential Issuer. However, as one example, due to the regulatory regime of eIDAS, the Credential Issuer can deduce that the signing service manages the private keys according to this regime and fulfills very high security requirements. As another example, FIDO2 allows RPs to obtain an attestation along with the public key from a FIDO authenticator. That implicitly asserts the key management policy, since the assertion is bound to a certain authenticator model and its key management capabilities.
 
-**App Attestation**: Key attestation, however, does not establish trust in the application storing the Credential and producing presentation of that Credential. App attestation, as provided by mobile operating systems, e.g., iOS's DeviceCheck or Android's SafetyNet, allows a server system to ensure it is communicating to a legitimate instance of its genuine app. Those mechanisms can be utilized to validate the internal integrity of the Wallet (as a whole).
-
-**Device Attestation**: Device Attestation attests to the health of the device on which the Wallet is running, as a whole. It helps prevent compromises such as a malicious third-party application tampering with a Wallet that manages keys and Credentials, which cannot be captured only by obtaining app attestation of a Wallet.
-
-**Client Authentication** allows a Wallet to authenticate with a Credential Issuer. To securely authenticate, the Wallet needs to utilize a backend component managing the key material and processing the secure communication with the Credential Issuer. The Credential Issuer MAY establish trust with the Wallet based on its own auditing or a trusted third-party attestation of the conformance of the Wallet to a certain policy.
-
-Directly using key, app, and/or device attestations to prove certain capabilities to a Credential Issuer is an obvious option. However, this at least requires platform mechanisms that issue signed assertions that third parties can evaluate, which is not always the case (e.g., iOS's DeviceCheck). Also, such an approach creates dependencies on platform specific mechanisms, trust anchors, and platform specific identifiers (e.g., Android `apkPackageName`) and it reveals information about the internal design of a Wallet. Implementers should take these consequences into account.
-
-The approach recommended by this specification is that the Credential Issuer relies on the OAuth 2.0 Client Authentication to establish trust in the Wallet and leaves it to the Wallet to ensure its internal integrity using app and key attestation (if required). This establishes a clean separation between the different components and a uniform interface irrespective of the Wallet's architecture (e.g., native vs. Web Wallet). Client Authentication can be performed with assertions registered with the Credential Issuer or with assertions issued to the Wallet by a third party the Credential Issuer trusts for the purpose of Client Authentication.
+**Wallet attestation** is a mechanism where the Wallet Provider asserts the client's software and device authenticity and genuinity. The Wallet can provide this data in the Pushed Authorization Request or Token Request to allow the Authorization Server to validate the Wallet's authenticity. Directly using key, app, and/or device attestations to prove certain capabilities to an Authorization Server is an possibility although existing platform attestations are partly intended for first party interactions, i.e. the Wallet Provider's backend service and create direct dependencies to these services. The approach recommended by this specification is that the Credential Issuer relies on the OAuth 2.0 Client Authentication to establish trust in the Wallet and leaves it to the Wallet to ensure its internal integrity using app and key attestation (if required). This establishes a clean separation between the different components and a uniform interface irrespective of the Wallet's architecture (e.g., native vs. Web Wallet). Therefore, this specification introduces a common format utlizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth] that may be used by Credential Issuers for improved interoperability, see [](#walletattestation). Beside this, other OAuth client authentication methods may be used, e.g. private-key JWT.
 
 ## Credential Offer {#credential-offer-security}
 
@@ -2257,6 +2249,53 @@ The following is a non-normative example of a Credential Response containing a C
 
 <{{examples/credential_response_sd_jwt_vc.txt}}
 
+# Wallet Attestations {#walletattestation}
+
+The Wallet Attestation defined by this specification is a verifiable statement that confirms the authenticity and security properties of a Wallet to the Authorization Server. Wallets can have different architectures, such as app-based with a backend service or web-based running entirely in a browser. Wallet attestations are architecture-independent and require a backend service from the Wallet Provider. When creating a Wallet attestation, the Wallet Provider MUST verify the Client's authenticity. App attestations provided by operating systems, like iOS's DeviceCheck or Android's Play Integrity, enable the Wallet Provider's backend to confirm communication with a legitimate instance. These mechanisms help validate the Wallet's internal integrity.
+
+A Wallet MAY provide wallet attestations to inform the Authorization Server about the authenticity of the client and its `client_id`. Authorization Server may want to evaluate these wallet attestations to determine whether they communciate to a Wallet that meets its security, compliance or governance requirements, based on the trust framework in use, regulatory requirements, laws, or internal design decisions. A Credential Issuer SHOULD communicate this requirement to evaluate wallet attestations through its metadata using `token_endpoint_auth_method` or using some sort of out-of-band mechanism.
+
+Since wallet attestations may be used for different Authorization Server from different trust frameworks and varying in their requirements, it is necessary to use a common approach to facilitate interoperability. Therefore, wallet attestations SHOULD use a common format, allowing Credential Issuers to develop consistent evaluation processes, reducing complexity and potential errors. Common formats make it easy for Credential Issuers to demonstrate compliance with regulatory requirements across different jurisdictions and facilitate the development of shared best practices and security benchmarks.
+
+There are two ways to convey wallet attestations during Credential issuance using the header-based syntax of Attestation-Based Client Authentication:
+- The Wallet sends it in the Pushed Authorization Request
+- The Wallet sends it in the Token Request
+
+The Wallet Attestation format follows Section 5.1 "Client Attestation JWT" of Attestation-Based Client Authentication. The client_id in the `sub` claim is expected to be the same for every Wallet instance of a Wallet Provider. The Wallet Attestation additionally includes the following JWT Claims:
+
+* `wallet_name`: REQUIRED. A String containing a human-readable name of the Wallet.
+* `wallet_link`: REQUIRED. A String containing a URL to get further information about the Wallet and the Wallet Provider.
+
+The following is a non-normative example of a Wallet Attestation:
+
+```
+{
+  "typ": "oauth-client-attestation+jwt"
+  "alg": "ES256",
+  "kid": "11"
+}
+.
+{
+  "iss": "https://client.example.com",
+  "sub": "https://client.example.com",
+  "wallet_name": "Wallet Solution X by Wonderland State Department",
+  "wallet_link": "https://example.com/wallet/detail_info.html",
+  "nbf":1300815780,
+  "exp":1300819380,
+  "cnf": {
+    "jwk": {
+      "kty": "EC",
+      "use": "sig",
+      "crv": "P-256",
+      "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
+      "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
+    }
+  }
+}
+```
+
+To use the Wallet Attestation towards the Authorization Server, the Wallet MUST generate a proof of possession according to Section 5.2 "Client Attestation PoP JWT" of Attestation-Based Client Authentication.
+
 # IANA Considerations
 
 ## OAuth URI Registry
@@ -2455,6 +2494,7 @@ The technology described in this specification was made available from contribut
 
    -15
 
+   * add section on wallet attestations
    * remove `claims` parameter from ISO mdoc and SD-JWT VC Credential Request
    * credential response always returns an array when not returning a transaction_id with the option for additional meta-data
    * deferred credential response always returns an array (same as credential response)