Draft for wallet attestation

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

@@ -1444,15 +1444,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}
 
@@ -2290,6 +2282,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 an interoperable, verifiable statement that provides evidence of authenticity and security properties of a Wallet to the Authorization Server. Wallets may have different architectures, e.g. they may be app-based with a backend service or web Wallets running entirely within the browser. Wallet attestations are independent from the Wallet's architecture, but require a require a backend service from the Wallet Provider. When the Wallet Provider creates the wallet attestation, it needs to verify the authenticity of the client. App attestation, as provided by mobile operating systems, e.g., iOS's DeviceCheck or Android's Play Integrity, allows the Wallet Provider's backend 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.
+
+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