From 9b5d2c2de7c23614bb972e15aa5d0f6fdb4757ac Mon Sep 17 00:00:00 2001 From: tlodderstedt Date: Fri, 7 Jul 2023 10:56:10 +0200 Subject: [PATCH 01/16] added wallet attestation scheme --- draft-oid4vc-haip-sd-jwt-vc.md | 37 +++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 81ed6d5..60763b8 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -139,7 +139,42 @@ Note: Issuers should be mindful of how long the usage of the refresh token is al ### Wallet Attestation Schema {#wallet-attestation-schema} -[Section 3.1 of wallet attestation draft would define the basics, and this profile will define the details.] +Wallets MUST use attestations following the definition given in [!I-D.ietf-looker-key-attestation-client-authentication]. + +In addition, the Wallet Attestation MUST contain the following claims: + +* `key_type`: this claim asserts the security mechanism the wallet can use to manage private keys. This capability is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `STRONGBOX`, `TEE`, `SecureEnclave`, `Software`. +* `user_authentication`: this claim asserts the security mechanism the wallet can use to authenticate access to private keys. This specification defines the following values for `user_authentication`: `APP_PIN_6_DIGITS`, ... + +These additional claims inform the issuer about the security capabilities of the wallet and allows the issuer to refuse credential issuance if the achievble security level of a certain wallet does not fulfil the issuer's requirements. + +Wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.terbu-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key. + +This is an example of a wallet attestation: + +```json +{ + "typ": "wallet-attestation+jwt", + "alg": "ES256", + "kid": "1" +} +. +{ + "iss": "https://wallet.example.com", + "sub": "https://wallet.example.com", + "exp": 1516247022, + "key_type": "STRONGBOX", + "user_authentication": "APP_PIN_6_DIGITS", + "cnf": { + "jwk": { + "kty": "EC", + "crv": "P-256", + "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", + "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" + } + } +} +``` ## Credential Endpoint From 74b182a39472cacb3d5f94c35cf302429acb9561 Mon Sep 17 00:00:00 2001 From: tlodderstedt Date: Fri, 7 Jul 2023 11:01:34 +0200 Subject: [PATCH 02/16] run fix-lint --- draft-oid4vc-haip-sd-jwt-vc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 60763b8..3c92aa5 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -141,12 +141,12 @@ Note: Issuers should be mindful of how long the usage of the refresh token is al Wallets MUST use attestations following the definition given in [!I-D.ietf-looker-key-attestation-client-authentication]. -In addition, the Wallet Attestation MUST contain the following claims: +In addition, the Wallet Attestation MUST contain the following claims: * `key_type`: this claim asserts the security mechanism the wallet can use to manage private keys. This capability is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `STRONGBOX`, `TEE`, `SecureEnclave`, `Software`. * `user_authentication`: this claim asserts the security mechanism the wallet can use to authenticate access to private keys. This specification defines the following values for `user_authentication`: `APP_PIN_6_DIGITS`, ... -These additional claims inform the issuer about the security capabilities of the wallet and allows the issuer to refuse credential issuance if the achievble security level of a certain wallet does not fulfil the issuer's requirements. +These additional claims inform the issuer about the security capabilities of the wallet and allows the issuer to refuse credential issuance if the achievble security level of a certain wallet does not fulfil the issuer's requirements. Wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.terbu-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key. From 20adc96244a1f69cf8c1c07015e9fbc5feb743c3 Mon Sep 17 00:00:00 2001 From: tlodderstedt Date: Wed, 12 Jul 2023 11:30:11 +0200 Subject: [PATCH 03/16] added values as suggested by Paul --- draft-oid4vc-haip-sd-jwt-vc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 3c92aa5..38a8894 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -143,8 +143,8 @@ Wallets MUST use attestations following the definition given in [!I-D.ietf-looke In addition, the Wallet Attestation MUST contain the following claims: -* `key_type`: this claim asserts the security mechanism the wallet can use to manage private keys. This capability is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `STRONGBOX`, `TEE`, `SecureEnclave`, `Software`. -* `user_authentication`: this claim asserts the security mechanism the wallet can use to authenticate access to private keys. This specification defines the following values for `user_authentication`: `APP_PIN_6_DIGITS`, ... +* `key_type`: this claim asserts the security mechanism the wallet can use to manage private keys. This capability is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `Software`, `TEE`, `Strongbox`, `Secure Enclave`, and `Secure Element`. +* `user_authentication`: this claim asserts the security mechanism the wallet can use to authenticate access to private keys. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. These additional claims inform the issuer about the security capabilities of the wallet and allows the issuer to refuse credential issuance if the achievble security level of a certain wallet does not fulfil the issuer's requirements. From 2d10a1bd4429680f48a79ba1afeabae7a66b5521 Mon Sep 17 00:00:00 2001 From: tlodderstedt Date: Wed, 12 Jul 2023 11:33:51 +0200 Subject: [PATCH 04/16] lint again --- draft-oid4vc-haip-sd-jwt-vc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 38a8894..5f6fead 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -141,10 +141,10 @@ Note: Issuers should be mindful of how long the usage of the refresh token is al Wallets MUST use attestations following the definition given in [!I-D.ietf-looker-key-attestation-client-authentication]. -In addition, the Wallet Attestation MUST contain the following claims: +In addition to the claims, the Wallet Attestation MUST contain the following claims: * `key_type`: this claim asserts the security mechanism the wallet can use to manage private keys. This capability is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `Software`, `TEE`, `Strongbox`, `Secure Enclave`, and `Secure Element`. -* `user_authentication`: this claim asserts the security mechanism the wallet can use to authenticate access to private keys. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. +* `user_authentication`: this claim asserts the security mechanism the wallet can use to authenticate access to private keys. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. These additional claims inform the issuer about the security capabilities of the wallet and allows the issuer to refuse credential issuance if the achievble security level of a certain wallet does not fulfil the issuer's requirements. From dfbe1e49579ac9049f9281f1fa651c3c778632a9 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 13 Jul 2023 13:13:29 +0200 Subject: [PATCH 05/16] Update draft-oid4vc-haip-sd-jwt-vc.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- draft-oid4vc-haip-sd-jwt-vc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 5f6fead..94de303 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -148,7 +148,7 @@ In addition to the claims, the Wallet Attestation MUST contain the following cla These additional claims inform the issuer about the security capabilities of the wallet and allows the issuer to refuse credential issuance if the achievble security level of a certain wallet does not fulfil the issuer's requirements. -Wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.terbu-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key. +To obtain the issuer's Public key for verification, wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.terbu-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key. This is an example of a wallet attestation: From c5214b78835b6e9227a286e05b7ff9fafb3e2879 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 13 Jul 2023 13:13:54 +0200 Subject: [PATCH 06/16] Update draft-oid4vc-haip-sd-jwt-vc.md Co-authored-by: Paul Bastian --- draft-oid4vc-haip-sd-jwt-vc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 94de303..16ea6d8 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -143,7 +143,7 @@ Wallets MUST use attestations following the definition given in [!I-D.ietf-looke In addition to the claims, the Wallet Attestation MUST contain the following claims: -* `key_type`: this claim asserts the security mechanism the wallet can use to manage private keys. This capability is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `Software`, `TEE`, `Strongbox`, `Secure Enclave`, and `Secure Element`. +* `key_type`: this claim asserts the security mechanism the wallet can use to manage private keys. This capability is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `Software`, `TEE`, `Strongbox`, `Secure Enclave`, `Secure Element` and `External-HSM`. * `user_authentication`: this claim asserts the security mechanism the wallet can use to authenticate access to private keys. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. These additional claims inform the issuer about the security capabilities of the wallet and allows the issuer to refuse credential issuance if the achievble security level of a certain wallet does not fulfil the issuer's requirements. From 27450a877bcee6da4dbd04492f62c8cb7d3c9039 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 20 Jul 2023 20:12:38 +0200 Subject: [PATCH 07/16] fixed references to client attestation draft --- draft-oid4vc-haip-sd-jwt-vc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 5f11c40..d21d7fb 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -139,7 +139,7 @@ Note: Issuers should be mindful of how long the usage of the refresh token is al ### Wallet Attestation Schema {#wallet-attestation-schema} -Wallets MUST use attestations following the definition given in [!I-D.ietf-looker-key-attestation-client-authentication]. +Wallets MUST use attestations following the definition given in [@!I-D.looker-oauth-attestation-based-client-auth]. In addition to the claims, the Wallet Attestation MUST contain the following claims: From 78ba68ca303c2aab380e68372c2f44a20a850a69 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 18 Sep 2023 16:15:40 +0200 Subject: [PATCH 08/16] changed the PR to match the evolved concepts --- draft-oid4vc-haip-sd-jwt-vc.md | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 8d2f22a..debf3c3 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -141,12 +141,14 @@ Note: Issuers should be mindful of how long the usage of the refresh token is al Wallets MUST use attestations following the definition given in [@!I-D.looker-oauth-attestation-based-client-auth]. -In addition to the claims, the Wallet Attestation MUST contain the following claims: +In addition to this definition, the Wallet Attestation MAY contain the following claims in the `cnf` element: -* `key_type`: this claim asserts the security mechanism the wallet can use to manage private keys. This capability is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `Software`, `TEE`, `Strongbox`, `Secure Enclave`, `Secure Element` and `External-HSM`. -* `user_authentication`: this claim asserts the security mechanism the wallet can use to authenticate access to private keys. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. +* `key_type`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `Software`, `TEE`, `Strongbox`, `Secure Enclave`, `Secure Element` and `External-HSM`. +* `user_authentication`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. -These additional claims inform the issuer about the security capabilities of the wallet and allows the issuer to refuse credential issuance if the achievble security level of a certain wallet does not fulfil the issuer's requirements. +The Wallet Attestation MAY also contain the following claim: + +* `aal`: OPTIONAL. JSON String asserting the authentication level of the wallet and the key as asserted in the `cnf` claim. To obtain the issuer's Public key for verification, wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.terbu-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key. @@ -160,18 +162,20 @@ This is an example of a wallet attestation: } . { - "iss": "https://wallet.example.com", - "sub": "https://wallet.example.com", - "exp": 1516247022, - "key_type": "STRONGBOX", - "user_authentication": "APP_PIN_6_DIGITS", + "iss": "https://attester.example.com", + "sub": "https://client.example.com", + "iat": 1516247022, + "exp": 1541493724, + "aal" : "https://trust-list.eu/aal/high", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" - } + }, + "key_type": "STRONGBOX", + "user_authentication": "SYSTEM_PIN", } } ``` From 1ca5b6d25cbf0fd5072b3665f3ebf52f869b6bef Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 18 Sep 2023 19:13:32 +0200 Subject: [PATCH 09/16] expanded key type values --- draft-oid4vc-haip-sd-jwt-vc.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index debf3c3..88399a9 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -143,7 +143,14 @@ Wallets MUST use attestations following the definition given in [@!I-D.looker-oa In addition to this definition, the Wallet Attestation MAY contain the following claims in the `cnf` element: -* `key_type`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `Software`, `TEE`, `Strongbox`, `Secure Enclave`, `Secure Element` and `External-HSM`. +* `key_type`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). 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 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 the Trusted Execution Environment for key management. + * `hsm`: It SHOULD be used when the wallet uses Hardware Security Module (HSM). * `user_authentication`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. The Wallet Attestation MAY also contain the following claim: From c2def75ebac047b666cdcd272c03467b5c172dc7 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 18 Sep 2023 19:17:37 +0200 Subject: [PATCH 10/16] itemized key type values, changed ref to ietf-oauth-attestation-based-client-auth --- draft-oid4vc-haip-sd-jwt-vc.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 88399a9..8a4403c 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -128,7 +128,7 @@ Both sending Credential Offer same-device and cross-device is supported. ## Token Endpoint {#token-endpoint} - * The Wallets MUST perform client authentication as defined in [@!I-D.looker-oauth-attestation-based-client-auth]. + * The Wallets MUST perform client authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth]. * Refresh tokens MUST be supported for credential refresh. * Wallets MUST support deferred authorization by being able to process the Token error response parameters `authorization_pending` and `slow_down`, and the credential offer parameter `interval`. * The wallet attestation JWT scheme is defined in (#wallet-attestation-schema). @@ -139,7 +139,7 @@ Note: Issuers should be mindful of how long the usage of the refresh token is al ### Wallet Attestation Schema {#wallet-attestation-schema} -Wallets MUST use attestations following the definition given in [@!I-D.looker-oauth-attestation-based-client-auth]. +Wallets MUST use attestations following the definition given in [@!I-D.ietf-oauth-attestation-based-client-auth]. In addition to this definition, the Wallet Attestation MAY contain the following claims in the `cnf` element: @@ -169,8 +169,8 @@ This is an example of a wallet attestation: } . { - "iss": "https://attester.example.com", - "sub": "https://client.example.com", + "iss": "", + "sub": "<`client_id` of the OAuth client>", "iat": 1516247022, "exp": 1541493724, "aal" : "https://trust-list.eu/aal/high", From 794a3397f3cdb675fac1c06f4b6e82510f261f61 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 18 Sep 2023 19:25:54 +0200 Subject: [PATCH 11/16] make fix-lint --- draft-oid4vc-haip-sd-jwt-vc.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 8a4403c..76d5017 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -143,19 +143,19 @@ Wallets MUST use attestations following the definition given in [@!I-D.ietf-oaut In addition to this definition, the Wallet Attestation MAY contain the following claims in the `cnf` element: -* `key_type`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). 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 software-based key management. - * `tee`: It SHOULD be used when the wallet uses the Trusted Execution Environment for key management. +* `key_type`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). 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 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 the Trusted Execution Environment for key management. + * `secure_element`: It SHOULD be used when the Wallet uses the Trusted Execution Environment for key management. * `hsm`: It SHOULD be used when the wallet uses Hardware Security Module (HSM). * `user_authentication`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. -The Wallet Attestation MAY also contain the following claim: +The Wallet Attestation MAY also contain the following claim: -* `aal`: OPTIONAL. JSON String asserting the authentication level of the wallet and the key as asserted in the `cnf` claim. +* `aal`: OPTIONAL. JSON String asserting the authentication level of the wallet and the key as asserted in the `cnf` claim. To obtain the issuer's Public key for verification, wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.terbu-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key. @@ -181,8 +181,8 @@ This is an example of a wallet attestation: "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" }, - "key_type": "STRONGBOX", - "user_authentication": "SYSTEM_PIN", + "key_type": "STRONGBOX", + "user_authentication": "SYSTEM_PIN", } } ``` From c0a7c6a0ccaf0c8476e1353d04f4f21da7b7bd14 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 18 Sep 2023 19:44:08 +0200 Subject: [PATCH 12/16] profile is defined in HAIP --- draft-oid4vc-haip-sd-jwt-vc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 76d5017..a805aff 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -103,7 +103,7 @@ Unless explicitly stated, all normative requirements apply to all participating Implementations of this profile: * MUST support both pre-auth code flow and authorization code flow. -* MUST support SD-JWT VC profile as defined in OID4VCI specification. +* MUST support the SD-JWT VC profile as defined in this specification. * MUST support sender-constrained Tokens using a mechanism as defined in [@!I-D.ietf-oauth-dpop]. * MUST support [@!RFC7636] with `S256` as the code challenge method. From 8cb4f356099e4ac0405e50b02af8ce95723c37bb Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 20 Sep 2023 18:22:04 +0200 Subject: [PATCH 13/16] corrected key type values --- draft-oid4vc-haip-sd-jwt-vc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index a805aff..0bd7ad8 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -145,11 +145,11 @@ In addition to this definition, the Wallet Attestation MAY contain the following * `key_type`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). 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 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 the Trusted Execution Environment 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`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. From d9e263c2f64e7a052cc451d7abfcd586a98e6ad5 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Mon, 25 Sep 2023 13:37:25 -0700 Subject: [PATCH 14/16] Apply suggestions from Giuseppe's code review Co-authored-by: Giuseppe De Marco --- draft-oid4vc-haip-sd-jwt-vc.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 0bd7ad8..c35d275 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -131,7 +131,7 @@ Both sending Credential Offer same-device and cross-device is supported. * The Wallets MUST perform client authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth]. * Refresh tokens MUST be supported for credential refresh. * Wallets MUST support deferred authorization by being able to process the Token error response parameters `authorization_pending` and `slow_down`, and the credential offer parameter `interval`. - * The wallet attestation JWT scheme is defined in (#wallet-attestation-schema). + * The Wallet Attestation JWT scheme is defined in (#wallet-attestation-schema). Note: It is RECOMMENDED to use ephemeral client attestation JWTs for client authentication in order to prevent linkability across Credential Issuers. @@ -143,23 +143,23 @@ Wallets MUST use attestations following the definition given in [@!I-D.ietf-oaut In addition to this definition, the Wallet Attestation MAY contain the following claims in the `cnf` element: -* `key_type`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: - * `software`: It MUST be used when the wallet uses software-based key management. +* `key_type`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the Wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud Wallet). 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. + * `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`: OPTIONAL. JSON String that asserts the security mechanism the wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. + * `hsm`: It SHOULD be used when the Wallet uses Hardware Security Module (HSM). +* `user_authentication`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: `system_biometry`, `system_pin`, `internal_biometry`, `internal_pin`, and `secureelement_pin`. The Wallet Attestation MAY also contain the following claim: -* `aal`: OPTIONAL. JSON String asserting the authentication level of the wallet and the key as asserted in the `cnf` claim. +* `aal`: OPTIONAL. JSON String asserting the authentication level of the Wallet and the key as asserted in the `cnf` claim. To obtain the issuer's Public key for verification, wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.terbu-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key. -This is an example of a wallet attestation: +This is an example of a Wallet Instance Attestation: ```json { From 1ae5b3317d8b849fc7305505bc8581a1242db039 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 4 Oct 2023 17:55:00 +0200 Subject: [PATCH 15/16] Update draft-oid4vc-haip-sd-jwt-vc.md Co-authored-by: Paul Bastian --- draft-oid4vc-haip-sd-jwt-vc.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index c35d275..3c21011 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -151,7 +151,12 @@ In addition to this definition, the Wallet Attestation MAY contain the following * `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`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: `system_biometry`, `system_pin`, `internal_biometry`, `internal_pin`, and `secureelement_pin`. +* `user_authentication`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: + * `system_biometry`: It MUST be used when the key usage is authorized through a biometric factor by the operating system. + * `system_pin`: It MUST be used when the key usage is authorized through a knowledge factor by the operating system. + * `internal_biometry`: It MUST be used when the key usage is authorized through a biometric factor by the Wallet itself. + * `internal_pin`: It MUST be used when the key usage is authorized through a knowledge factor by the Wallet itself. + * `secure_element_pin` It MUST be used when the key usage is authorized through a knowledge factor by the secure element that is managing the key itself. The Wallet Attestation MAY also contain the following claim: From e778c5561940b011a0c0a1a9bf69237dccf97f01 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 5 Oct 2023 20:52:08 +0200 Subject: [PATCH 16/16] Update draft-oid4vc-haip-sd-jwt-vc.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- draft-oid4vc-haip-sd-jwt-vc.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-oid4vc-haip-sd-jwt-vc.md b/draft-oid4vc-haip-sd-jwt-vc.md index 3c21011..5ac4059 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.md +++ b/draft-oid4vc-haip-sd-jwt-vc.md @@ -151,12 +151,12 @@ In addition to this definition, the Wallet Attestation MAY contain the following * `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`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: - * `system_biometry`: It MUST be used when the key usage is authorized through a biometric factor by the operating system. - * `system_pin`: It MUST be used when the key usage is authorized through a knowledge factor by the operating system. - * `internal_biometry`: It MUST be used when the key usage is authorized through a biometric factor by the Wallet itself. - * `internal_pin`: It MUST be used when the key usage is authorized through a knowledge factor by the Wallet itself. - * `secure_element_pin` It MUST be used when the key usage is authorized through a knowledge factor by the secure element that is managing the key itself. +* `user_authentication`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to authenticate the user to authorize access to the private key associated with the public key given in the `cnf` claim. 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. The Wallet Attestation MAY also contain the following claim: