From 6da765e06de49091a7c02625bc2f06b3579d8a9d Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 6 Sep 2024 18:52:44 +0200 Subject: [PATCH 01/36] first draft for key attestation --- ...id-4-verifiable-credential-issuance-1_0.md | 84 +++++++++++++++++++ 1 file changed, 84 insertions(+) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index ba912c7c..2233dca8 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2166,6 +2166,90 @@ The following is a non-normative example of a Credential Response containing a C <{{examples/credential_response_sd_jwt_vc.txt}} +# Key Attestations {#keyattestation} + +A key attestation is an interoperable mechanism to proof the authenticity and security properties of a key and its storage component. Keys may be stored in various key storage components, that differ regarding the private key's protection against extraction and duplication as well as the user's authentication to unlock key operations. Key storage components may be software-based or hardware-based and may be on the same device as the wallet, external security tokens or remote services that enable cryptographic key operations. + +A Wallet may provide key attestations to inform the Issuer about the properties of the provided keys. Credential Issuers may want to evaluate key attestations to decide whether keys are eligible to its own security requirements, which can results from regulatory requirements and laws or internal design decisions. An Issuer SHOULD communicate his requirements through his metadata or out-of-band. + +todo: motivate interoperability for issuers + +todo: explain usage of this within proof type or DPoP Proof + +## Key Attestation in JWT format + +The JWT is signed by the Wallet Provider or the Wallet's key storage component itself and contains the following elements: + +* in the JOSE header, + * `alg`: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry [@IANA.JOSE.ALGS]. It MUST NOT be `none` or an identifier for a symmetric algorithm (MAC). + * `typ`: REQUIRED. MUST be `openid4vci-keyattestation+jwt`, which explicitly types the key proof JWT as recommended in Section 3.11 of [@!RFC8725]. + +The key attestation may use `x5c`, `kid`, `trust_chain` or other mechanisms to convey the public key and the associated trust mechanism to sign the key attestation. + +* in the JWT body, + * `iat`: REQUIRED (number). Integer for the time at which the key attestation was issued using the syntax defined in [@!RFC7519]. + * `exp`: REQUIRED (number). Integer for the time at which the key attestation expires using the syntax defined in [@!RFC7519]. + * `keys` : REQUIRED. Array of attested keys using the syntax of JWK as defined in [@!RFC7517]. + * `key_type` : OPTIONAL. String that asserts the key storage component and its security mechanism of attested keys from `keys`. This specification defines initial values in (#keyattestation-keytypes). + * `user_authentication` : OPTIONAL. String that asserts the security mechanism the key storage component uses to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). + * `apr` : OPTIONAL. String that asserts the resistance to a certain attack potential as described + * `nonce`: OPTIONAL. String that represents a nonce provided by the Issuer to proof that a key attestation was freshly generated. + +todo: add optional `status` parameter + +The Credential Issuer MUST validate that the JWT used as a proof is actually signed by a key identified in the JOSE Header. + +This is an example of a Wallet Instance Attestation: + +```json +{ + "typ": "openid4vci-keyattestation+jwt", + "alg": "ES256", + "kid": "1" +} +. +{ + "iss": "", + "iat": 1516247022, + "exp": 1541493724, + "key_type": "strong_box", + "user_authentication": "system_pin", + "apr" : "https://trust-list.eu/apr/high", + "keys": [ + { + "kty": "EC", + "crv": "P-256", + "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", + "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" + } + ] +} +``` + +## Key Types {#keyattestation-keytypes} + +This specification defines the following values for `key_type`: + +* `software`: It MUST be used when the Wallet uses software-based key management. +* `hardware`: It MUST be used when the wallet uses hardware-based key management. +* `tee`: It SHOULD be used when the Wallet uses the Trusted Execution Environment for key management. +* `secure_enclave`: It SHOULD be used when the Wallet uses the Secure Enclave for key management. +* `strong_box`: It SHOULD be used when the Wallet uses the Strongbox for key management. +* `secure_element`: It SHOULD be used when the Wallet uses a Secure Element for key management. +* `hsm`: It SHOULD be used when the Wallet uses Hardware Security Module (HSM). + +## User Authentication Types {#keyattestation-auth} + +This specification defines the following values for `user_authentication`: + +* `system_biometry`: It MUST be used when the key usage is authorized by the mobile operating system using a biometric factor. +* `system_pin`: It MUST be used when the key usage is authorized by the mobile operating system using personal identification number (PIN). +* `internal_biometry`: It MUST be used when the key usage is authorized by the Wallet using a biometric factor. +* `internal_pin`: It MUST be used when the key usage is authorized by the Wallet using PIN. +* `secure_element_pin` It MUST be used when the key usage is authorized by the secure element managing the key itself using PIN. + +todo: text about Level of assurance and attack potential resistance + # IANA Considerations ## Sub-Namespace Registration From 876c29cb632ffc7041ca8b45cbc3d57ebb9a9ad4 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 10 Sep 2024 20:37:51 +0200 Subject: [PATCH 02/36] 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 2233dca8..7089716f 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2231,7 +2231,6 @@ This is an example of a Wallet Instance Attestation: This specification defines the following values for `key_type`: * `software`: It MUST be used when the Wallet uses software-based key management. -* `hardware`: It MUST be used when the wallet uses hardware-based key management. * `tee`: It SHOULD be used when the Wallet uses the Trusted Execution Environment for key management. * `secure_enclave`: It SHOULD be used when the Wallet uses the Secure Enclave for key management. * `strong_box`: It SHOULD be used when the Wallet uses the Strongbox for key management. From feced43088fa0b8325268c4bed8b0748405adc71 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 17 Sep 2024 20:27:09 +0200 Subject: [PATCH 03/36] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- openid-4-verifiable-credential-issuance-1_0.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 7089716f..010e900b 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2168,11 +2168,11 @@ The following is a non-normative example of a Credential Response containing a C # Key Attestations {#keyattestation} -A key attestation is an interoperable mechanism to proof the authenticity and security properties of a key and its storage component. Keys may be stored in various key storage components, that differ regarding the private key's protection against extraction and duplication as well as the user's authentication to unlock key operations. Key storage components may be software-based or hardware-based and may be on the same device as the wallet, external security tokens or remote services that enable cryptographic key operations. +A key attestation is an interoperable, verifiable statement that provides evidence of the authenticity and security properties of a key and its storage component. Keys can be stored in various key storage components, which differ in their ability to protect the private key against extraction and duplication, as well as in the methods used for End-User authentication to unlock key operations. These key storage components may be software-based or hardware-based, and can be located on the same device as the Wallet, on external security tokens, or on remote services that enable cryptographic key operations. -A Wallet may provide key attestations to inform the Issuer about the properties of the provided keys. Credential Issuers may want to evaluate key attestations to decide whether keys are eligible to its own security requirements, which can results from regulatory requirements and laws or internal design decisions. An Issuer SHOULD communicate his requirements through his metadata or out-of-band. +A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, which can result from the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. -todo: motivate interoperability for issuers +Since the key attestations may have large audience as many Credential Issuers that not necessarly uses the same trust framework or internal design decisions, it is required to use a common approach to facilitate interoperability. Therefore, key attestations SHOULD use a common format,allowing Issuers to develop consistent evaluation processes, reducing complexity and potential errors. Common formats makes easy for Issuers to demonstrate compliance with regulatory requirements across different jurisdictions, they also facilitate the development of shared best practices and security benchmarks. todo: explain usage of this within proof type or DPoP Proof @@ -2194,12 +2194,11 @@ The key attestation may use `x5c`, `kid`, `trust_chain` or other mechanisms to c * `user_authentication` : OPTIONAL. String that asserts the security mechanism the key storage component uses to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). * `apr` : OPTIONAL. String that asserts the resistance to a certain attack potential as described * `nonce`: OPTIONAL. String that represents a nonce provided by the Issuer to proof that a key attestation was freshly generated. - -todo: add optional `status` parameter + * `status`: OPTIONAL. JSON Object representing the supported revocation check mechanisms, such as the one defined in [status list] The Credential Issuer MUST validate that the JWT used as a proof is actually signed by a key identified in the JOSE Header. -This is an example of a Wallet Instance Attestation: +This is an example of a Key Attestation: ```json { @@ -2241,7 +2240,7 @@ This specification defines the following values for `key_type`: This specification defines the following values for `user_authentication`: -* `system_biometry`: It MUST be used when the key usage is authorized by the mobile operating system using a biometric factor. +* `system_biometry`: It MUST be used when the key usage is authorized by the operating system using a biometric factor, such as the one provided by mobile devices. * `system_pin`: It MUST be used when the key usage is authorized by the mobile operating system using personal identification number (PIN). * `internal_biometry`: It MUST be used when the key usage is authorized by the Wallet using a biometric factor. * `internal_pin`: It MUST be used when the key usage is authorized by the Wallet using PIN. From 56e26fc28cb29e478282fa163365c16126ad82b1 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 20 Sep 2024 19:05:31 +0200 Subject: [PATCH 04/36] 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 010e900b..8be119a1 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2182,7 +2182,7 @@ The JWT is signed by the Wallet Provider or the Wallet's key storage component i * in the JOSE header, * `alg`: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry [@IANA.JOSE.ALGS]. It MUST NOT be `none` or an identifier for a symmetric algorithm (MAC). - * `typ`: REQUIRED. MUST be `openid4vci-keyattestation+jwt`, which explicitly types the key proof JWT as recommended in Section 3.11 of [@!RFC8725]. + * `typ`: REQUIRED. MUST be `keyattestation+jwt`, which explicitly types the key proof JWT as recommended in Section 3.11 of [@!RFC8725]. The key attestation may use `x5c`, `kid`, `trust_chain` or other mechanisms to convey the public key and the associated trust mechanism to sign the key attestation. From 7c0baa3992bae8dfde758b88c540fff3aa86768d Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 20 Sep 2024 19:07:13 +0200 Subject: [PATCH 05/36] 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 8be119a1..4e0bff44 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2202,7 +2202,7 @@ This is an example of a Key Attestation: ```json { - "typ": "openid4vci-keyattestation+jwt", + "typ": "keyattestation+jwt", "alg": "ES256", "kid": "1" } From a96b09baddbd7e3d8bab99fbe3bb9e77ee18a76a Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 23 Sep 2024 12:57:37 +0200 Subject: [PATCH 06/36] Apply suggestions from code review --- 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 4e0bff44..c1f5eeec 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2189,7 +2189,7 @@ The key attestation may use `x5c`, `kid`, `trust_chain` or other mechanisms to c * in the JWT body, * `iat`: REQUIRED (number). Integer for the time at which the key attestation was issued using the syntax defined in [@!RFC7519]. * `exp`: REQUIRED (number). Integer for the time at which the key attestation expires using the syntax defined in [@!RFC7519]. - * `keys` : REQUIRED. Array of attested keys using the syntax of JWK as defined in [@!RFC7517]. + * `attested_keys` : REQUIRED. Array of attested keys using the syntax of JWK as defined in [@!RFC7517]. * `key_type` : OPTIONAL. String that asserts the key storage component and its security mechanism of attested keys from `keys`. This specification defines initial values in (#keyattestation-keytypes). * `user_authentication` : OPTIONAL. String that asserts the security mechanism the key storage component uses to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). * `apr` : OPTIONAL. String that asserts the resistance to a certain attack potential as described @@ -2214,7 +2214,7 @@ This is an example of a Key Attestation: "key_type": "strong_box", "user_authentication": "system_pin", "apr" : "https://trust-list.eu/apr/high", - "keys": [ + "attested_keys": [ { "kty": "EC", "crv": "P-256", From f5db4bf53adbd5cf57e3e2009a6b0e9bdd05b59a Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 23 Sep 2024 13:16:26 +0200 Subject: [PATCH 07/36] 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 c1f5eeec..ef8a3230 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2192,7 +2192,7 @@ The key attestation may use `x5c`, `kid`, `trust_chain` or other mechanisms to c * `attested_keys` : REQUIRED. Array of attested keys using the syntax of JWK as defined in [@!RFC7517]. * `key_type` : OPTIONAL. String that asserts the key storage component and its security mechanism of attested keys from `keys`. This specification defines initial values in (#keyattestation-keytypes). * `user_authentication` : OPTIONAL. String that asserts the security mechanism the key storage component uses to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). - * `apr` : OPTIONAL. String that asserts the resistance to a certain attack potential as described + * `apr` : OPTIONAL. String that asserts the resistance to a specified attack potential. The value contains an URL that identifies the given attack potential. * `nonce`: OPTIONAL. String that represents a nonce provided by the Issuer to proof that a key attestation was freshly generated. * `status`: OPTIONAL. JSON Object representing the supported revocation check mechanisms, such as the one defined in [status list] From 6e3a118cdd70577872520c2f0850716eeda929a2 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 23 Sep 2024 13:19:08 +0200 Subject: [PATCH 08/36] 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 ef8a3230..667b1a31 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2190,7 +2190,7 @@ The key attestation may use `x5c`, `kid`, `trust_chain` or other mechanisms to c * `iat`: REQUIRED (number). Integer for the time at which the key attestation was issued using the syntax defined in [@!RFC7519]. * `exp`: REQUIRED (number). Integer for the time at which the key attestation expires using the syntax defined in [@!RFC7519]. * `attested_keys` : REQUIRED. Array of attested keys using the syntax of JWK as defined in [@!RFC7517]. - * `key_type` : OPTIONAL. String that asserts the key storage component and its security mechanism of attested keys from `keys`. This specification defines initial values in (#keyattestation-keytypes). + * `key_type` : OPTIONAL. String that asserts the key storage component and its security mechanism of attested keys from the `attested_keys` parameter. This specification defines initial values in (#keyattestation-keytypes). * `user_authentication` : OPTIONAL. String that asserts the security mechanism the key storage component uses to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). * `apr` : OPTIONAL. String that asserts the resistance to a specified attack potential. The value contains an URL that identifies the given attack potential. * `nonce`: OPTIONAL. String that represents a nonce provided by the Issuer to proof that a key attestation was freshly generated. From 64878e065e940ab75d5024ab1feab7feb2fce9b7 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 23 Sep 2024 16:40:39 +0200 Subject: [PATCH 09/36] use key attestation in JWT proof type --- 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 667b1a31..2f9dd5fd 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -813,7 +813,7 @@ The JWT MUST contain the following elements: * `typ`: REQUIRED. MUST be `openid4vci-proof+jwt`, which explicitly types the key proof JWT as recommended in Section 3.11 of [@!RFC8725]. * `kid`: OPTIONAL. JOSE Header containing the key ID. If the Credential shall be bound to a DID, the `kid` refers to a DID URL which identifies a particular key in the DID Document that the Credential shall be bound to. It MUST NOT be present if `jwk` is present. * `jwk`: OPTIONAL. JOSE Header containing the key material the new Credential shall be bound to. It MUST NOT be present if `kid` is present. - * `x5c`: OPTIONAL. JOSE Header containing a certificate or certificate chain corresponding to the key used to sign the JWT. This element MAY be used to convey a key attestation. In such a case, the actual key certificate will contain attributes related to the key properties. + * `key_attestation`: OPTIONAL. JOSE Header containing a key attestation as described in (#keyattestation). * `trust_chain`: OPTIONAL. JOSE Header containing an [@!OpenID.Federation] Trust Chain. This element MAY be used to convey key attestation, metadata, metadata policies, federation Trust Marks and any other information related to a specific federation, if available in the chain. When used for signature verification, the header parameter `kid` MUST be present. * in the JWT body, @@ -865,8 +865,10 @@ Here is another example JWT not only proving possession of a private key but als ```json { + "typ": "openid4vci-proof+jwt", "alg": "ES256", - "x5c": [] + "kid": 0, + "key_attestation": [] }. { "iss": "s6BhdRkqt3", From 1932f71d162e72a24ca27f3443037ac74319bc91 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 1 Oct 2024 20:07:43 +0200 Subject: [PATCH 10/36] 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 | 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 2f9dd5fd..ba99f7d5 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2172,7 +2172,7 @@ The following is a non-normative example of a Credential Response containing a C A key attestation is an interoperable, verifiable statement that provides evidence of the authenticity and security properties of a key and its storage component. Keys can be stored in various key storage components, which differ in their ability to protect the private key against extraction and duplication, as well as in the methods used for End-User authentication to unlock key operations. These key storage components may be software-based or hardware-based, and can be located on the same device as the Wallet, on external security tokens, or on remote services that enable cryptographic key operations. -A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, which can result from the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. +A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys, e.g. for proof types sent in the Credential Request. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, based on the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. Since the key attestations may have large audience as many Credential Issuers that not necessarly uses the same trust framework or internal design decisions, it is required to use a common approach to facilitate interoperability. Therefore, key attestations SHOULD use a common format,allowing Issuers to develop consistent evaluation processes, reducing complexity and potential errors. Common formats makes easy for Issuers to demonstrate compliance with regulatory requirements across different jurisdictions, they also facilitate the development of shared best practices and security benchmarks. From 3c15c3cf9f8b5667b99e825fe390fbaf1f1bc8bc Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 1 Oct 2024 20:11:12 +0200 Subject: [PATCH 11/36] 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 ba99f7d5..35829fe3 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2170,7 +2170,7 @@ The following is a non-normative example of a Credential Response containing a C # Key Attestations {#keyattestation} -A key attestation is an interoperable, verifiable statement that provides evidence of the authenticity and security properties of a key and its storage component. Keys can be stored in various key storage components, which differ in their ability to protect the private key against extraction and duplication, as well as in the methods used for End-User authentication to unlock key operations. These key storage components may be software-based or hardware-based, and can be located on the same device as the Wallet, on external security tokens, or on remote services that enable cryptographic key operations. +A key attestation is an interoperable, verifiable statement that provides evidence of the authenticity and security properties of a key and its storage component. Keys can be stored in various key storage components, which differ in their ability to protect the private key against extraction and duplication, as well as in the methods used for End-User authentication to unlock key operations. These key storage components may be software-based or hardware-based, and can be located on the same device as the Wallet, on external security tokens, or on remote services that enable cryptographic key operations. Key attestations are signed by the Wallet Provider or the Wallet's key storage component itself. A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys, e.g. for proof types sent in the Credential Request. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, based on the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. From ef84be44b167f5d59a36e0b6e8c389c676f95faa Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 1 Oct 2024 20:17:49 +0200 Subject: [PATCH 12/36] 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 35829fe3..21538b1e 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2191,7 +2191,7 @@ The key attestation may use `x5c`, `kid`, `trust_chain` or other mechanisms to c * in the JWT body, * `iat`: REQUIRED (number). Integer for the time at which the key attestation was issued using the syntax defined in [@!RFC7519]. * `exp`: REQUIRED (number). Integer for the time at which the key attestation expires using the syntax defined in [@!RFC7519]. - * `attested_keys` : REQUIRED. Array of attested keys using the syntax of JWK as defined in [@!RFC7517]. + * `attested_keys` : REQUIRED. Array of attested keys from the same key storage component using the syntax of JWK as defined in [@!RFC7517]. * `key_type` : OPTIONAL. String that asserts the key storage component and its security mechanism of attested keys from the `attested_keys` parameter. This specification defines initial values in (#keyattestation-keytypes). * `user_authentication` : OPTIONAL. String that asserts the security mechanism the key storage component uses to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). * `apr` : OPTIONAL. String that asserts the resistance to a specified attack potential. The value contains an URL that identifies the given attack potential. From bfa2a26b35d918bdfcfd6065905f3cce378463fa Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 1 Oct 2024 20:53:50 +0200 Subject: [PATCH 13/36] adding metadata and text for apr --- openid-4-verifiable-credential-issuance-1_0.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 21538b1e..53b6f0d0 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -1282,6 +1282,10 @@ This specification defines the following Credential Issuer Metadata parameters: * `credential_signing_alg_values_supported`: OPTIONAL. Array of case sensitive strings that identify the algorithms that the Issuer uses to sign the issued Credential. Algorithm names used are determined by the Credential Format and are defined in (#format-profiles). * `proof_types_supported`: OPTIONAL. Object that describes specifics of the key proof(s) that the Credential Issuer supports. This object contains a list of name/value pairs, where each name is a unique identifier of the supported proof type(s). Valid values are defined in (#proof-types), other values MAY be used. This identifier is also used by the Wallet in the Credential Request as defined in (#credential-request). The value in the name/value pair is an object that contains metadata about the key proof and contains the following parameters defined by this specification: * `proof_signing_alg_values_supported`: REQUIRED. Array of case sensitive strings that identify the algorithms that the Issuer supports for this proof type. The Wallet uses one of them to sign the proof. Algorithm names used are determined by the key proof type and are defined in (#proof-types). + * `key_attestations_required`: OPTIONAL. Object that describes the requirement for key attestations as described in (#keyattestation), which the Credential Issuer expects the Wallet to send within the proof of the Credential Request. If the Credential Issuer does not expect a key attestation, this object is absent. If no `length` or `description` is given, this object may be empty, indicating that a key attestation without further constraints is required. + * `key_type`: OPTIONAL. Array defining values specified in (#keyattestation-keytypes) accepted by the Credential Issuer. + * `user_authentication`: OPTIONAL. Array defining values specified in (#keyattestation-keytypes) accepted by the Credential Issuer. + * `apr`: OPTIONAL. Array defining values specified in (#keyattestation-apr) accepted by the Credential Issuer. * `display`: OPTIONAL. Array of objects, where each object contains the display properties of the supported Credential for a certain language. Below is a non-exhaustive list of parameters that MAY be included. * `name`: REQUIRED. String value of a display name for the Credential. * `locale`: OPTIONAL. String value that identifies the language of this object represented as a language tag taken from values defined in BCP47 [@!RFC5646]. Multiple `display` objects MAY be included for separate languages. There MUST be only one object for each language identifier. @@ -2194,7 +2198,7 @@ The key attestation may use `x5c`, `kid`, `trust_chain` or other mechanisms to c * `attested_keys` : REQUIRED. Array of attested keys from the same key storage component using the syntax of JWK as defined in [@!RFC7517]. * `key_type` : OPTIONAL. String that asserts the key storage component and its security mechanism of attested keys from the `attested_keys` parameter. This specification defines initial values in (#keyattestation-keytypes). * `user_authentication` : OPTIONAL. String that asserts the security mechanism the key storage component uses to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). - * `apr` : OPTIONAL. String that asserts the resistance to a specified attack potential. The value contains an URL that identifies the given attack potential. + * `apr` : OPTIONAL. String that asserts the resistance to a specified attack potential. The value contains an URN that identifies the given attack potential. * `nonce`: OPTIONAL. String that represents a nonce provided by the Issuer to proof that a key attestation was freshly generated. * `status`: OPTIONAL. JSON Object representing the supported revocation check mechanisms, such as the one defined in [status list] @@ -2248,7 +2252,9 @@ This specification defines the following values for `user_authentication`: * `internal_pin`: It MUST be used when the key usage is authorized by the Wallet using PIN. * `secure_element_pin` It MUST be used when the key usage is authorized by the secure element managing the key itself using PIN. -todo: text about Level of assurance and attack potential resistance +## Attack Potential Resistance {#keyattestation-apr} + +This specification does not define any specific vaues for `apr`. Ecosystems may define their own values, any URN is a valid value. It is RECOMMENDED that the value is a URL that gives further information about the attack potential resistance and possible relations to level of assurances. # IANA Considerations From 8a8dcfd7d11e4e31345109d6ee319d9b56408eb1 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 3 Oct 2024 13:19:08 +0200 Subject: [PATCH 14/36] text for two methods of using key attestation --- openid-4-verifiable-credential-issuance-1_0.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 53b6f0d0..1920b586 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2178,6 +2178,12 @@ A key attestation is an interoperable, verifiable statement that provides eviden A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys, e.g. for proof types sent in the Credential Request. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, based on the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. +There are two flows how key attestations may be used: +- The Wallet generates new key(s) in the key storage component and receives key attestation(s) from the Wallet Provider. Lateron, the Wallet uses `jwt` proof type in the Credential Request to create a proof of possession of the key and adds the key attestation in the JOSE header. +- The Wallet starts an issuance flow and receives a nonce from the issuer. The Wallet generates new key(s) in the key storage component and requests a key attestation that includes the nonce. The Wallet uses `attestation` proof type in the Credential Request with the key attestation without a proof of possession of the key itself. + +The latter may avoid unnecessary user interaction during the credential issuance, as the key itself is not performing a signature operation. + Since the key attestations may have large audience as many Credential Issuers that not necessarly uses the same trust framework or internal design decisions, it is required to use a common approach to facilitate interoperability. Therefore, key attestations SHOULD use a common format,allowing Issuers to develop consistent evaluation processes, reducing complexity and potential errors. Common formats makes easy for Issuers to demonstrate compliance with regulatory requirements across different jurisdictions, they also facilitate the development of shared best practices and security benchmarks. todo: explain usage of this within proof type or DPoP Proof From 42de92f70f100fee7265df81a6f9859305cf81ac Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Thu, 3 Oct 2024 16:21:06 +0200 Subject: [PATCH 15/36] add new proof type for key attestation --- ...id-4-verifiable-credential-issuance-1_0.md | 26 +++++++++++++++---- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 1920b586..e2d35d90 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -803,6 +803,7 @@ This specification defines the following proof types: * `jwt`: A JWT [@!RFC7519] is used for proof of possession. When a `proof_type` parameter in a `proof` object is set to `jwt`, it MUST also contain a `jwt` parameter that includes a JWT as defined in (#jwt-proof-type). When a `proofs` object is using a `jwt` proof type, it MUST include a `jwt` parameter with its value being an array of JWTs, where each JWT is formed as defined in (#jwt-proof-type). * `ldp_vp`: A W3C Verifiable Presentation object signed using the Data Integrity Proof [@VC_Data_Integrity] as defined in [@VC_DATA_2.0] or [@VC_DATA] is used for proof of possession. When a `proof_type` parameter in a `proof` object is set to `ldp_vp`, it MUST also contain an `ldp_vp` parameter that includes a [W3C Verifiable Presentation](https://www.w3.org/TR/vc-data-model-2.0/#presentations-0) defined in (#ldp-vp-proof-type). When a `proofs` object is using a `ldp_vp` proof type, it MUST include an `ldp_vp` parameter with its value being an array of [W3C Verifiable Presentations](https://www.w3.org/TR/vc-data-model-2.0/#presentations-0), where each of these W3C Verifiable Presentation is formed as defined in (#ldp-vp-proof-type). +* `attestation`: A JWT [@!RFC7519] representing a key attestation is used instead of a proof of possession. When a `proof_type` parameter in a `proof` object is set to `attestation`, it MUST also contain an `attestation` parameter that includes a JWT as defined in (#attestation-proof-type). #### `jwt` Proof Type {#jwt-proof-type} @@ -922,6 +923,21 @@ Below is a non-normative example of a `proof` parameter: ``` +#### `attestation` Proof Type {#keyattestation-proof-type} + +A key attestation in JWT format as defined in (#keyattestation-jwt). + +When a key attestation is used as proof type, it MUST contain the `nonce` claim if a `c_nonce` was provided by the Credential Issuer and its value must be equal to the value of the server-provided `c_nonce`. + +Below is a non-normative example of a `proof` parameter (with line breaks within values for display purposes only): + +```json +{ + "proof_type": "attestation", + "attestation": "" +} +``` + ### Verifying Proof {#verifying-key-proof} To validate a key proof, the Credential Issuer MUST ensure that: @@ -2178,17 +2194,17 @@ A key attestation is an interoperable, verifiable statement that provides eviden A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys, e.g. for proof types sent in the Credential Request. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, based on the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. -There are two flows how key attestations may be used: -- The Wallet generates new key(s) in the key storage component and receives key attestation(s) from the Wallet Provider. Lateron, the Wallet uses `jwt` proof type in the Credential Request to create a proof of possession of the key and adds the key attestation in the JOSE header. -- The Wallet starts an issuance flow and receives a nonce from the issuer. The Wallet generates new key(s) in the key storage component and requests a key attestation that includes the nonce. The Wallet uses `attestation` proof type in the Credential Request with the key attestation without a proof of possession of the key itself. +There are two flows how key attestations can be used within Credential issuance: +- The Wallet uses the `jwt` proof type in the Credential Request to create a proof of possession of the key and adds the key attestation in the JOSE header. +- The Wallet uses the `attestation` proof type in the Credential Request with the key attestation without a proof of possession of the key itself. -The latter may avoid unnecessary user interaction during the credential issuance, as the key itself is not performing a signature operation. +The latter may avoid unnecessary user interaction during the Credential issuance, as the key itself is not performing a signature operation. Since the key attestations may have large audience as many Credential Issuers that not necessarly uses the same trust framework or internal design decisions, it is required to use a common approach to facilitate interoperability. Therefore, key attestations SHOULD use a common format,allowing Issuers to develop consistent evaluation processes, reducing complexity and potential errors. Common formats makes easy for Issuers to demonstrate compliance with regulatory requirements across different jurisdictions, they also facilitate the development of shared best practices and security benchmarks. todo: explain usage of this within proof type or DPoP Proof -## Key Attestation in JWT format +## Key Attestation in JWT format {#keyattestation-jwt} The JWT is signed by the Wallet Provider or the Wallet's key storage component itself and contains the following elements: From 1b98041747ad011fed3023fe04a4bb1dc2a6380f Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Thu, 3 Oct 2024 16:23:37 +0200 Subject: [PATCH 16/36] add document history entry for key attestation --- 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 e2d35d90..87b91048 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2426,6 +2426,7 @@ The technology described in this specification was made available from contribut -14 + * add key attestation as additional information in a proof of possesion and new proof type * removes CWT proof type * removes the Batch Credential Endpoint * clarify that authorization_details can be present in the Token Request for Pre-Authorized Code Flow when multiple Credential Configurations are present in the Credential Offer From 23c87628e7aa35df6f7af297479d8e06d7bc6b1f Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Thu, 3 Oct 2024 16:27:23 +0200 Subject: [PATCH 17/36] fix reference for attestation proof type --- 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 87b91048..f41714f7 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -923,7 +923,7 @@ Below is a non-normative example of a `proof` parameter: ``` -#### `attestation` Proof Type {#keyattestation-proof-type} +#### `attestation` Proof Type {#attestation-proof-type} A key attestation in JWT format as defined in (#keyattestation-jwt). From 7735e1c6e142a838867283ece8c1be2240eb5104 Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Thu, 3 Oct 2024 16:31:53 +0200 Subject: [PATCH 18/36] add references to key attestation usage --- openid-4-verifiable-credential-issuance-1_0.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index f41714f7..e0712533 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2195,15 +2195,13 @@ A key attestation is an interoperable, verifiable statement that provides eviden A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys, e.g. for proof types sent in the Credential Request. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, based on the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. There are two flows how key attestations can be used within Credential issuance: -- The Wallet uses the `jwt` proof type in the Credential Request to create a proof of possession of the key and adds the key attestation in the JOSE header. -- The Wallet uses the `attestation` proof type in the Credential Request with the key attestation without a proof of possession of the key itself. +- The Wallet uses the `jwt` proof type in the Credential Request to create a proof of possession of the key and adds the key attestation in the JOSE header as specified in (#jwt-proof-type). +- The Wallet uses the `attestation` proof type in the Credential Request with the key attestation without a proof of possession of the key itself as specified in (#attestation-proof-type). The latter may avoid unnecessary user interaction during the Credential issuance, as the key itself is not performing a signature operation. Since the key attestations may have large audience as many Credential Issuers that not necessarly uses the same trust framework or internal design decisions, it is required to use a common approach to facilitate interoperability. Therefore, key attestations SHOULD use a common format,allowing Issuers to develop consistent evaluation processes, reducing complexity and potential errors. Common formats makes easy for Issuers to demonstrate compliance with regulatory requirements across different jurisdictions, they also facilitate the development of shared best practices and security benchmarks. -todo: explain usage of this within proof type or DPoP Proof - ## Key Attestation in JWT format {#keyattestation-jwt} The JWT is signed by the Wallet Provider or the Wallet's key storage component itself and contains the following elements: From 05aa4679dedb7431445c509ef7114cd86558662d Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 8 Oct 2024 18:51:01 +0200 Subject: [PATCH 19/36] 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 e0712533..72a60754 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -934,7 +934,7 @@ Below is a non-normative example of a `proof` parameter (with line breaks within ```json { "proof_type": "attestation", - "attestation": "" + "attestation": "" } ``` From 246e0830fb8c601b4e8d81149f0f610e118fceb7 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 10 Oct 2024 16:54:52 +0200 Subject: [PATCH 20/36] Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Tobias Looker --- 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 72a60754..a10131cf 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -868,7 +868,7 @@ Here is another example JWT not only proving possession of a private key but als { "typ": "openid4vci-proof+jwt", "alg": "ES256", - "kid": 0, + "kid": "0", "key_attestation": [] }. { From 33612a34db392d29a4ff2e62cfbc6291abd4b22f Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 10 Oct 2024 16:55:37 +0200 Subject: [PATCH 21/36] 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 a10131cf..53f7e7ec 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -869,7 +869,7 @@ Here is another example JWT not only proving possession of a private key but als "typ": "openid4vci-proof+jwt", "alg": "ES256", "kid": "0", - "key_attestation": [] + "key_attestation": }. { "iss": "s6BhdRkqt3", From 4e6dc79c439f803e60a93d1826721054e52d4f31 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 10 Oct 2024 17:09:12 +0200 Subject: [PATCH 22/36] Apply suggestions from code review --- openid-4-verifiable-credential-issuance-1_0.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 53f7e7ec..e03e7f56 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2194,14 +2194,13 @@ A key attestation is an interoperable, verifiable statement that provides eviden A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys, e.g. for proof types sent in the Credential Request. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, based on the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. +Since the key attestations may have large audience as many Credential Issuers that not necessarly uses the same trust framework or internal design decisions, it is required to use a common approach to facilitate interoperability. Therefore, key attestations SHOULD use a common format,allowing Issuers to develop consistent evaluation processes, reducing complexity and potential errors. Common formats makes easy for Issuers to demonstrate compliance with regulatory requirements across different jurisdictions, they also facilitate the development of shared best practices and security benchmarks. + There are two flows how key attestations can be used within Credential issuance: - The Wallet uses the `jwt` proof type in the Credential Request to create a proof of possession of the key and adds the key attestation in the JOSE header as specified in (#jwt-proof-type). - The Wallet uses the `attestation` proof type in the Credential Request with the key attestation without a proof of possession of the key itself as specified in (#attestation-proof-type). The latter may avoid unnecessary user interaction during the Credential issuance, as the key itself is not performing a signature operation. - -Since the key attestations may have large audience as many Credential Issuers that not necessarly uses the same trust framework or internal design decisions, it is required to use a common approach to facilitate interoperability. Therefore, key attestations SHOULD use a common format,allowing Issuers to develop consistent evaluation processes, reducing complexity and potential errors. Common formats makes easy for Issuers to demonstrate compliance with regulatory requirements across different jurisdictions, they also facilitate the development of shared best practices and security benchmarks. - ## Key Attestation in JWT format {#keyattestation-jwt} The JWT is signed by the Wallet Provider or the Wallet's key storage component itself and contains the following elements: From 1f9e94bb17623a002b9f28e7a0d1082555e51c21 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 10 Oct 2024 17:10:11 +0200 Subject: [PATCH 23/36] 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 | 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 e03e7f56..4f81976c 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2209,7 +2209,7 @@ The JWT is signed by the Wallet Provider or the Wallet's key storage component i * `alg`: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry [@IANA.JOSE.ALGS]. It MUST NOT be `none` or an identifier for a symmetric algorithm (MAC). * `typ`: REQUIRED. MUST be `keyattestation+jwt`, which explicitly types the key proof JWT as recommended in Section 3.11 of [@!RFC8725]. -The key attestation may use `x5c`, `kid`, `trust_chain` or other mechanisms to convey the public key and the associated trust mechanism to sign the key attestation. +The key attestation may use `x5c`, `kid` or `trust_chain` (as defined in (#jwt-proof-type) ) to convey the public key and the associated trust mechanism to sign the key attestation. * in the JWT body, * `iat`: REQUIRED (number). Integer for the time at which the key attestation was issued using the syntax defined in [@!RFC7519]. From 1131416187a00db29b2eb43be1a9003467523a71 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 10 Oct 2024 17:16:58 +0200 Subject: [PATCH 24/36] 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 | 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 4f81976c..03ecf9e8 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2213,7 +2213,7 @@ The key attestation may use `x5c`, `kid` or `trust_chain` (as defined in (#jwt-p * in the JWT body, * `iat`: REQUIRED (number). Integer for the time at which the key attestation was issued using the syntax defined in [@!RFC7519]. - * `exp`: REQUIRED (number). Integer for the time at which the key attestation expires using the syntax defined in [@!RFC7519]. + * `exp`: REQUIRED (number). Integer for the time at which the key attestation and the key(s) it is attesting expire, using the syntax defined in [@!RFC7519]. * `attested_keys` : REQUIRED. Array of attested keys from the same key storage component using the syntax of JWK as defined in [@!RFC7517]. * `key_type` : OPTIONAL. String that asserts the key storage component and its security mechanism of attested keys from the `attested_keys` parameter. This specification defines initial values in (#keyattestation-keytypes). * `user_authentication` : OPTIONAL. String that asserts the security mechanism the key storage component uses to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). From f71e7484c639dd06b4f0920927fd0fdddc356918 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 10 Oct 2024 17:25:53 +0200 Subject: [PATCH 25/36] 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 03ecf9e8..4d581f2c 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -803,7 +803,7 @@ This specification defines the following proof types: * `jwt`: A JWT [@!RFC7519] is used for proof of possession. When a `proof_type` parameter in a `proof` object is set to `jwt`, it MUST also contain a `jwt` parameter that includes a JWT as defined in (#jwt-proof-type). When a `proofs` object is using a `jwt` proof type, it MUST include a `jwt` parameter with its value being an array of JWTs, where each JWT is formed as defined in (#jwt-proof-type). * `ldp_vp`: A W3C Verifiable Presentation object signed using the Data Integrity Proof [@VC_Data_Integrity] as defined in [@VC_DATA_2.0] or [@VC_DATA] is used for proof of possession. When a `proof_type` parameter in a `proof` object is set to `ldp_vp`, it MUST also contain an `ldp_vp` parameter that includes a [W3C Verifiable Presentation](https://www.w3.org/TR/vc-data-model-2.0/#presentations-0) defined in (#ldp-vp-proof-type). When a `proofs` object is using a `ldp_vp` proof type, it MUST include an `ldp_vp` parameter with its value being an array of [W3C Verifiable Presentations](https://www.w3.org/TR/vc-data-model-2.0/#presentations-0), where each of these W3C Verifiable Presentation is formed as defined in (#ldp-vp-proof-type). -* `attestation`: A JWT [@!RFC7519] representing a key attestation is used instead of a proof of possession. When a `proof_type` parameter in a `proof` object is set to `attestation`, it MUST also contain an `attestation` parameter that includes a JWT as defined in (#attestation-proof-type). +* `attestation`: A JWT [@!RFC7519] representing a key attestation without proof of possession is used. When a `proof_type` parameter in a `proof` object is set to `attestation`, it MUST also contain an `attestation` parameter that includes a JWT as defined in (#attestation-proof-type). #### `jwt` Proof Type {#jwt-proof-type} From 4b3c00d579ff6e48baef0d2076d4ccd316392757 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 08:16:58 +0200 Subject: [PATCH 26/36] 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 4d581f2c..a173ac8d 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -927,7 +927,7 @@ Below is a non-normative example of a `proof` parameter: A key attestation in JWT format as defined in (#keyattestation-jwt). -When a key attestation is used as proof type, it MUST contain the `nonce` claim if a `c_nonce` was provided by the Credential Issuer and its value must be equal to the value of the server-provided `c_nonce`. +When a key attestation is used as proof type, it MUST contain the `c_nonce` value provided by the Credential in its `nonce` parameter.. Below is a non-normative example of a `proof` parameter (with line breaks within values for display purposes only): From c148e8c50f54fb138d2d587630a8c04a848a0b96 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 16:24:19 +0200 Subject: [PATCH 27/36] Update openid-4-verifiable-credential-issuance-1_0.md --- 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 a173ac8d..fa2603e9 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -814,6 +814,7 @@ The JWT MUST contain the following elements: * `typ`: REQUIRED. MUST be `openid4vci-proof+jwt`, which explicitly types the key proof JWT as recommended in Section 3.11 of [@!RFC8725]. * `kid`: OPTIONAL. JOSE Header containing the key ID. If the Credential shall be bound to a DID, the `kid` refers to a DID URL which identifies a particular key in the DID Document that the Credential shall be bound to. It MUST NOT be present if `jwk` is present. * `jwk`: OPTIONAL. JOSE Header containing the key material the new Credential shall be bound to. It MUST NOT be present if `kid` is present. +* `x5c`: OPTIONAL. JOSE Header containing a certificate or certificate chain corresponding to the key used to sign the JWT. * `key_attestation`: OPTIONAL. JOSE Header containing a key attestation as described in (#keyattestation). * `trust_chain`: OPTIONAL. JOSE Header containing an [@!OpenID.Federation] Trust Chain. This element MAY be used to convey key attestation, metadata, metadata policies, federation Trust Marks and any other information related to a specific federation, if available in the chain. When used for signature verification, the header parameter `kid` MUST be present. From 4d803c02bb6bac6db8cd3c58e3379a377b1e1296 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 16:35:38 +0200 Subject: [PATCH 28/36] 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 fa2603e9..2f5149f1 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2191,7 +2191,7 @@ The following is a non-normative example of a Credential Response containing a C # Key Attestations {#keyattestation} -A key attestation is an interoperable, verifiable statement that provides evidence of the authenticity and security properties of a key and its storage component. Keys can be stored in various key storage components, which differ in their ability to protect the private key against extraction and duplication, as well as in the methods used for End-User authentication to unlock key operations. These key storage components may be software-based or hardware-based, and can be located on the same device as the Wallet, on external security tokens, or on remote services that enable cryptographic key operations. Key attestations are signed by the Wallet Provider or the Wallet's key storage component itself. +A key attestation defined by this specification is an interoperable, verifiable statement that provides to the Issuer, the evidence of authenticity and security properties of a key and its storage component. Keys can be stored in various key storage components, which differ in their ability to protect the private key against extraction and duplication, as well as in the methods used for End-User authentication to unlock key operations. These key storage components may be software-based or hardware-based, and can be located on the same device as the Wallet, on external security tokens, or on remote services that enable cryptographic key operations. Key attestations are issued by the Wallet's key storage component itself or by the Wallet Provider. When the Wallet Provider creates the key attestation, it needs to verify the authenticity of the claims it is making about the keys (e.g., by using the platform-specific attestations). A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys, e.g. for proof types sent in the Credential Request. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, based on the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. From f9cfdbacb07f9975c8f1f19b555a6f04d71824ec Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 16:36:20 +0200 Subject: [PATCH 29/36] 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 2f5149f1..0a85dc42 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2191,7 +2191,7 @@ The following is a non-normative example of a Credential Response containing a C # Key Attestations {#keyattestation} -A key attestation defined by this specification is an interoperable, verifiable statement that provides to the Issuer, the evidence of authenticity and security properties of a key and its storage component. Keys can be stored in various key storage components, which differ in their ability to protect the private key against extraction and duplication, as well as in the methods used for End-User authentication to unlock key operations. These key storage components may be software-based or hardware-based, and can be located on the same device as the Wallet, on external security tokens, or on remote services that enable cryptographic key operations. Key attestations are issued by the Wallet's key storage component itself or by the Wallet Provider. When the Wallet Provider creates the key attestation, it needs to verify the authenticity of the claims it is making about the keys (e.g., by using the platform-specific attestations). +A key attestation defined by this specification is an interoperable, verifiable statement that provides to the Issuer, the evidence of authenticity and security properties of a key and its storage component. Keys can be stored in various key storage components, which differ in their ability to protect the private key against extraction and duplication, as well as in the methods used for End-User authentication to unlock key operations. These key storage components may be software-based or hardware-based, and can be located on the same device as the Wallet, on external security tokens, or on remote services that enable cryptographic key operations. Key attestations are issued by the Wallet's key storage component itself or by the Wallet Provider. When the Wallet Provider creates the key attestation, it needs to verify the authenticity of the claims it is making about the keys (e.g., by using the platform-specific key attestations). A Wallet MAY provide key attestations to inform the Credential Issuer about the properties of the provided cryptographic public keys, e.g. for proof types sent in the Credential Request. Credential Issuers may want to evaluate these key attestations to determine whether the keys meet their own security requirements, based on the trust framework in use, regulatory requirements, laws, or internal design decisions. An Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism. From b00430058706ceafb68ace1865bb8ec7714e2044 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 17:03:18 +0200 Subject: [PATCH 30/36] Apply suggestions from code review --- 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 0a85dc42..4e52b501 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2216,9 +2216,9 @@ The key attestation may use `x5c`, `kid` or `trust_chain` (as defined in (#jwt-p * `iat`: REQUIRED (number). Integer for the time at which the key attestation was issued using the syntax defined in [@!RFC7519]. * `exp`: REQUIRED (number). Integer for the time at which the key attestation and the key(s) it is attesting expire, using the syntax defined in [@!RFC7519]. * `attested_keys` : REQUIRED. Array of attested keys from the same key storage component using the syntax of JWK as defined in [@!RFC7517]. - * `key_type` : OPTIONAL. String that asserts the key storage component and its security mechanism of attested keys from the `attested_keys` parameter. This specification defines initial values in (#keyattestation-keytypes). - * `user_authentication` : OPTIONAL. String that asserts the security mechanism the key storage component uses to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). - * `apr` : OPTIONAL. String that asserts the resistance to a specified attack potential. The value contains an URN that identifies the given attack potential. + * `key_type` : OPTIONAL. Case sensitive string that asserts the key storage component and its security mechanism of attested keys from the `attested_keys` parameter. This specification defines initial values in (#keyattestation-keytypes). + * `user_authentication` : OPTIONAL. Array of case sensitive strings that asserts the security mechanisms the key storage component allows to authenticate the End-User to authorize access to the private key from `keys`. This specification defines initial values in (#keyattestation-auth). + * `apr` : OPTIONAL. Array of case sensitive strings that assert attested resistance to specified attack potentials for the given keys. The string values contain URNs that identify the given attack potentials. * `nonce`: OPTIONAL. String that represents a nonce provided by the Issuer to proof that a key attestation was freshly generated. * `status`: OPTIONAL. JSON Object representing the supported revocation check mechanisms, such as the one defined in [status list] @@ -2238,8 +2238,8 @@ This is an example of a Key Attestation: "iat": 1516247022, "exp": 1541493724, "key_type": "strong_box", - "user_authentication": "system_pin", - "apr" : "https://trust-list.eu/apr/high", + "user_authentication": [ "system_pin" ], + "apr" : [ "https://trust-list.eu/apr/high" ], "attested_keys": [ { "kty": "EC", From 638cc52a53b1b86eb6a091e842cb8bc5d246bc3f Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 17:08:45 +0200 Subject: [PATCH 31/36] Apply suggestions from code review Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- openid-4-verifiable-credential-issuance-1_0.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 4e52b501..8a0557b8 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2256,11 +2256,12 @@ This is an example of a Key Attestation: This specification defines the following values for `key_type`: * `software`: It MUST be used when the Wallet uses software-based key management. -* `tee`: It SHOULD be used when the Wallet uses the Trusted Execution Environment for key management. -* `secure_enclave`: It SHOULD be used when the Wallet uses the Secure Enclave for key management. -* `strong_box`: It SHOULD be used when the Wallet uses the Strongbox for key management. -* `secure_element`: It SHOULD be used when the Wallet uses a Secure Element for key management. -* `hsm`: It SHOULD be used when the Wallet uses Hardware Security Module (HSM). +* `tee`: It MUST be used when the Wallet uses the Trusted Execution Environment for key management. +* `secure_enclave`: It MUST be used when the Wallet uses the Secure Enclave for key management. +* `strong_box`: It MUST be used when the Wallet uses the Strongbox for key management. +* `secure_element`: It MUST be used when the Wallet uses a Secure Element for key management. +* `hsm`: It MUST be used when the Wallet uses Hardware Security Module (HSM). +* `remote_hsm`: It MUST be used when the Wallet uses Hardware Security Module (HSM) that is not directly connected to the Wallet. ## User Authentication Types {#keyattestation-auth} From 3c6bb15584363f1444ca406be6189e0f9eb8550a Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 17:09:57 +0200 Subject: [PATCH 32/36] Update openid-4-verifiable-credential-issuance-1_0.md --- 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 8a0557b8..3ba834e2 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2260,8 +2260,8 @@ This specification defines the following values for `key_type`: * `secure_enclave`: It MUST be used when the Wallet uses the Secure Enclave for key management. * `strong_box`: It MUST be used when the Wallet uses the Strongbox for key management. * `secure_element`: It MUST be used when the Wallet uses a Secure Element for key management. -* `hsm`: It MUST be used when the Wallet uses Hardware Security Module (HSM). -* `remote_hsm`: It MUST be used when the Wallet uses Hardware Security Module (HSM) that is not directly connected to the Wallet. +* `hsm`: It MUST be used when the Wallet uses Hardware Security Module (HSM) for key management. +* `remote_hsm`: It MUST be used when the Wallet uses Hardware Security Module (HSM) that is not directly connected to the Wallet for key management. ## User Authentication Types {#keyattestation-auth} From 02aaaa98a4c350c934423ad19ba0b263c45d065c Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 17:30:22 +0200 Subject: [PATCH 33/36] Update openid-4-verifiable-credential-issuance-1_0.md --- 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 3ba834e2..258d6541 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2260,6 +2260,7 @@ This specification defines the following values for `key_type`: * `secure_enclave`: It MUST be used when the Wallet uses the Secure Enclave for key management. * `strong_box`: It MUST be used when the Wallet uses the Strongbox for key management. * `secure_element`: It MUST be used when the Wallet uses a Secure Element for key management. +* `external`: It MUST be used when the Wallet uses a local external hardware token for key management. * `hsm`: It MUST be used when the Wallet uses Hardware Security Module (HSM) for key management. * `remote_hsm`: It MUST be used when the Wallet uses Hardware Security Module (HSM) that is not directly connected to the Wallet for key management. From 06413057b205f6b953549f7bccc6b1159ed6cf1f Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 17:35:12 +0200 Subject: [PATCH 34/36] 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 | 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 258d6541..385c8e1e 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2268,11 +2268,11 @@ This specification defines the following values for `key_type`: This specification defines the following values for `user_authentication`: -* `system_biometry`: It MUST be used when the key usage is authorized by the operating system using a biometric factor, such as the one provided by mobile devices. -* `system_pin`: It MUST be used when the key usage is authorized by the mobile operating system using personal identification number (PIN). -* `internal_biometry`: It MUST be used when the key usage is authorized by the Wallet using a biometric factor. -* `internal_pin`: It MUST be used when the key usage is authorized by the Wallet using PIN. -* `secure_element_pin` It MUST be used when the key usage is authorized by the secure element managing the key itself using PIN. +* `system_biometry`: It MUST be used when the key usage is authorized by the key storage component itself or the associated operating system using a biometric factor, such as the one provided by mobile devices. +* `system_pin`: It MUST be used when the key usage is authorized by the key storage component itself or the associated operating system using personal identification number (PIN). +* `remote_biometry`: It MUST be used when the key usage is authorized by a remote system using a biometric factor. +* `remote_pin`: It MUST be used when the key usage is authorized by a remote system using a PIN. + ## Attack Potential Resistance {#keyattestation-apr} From 5677f136f043628579b035eeb92ebe95e5223f84 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 17:36:37 +0200 Subject: [PATCH 35/36] 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 385c8e1e..95340bec 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -2238,7 +2238,7 @@ This is an example of a Key Attestation: "iat": 1516247022, "exp": 1541493724, "key_type": "strong_box", - "user_authentication": [ "system_pin" ], + "user_authentication": [ "system_pin", "system_biometry" ], "apr" : [ "https://trust-list.eu/apr/high" ], "attested_keys": [ { From 19b78158625ec4832cef9b973311640ba031f0be Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 11 Oct 2024 17:52:24 +0200 Subject: [PATCH 36/36] simplify text in security consideration --- 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 95340bec..d0e55fe6 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -1346,7 +1346,7 @@ Credential Issuers often want to know what Wallet they are issuing Credentials t 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. +**Key attestation** is a mechanism where the key storage component or Wallet Provider asserts the keys and their security policy. The Wallet can provide this data in the Credential Request to allow the Credential Issuer to validate the key management policy. This requires the Credential Issuer to rely on the trust anchor of the key attestation and the respective key management policy. While some existing platforms have key attestation formats, this specification introduces a common key attestation format that may be used by Credential Issuers for improved interoperability, see [](#keyattestation). **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).