From 3fb4666532d57628fad62fa0e4d3d1fe186d2cf7 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 28 Oct 2024 16:19:13 +0100 Subject: [PATCH 01/19] initial draft for wallet attestation --- ...id-4-verifiable-credential-issuance-1_0.md | 26 ++++++++++++------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 5c4f9762..e9733ef4 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/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,22 @@ The following is a non-normative example of a Credential Response containing a C <{{examples/credential_response_sd_jwt_vc.txt}} +# Wallet Attestations {#walletattestation} + +A 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 + +## Wallet Attestation in JWT format {#walletattestation-jwt} + +tbd + # IANA Considerations ## OAuth URI Registry From 526a16c49a416b9915a265ba52c1a9aeffc6cc29 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 28 Oct 2024 19:20:10 +0100 Subject: [PATCH 02/19] Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Giuseppe De Marco --- openid-4-verifiable-credential-issuance-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index e9733ef4..433a3acc 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2284,7 +2284,7 @@ The following is a non-normative example of a Credential Response containing a C # Wallet Attestations {#walletattestation} -A 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. +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. From 194b16e03d68453f47bd028bce55d6df91d36016 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Wed, 6 Nov 2024 18:07:04 +0100 Subject: [PATCH 03/19] examples for wallet attestation --- ...id-4-verifiable-credential-issuance-1_0.md | 35 +++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 433a3acc..f868f53c 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2294,9 +2294,40 @@ There are two ways to convey wallet attestations during Credential issuance usin - The Wallet sends it in the Pushed Authorization Request - The Wallet sends it in the Token Request -## Wallet Attestation in JWT format {#walletattestation-jwt} +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: -tbd +* `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 From 7820bca67154b3f9b931f0556a439a1d93de2031 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 12 Nov 2024 21:02:22 +0100 Subject: [PATCH 04/19] Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Giuseppe De Marco --- openid-4-verifiable-credential-issuance-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index f868f53c..98601931 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2284,7 +2284,7 @@ The following is a non-normative example of a Credential Response containing a C # 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. +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. From acccaef98c5806cace6700f72b663a586892ca01 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 12 Nov 2024 21:05:02 +0100 Subject: [PATCH 05/19] add history --- openid-4-verifiable-credential-issuance-1_0.md | 1 + 1 file changed, 1 insertion(+) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 98601931..bbaa1561 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2527,6 +2527,7 @@ The technology described in this specification was made available from contribut -15 + * add section on wallet attestations * 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) * notification_id is now used for an issuance flow that can contain more than one credential From a3c93d28e802c40d57efd92a767eae45e2db55d5 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Wed, 13 Nov 2024 08:19:41 +0100 Subject: [PATCH 06/19] Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- openid-4-verifiable-credential-issuance-1_0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 7b947278..ba143eca 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2263,8 +2263,8 @@ There are two ways to convey wallet attestations during Credential issuance usin 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. +* `wallet_name`: REQUIRED. String containing a human-readable name of the Wallet. +* `wallet_link`: REQUIRED. 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: From 63daa67cd87861dc670bfbd3daf35e7096c63bbd Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 14 Nov 2024 14:37:40 +0100 Subject: [PATCH 07/19] Apply suggestions from Giuseppe Co-authored-by: Giuseppe De Marco --- openid-4-verifiable-credential-issuance-1_0.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index ba143eca..8e5f829a 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2251,17 +2251,17 @@ The following is a non-normative example of a Credential Response containing a C # 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. +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. Mobile application 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. +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 communicate 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. +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: +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: +The Wallet Attestation format follows Section 5.1 "Client Attestation JWT" of Attestation-Based Client Authentication. The Wallet Attestation additionally includes the following JWT Claims: * `wallet_name`: REQUIRED. String containing a human-readable name of the Wallet. * `wallet_link`: REQUIRED. String containing a URL to get further information about the Wallet and the Wallet Provider. @@ -2494,7 +2494,7 @@ The technology described in this specification was made available from contribut -15 - * add section on wallet attestations + * 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) From 85cbd14df3bbc331c9df201c5730f2652872c7d4 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 3 Dec 2024 20:54:24 +0100 Subject: [PATCH 08/19] some minor changes on Torsten's review --- openid-4-verifiable-credential-issuance-1_0.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 8e5f829a..d21128b1 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -1413,7 +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. -**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. +**Wallet attestation** is a mechanism where the Wallet Provider asserts the client's 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} @@ -2251,7 +2251,9 @@ The following is a non-normative example of a Credential Response containing a C # 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. Mobile application 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. +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. + +Some Wallet architectures require a backend service from the Wallet Provider that verifies the Client's authenticity before providing Wallet Attestations. Mobile application 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 communicate 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. From 3acc0e8bdebd88531d40fd027fab6379b4b45a47 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 3 Dec 2024 20:58:19 +0100 Subject: [PATCH 09/19] Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- openid-4-verifiable-credential-issuance-1_0.md | 1 + 1 file changed, 1 insertion(+) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index d21128b1..3a8480dc 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2267,6 +2267,7 @@ The Wallet Attestation format follows Section 5.1 "Client Attestation JWT" of At * `wallet_name`: REQUIRED. String containing a human-readable name of the Wallet. * `wallet_link`: REQUIRED. String containing a URL to get further information about the Wallet and the Wallet Provider. +* `status`: OPTIONAL. Object compliant to IETF Status List draft. The following is a non-normative example of a Wallet Attestation: From fc78c4ae60a10257e65ee5929e73e42d32c2e19f Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 5 Dec 2024 15:55:16 +0100 Subject: [PATCH 10/19] Apply suggestions from code review Co-authored-by: Torsten Lodderstedt --- openid-4-verifiable-credential-issuance-1_0.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 3a8480dc..c807b239 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2249,7 +2249,7 @@ The following is a non-normative example of a Credential Response containing a C <{{examples/credential_response_sd_jwt_vc.txt}} -# Wallet Attestations {#walletattestation} +# Wallet Attestations in JWT format {#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. @@ -2257,17 +2257,17 @@ Some Wallet architectures require a backend service from the Wallet Provider tha 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 communicate 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. +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, this section proposes 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: +There are two ways to convey Wallet Attestations during Credential issuance using the header-based syntax of [@!I-D.ietf-oauth-attestation-based-client-auth]: - 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 Wallet Attestation additionally includes the following JWT Claims: +The Wallet Attestation format follows Section 5.1 "Client Attestation JWT" of [@!I-D.ietf-oauth-attestation-based-client-auth]. The Wallet Attestation additionally includes the following JWT Claims: * `wallet_name`: REQUIRED. String containing a human-readable name of the Wallet. * `wallet_link`: REQUIRED. String containing a URL to get further information about the Wallet and the Wallet Provider. -* `status`: OPTIONAL. Object compliant to IETF Status List draft. +* `status`: OPTIONAL. Status mechanism for the Wallet Attestation as defined in [@!I-D.ietf-oauth-token-status-list] The following is a non-normative example of a Wallet Attestation: From 693197f28d5deb3810538a9dfc90e2bade14847b Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 6 Dec 2024 15:53:12 +0100 Subject: [PATCH 11/19] Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Torsten Lodderstedt --- openid-4-verifiable-credential-issuance-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index c807b239..f78869a7 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2251,7 +2251,7 @@ The following is a non-normative example of a Credential Response containing a C # Wallet Attestations in JWT format {#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. +The Wallet Attestation defined in this section is a verifiable statement in JWT format that is used to authenticate the Wallet with the Authorization Server of the Credential Issuer. The Wallet Attestation MUST be signed by an issuer that the Authorization Server of the Credential Issuer trusts for this purpose. Some Wallet architectures require a backend service from the Wallet Provider that verifies the Client's authenticity before providing Wallet Attestations. Mobile application 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. From 699b7b60e6e046fb987ac434ef3acd14616b5a48 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 6 Dec 2024 16:26:37 +0100 Subject: [PATCH 12/19] Apply suggestions from code review --- openid-4-verifiable-credential-issuance-1_0.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index f78869a7..bd21c744 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -1413,7 +1413,9 @@ 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. -**Wallet attestation** is a mechanism where the Wallet Provider asserts the client's 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. +**Client Authentication** allows a Wallet to authenticate with the Authorization Server of the Credential Issuer. Authorization Server may want to authenticate Wallets to determine whether they communicate 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. Any token endpoint authentication method as registered in the [OAuth Token Endpoint Authentication Methods IANA Registry](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method) may be used with the Pushed Authorization or Token Request. An Authorization Server SHOULD communicate its client authentication requirement through its `token_endpoint_auth_method` metadata parameter. + +**Wallet attestation** is a client authentication mechanism where the Wallet Provider asserts the client's authenticity and genuinity utlizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth], for details see (reference) ## Credential Offer {#credential-offer-security} @@ -2251,7 +2253,7 @@ The following is a non-normative example of a Credential Response containing a C # Wallet Attestations in JWT format {#walletattestation} -The Wallet Attestation defined in this section is a verifiable statement in JWT format that is used to authenticate the Wallet with the Authorization Server of the Credential Issuer. The Wallet Attestation MUST be signed by an issuer that the Authorization Server of the Credential Issuer trusts for this purpose. +The Wallet Attestation defined in this section is a client authentication method especially designed for native App Wallets. Instead of using platform-specific key, app, and/or device attestations directly, it uses a key-bound, platform agnostic common format based on JWTs. This allows Authorization Servers to authenticate Wallets across different platforms in a unified fashion and exposes only a minimum dataset. Also, it allows the Wallet app to directly interact with the Credential Issuer without involving the Wallet Provider's backend. The Wallet Attestation MUST be signed by an issuer that the Authorization Server of the Credential Issuer trusts for this purpose. Some Wallet architectures require a backend service from the Wallet Provider that verifies the Client's authenticity before providing Wallet Attestations. Mobile application 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. From d3858e0fe2d199dabe11461474811f13654a4cbd Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 6 Dec 2024 16:29:52 +0100 Subject: [PATCH 13/19] Apply suggestions from code review --- openid-4-verifiable-credential-issuance-1_0.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index bd21c744..2f5b94e6 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2261,14 +2261,14 @@ A Wallet MAY provide Wallet Attestations to inform the Authorization Server abou 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, this section proposes 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 [@!I-D.ietf-oauth-attestation-based-client-auth]: +There are two requests where Wallets may need to authenticate during Credential issuance: - 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 [@!I-D.ietf-oauth-attestation-based-client-auth]. The Wallet Attestation additionally includes the following JWT Claims: -* `wallet_name`: REQUIRED. String containing a human-readable name of the Wallet. -* `wallet_link`: REQUIRED. String containing a URL to get further information about the Wallet and the Wallet Provider. +* `wallet_name`: OPTIONAL. String containing a human-readable name of the Wallet. +* `wallet_link`: OPTIONAL. String containing a URL to get further information about the Wallet and the Wallet Provider. * `status`: OPTIONAL. Status mechanism for the Wallet Attestation as defined in [@!I-D.ietf-oauth-token-status-list] The following is a non-normative example of a Wallet Attestation: From e1391a9f41e9eb245355b926e3680a276deeb64b Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 6 Dec 2024 16:36:58 +0100 Subject: [PATCH 14/19] Apply suggestions from code review --- openid-4-verifiable-credential-issuance-1_0.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 2f5b94e6..cd410d7c 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2255,11 +2255,8 @@ The following is a non-normative example of a Credential Response containing a C The Wallet Attestation defined in this section is a client authentication method especially designed for native App Wallets. Instead of using platform-specific key, app, and/or device attestations directly, it uses a key-bound, platform agnostic common format based on JWTs. This allows Authorization Servers to authenticate Wallets across different platforms in a unified fashion and exposes only a minimum dataset. Also, it allows the Wallet app to directly interact with the Credential Issuer without involving the Wallet Provider's backend. The Wallet Attestation MUST be signed by an issuer that the Authorization Server of the Credential Issuer trusts for this purpose. -Some Wallet architectures require a backend service from the Wallet Provider that verifies the Client's authenticity before providing Wallet Attestations. Mobile application 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. +In a typical architecture of a native Wallet App, the Wallet Provider's backend will use attestations provided by the mobile operating system, like iOS's DeviceCheck or Android's Play Integrity, to validate the app's integrity and authenticity before issuing the Wallet Attestation. -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 communicate 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, this section proposes 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 requests where Wallets may need to authenticate during Credential issuance: - The Wallet sends it in the Pushed Authorization Request From e149a8cacb11b715335b60047816ed392c2f3f39 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 6 Dec 2024 16:37:28 +0100 Subject: [PATCH 15/19] Update openid-4-verifiable-credential-issuance-1_0.md --- openid-4-verifiable-credential-issuance-1_0.md | 1 - 1 file changed, 1 deletion(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index cd410d7c..31050384 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2257,7 +2257,6 @@ The Wallet Attestation defined in this section is a client authentication method In a typical architecture of a native Wallet App, the Wallet Provider's backend will use attestations provided by the mobile operating system, like iOS's DeviceCheck or Android's Play Integrity, to validate the app's integrity and authenticity before issuing the Wallet Attestation. - There are two requests where Wallets may need to authenticate during Credential issuance: - The Wallet sends it in the Pushed Authorization Request - The Wallet sends it in the Token Request From e96f24bf7c2026dd7fdad9b72db8b505e65496eb Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 6 Dec 2024 17:00:16 +0100 Subject: [PATCH 16/19] Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- openid-4-verifiable-credential-issuance-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 31050384..1bb28738 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -1413,7 +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. -**Client Authentication** allows a Wallet to authenticate with the Authorization Server of the Credential Issuer. Authorization Server may want to authenticate Wallets to determine whether they communicate 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. Any token endpoint authentication method as registered in the [OAuth Token Endpoint Authentication Methods IANA Registry](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method) may be used with the Pushed Authorization or Token Request. An Authorization Server SHOULD communicate its client authentication requirement through its `token_endpoint_auth_method` metadata parameter. +**Client Authentication** allows a Wallet to authenticate with the Authorization Server of the Credential Issuer. The Authorization Server may want to authenticate Wallets to determine whether they communicate 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. Any token endpoint authentication method as registered in the [OAuth Token Endpoint Authentication Methods IANA Registry](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method) may be used with the Pushed Authorization or Token Request. An Authorization Server SHOULD communicate its client authentication requirement through its `token_endpoint_auth_method` metadata parameter. **Wallet attestation** is a client authentication mechanism where the Wallet Provider asserts the client's authenticity and genuinity utlizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth], for details see (reference) From c33c2678157e44ce44444ee810d19ca3ea9c0a2a Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 6 Dec 2024 17:00:51 +0100 Subject: [PATCH 17/19] Update openid-4-verifiable-credential-issuance-1_0.md --- openid-4-verifiable-credential-issuance-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 1bb28738..fcf37d01 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -1415,7 +1415,7 @@ The following mechanisms in concert can be utilized to fulfill those objectives: **Client Authentication** allows a Wallet to authenticate with the Authorization Server of the Credential Issuer. The Authorization Server may want to authenticate Wallets to determine whether they communicate 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. Any token endpoint authentication method as registered in the [OAuth Token Endpoint Authentication Methods IANA Registry](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method) may be used with the Pushed Authorization or Token Request. An Authorization Server SHOULD communicate its client authentication requirement through its `token_endpoint_auth_method` metadata parameter. -**Wallet attestation** is a client authentication mechanism where the Wallet Provider asserts the client's authenticity and genuinity utlizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth], for details see (reference) +**Wallet attestation** is a client authentication mechanism where the Wallet Provider asserts the client's authenticity and genuinity utlizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth], for details see (#walletattestation). ## Credential Offer {#credential-offer-security} From 9b1eb852edf952467eefaeac9b11d1d245c07aee Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 6 Dec 2024 17:01:01 +0100 Subject: [PATCH 18/19] Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- openid-4-verifiable-credential-issuance-1_0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index fcf37d01..e3c07395 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2281,8 +2281,8 @@ The following is a non-normative example of a Wallet Attestation: "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, + "nbf": 1300815780, + "exp": 1300819380, "cnf": { "jwk": { "kty": "EC", From e7f71050536979914d0a0f5525196d5c82e89102 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Sun, 8 Dec 2024 19:29:29 +0100 Subject: [PATCH 19/19] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- openid-4-verifiable-credential-issuance-1_0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index e3c07395..ca550775 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -1413,9 +1413,9 @@ 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. -**Client Authentication** allows a Wallet to authenticate with the Authorization Server of the Credential Issuer. The Authorization Server may want to authenticate Wallets to determine whether they communicate 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. Any token endpoint authentication method as registered in the [OAuth Token Endpoint Authentication Methods IANA Registry](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method) may be used with the Pushed Authorization or Token Request. An Authorization Server SHOULD communicate its client authentication requirement through its `token_endpoint_auth_method` metadata parameter. +**Client Authentication** enables a Wallet to authenticate with the Credential Issuer's Authorization Server. This authentication ensures that the Wallet complies with the Authorization Server's security, compliance, and governance standards, which may be required by trust frameworks, regulatory requirements, laws, or internal policies. Any method listed in the [OAuth Token Endpoint Authentication Methods IANA Registry](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method) can be used for authentication during the Pushed Authorization or Token Request. The Authorization Server SHOULD specify its client authentication requirements using the `token_endpoint_auth_method` metadata parameter. -**Wallet attestation** is a client authentication mechanism where the Wallet Provider asserts the client's authenticity and genuinity utlizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth], for details see (#walletattestation). +**Wallet Attestation** is a signed proof provided by the Wallet Provider, verifying the client's authenticity and genuineness. This process uses the mechanisms outlined in Attestation-Based Client Authentication, described in the Section [Wallet Attestation](#walletattestation). Once obtained, the Wallet Attestation can be used as a client authentication for the Wallet. ## Credential Offer {#credential-offer-security}