From 51d68f872e19feed66ef12b1a26a68489c7a3fd4 Mon Sep 17 00:00:00 2001 From: grausof Date: Thu, 23 May 2024 11:15:33 +0200 Subject: [PATCH 1/7] Fix Wallet Attestation request --- docs/en/wallet-attestation.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 23a62a2c1..636458710 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -121,7 +121,7 @@ Wallet Instance Initialization and Registration .. code-block:: http - PUT /wallet-instance HTTP/1.1 + POST /wallet-instance HTTP/1.1 Host: walletprovider.example.com Content-Type: application/json @@ -150,8 +150,7 @@ Wallet Instance Initialization and Registration .. code-block:: http - HTTP/1.1 201 Created - Content-Type: application/json + HTTP/1.1 204 No content If any errors occur during the Wallet Instance registration, the Wallet Provider MUST return an error response. The response MUST use the content type set to *application/json* and MUST include the following parameters: From 2bd7e53b05da24b93b2b23178a13d6446a07a349 Mon Sep 17 00:00:00 2001 From: grausof Date: Tue, 28 May 2024 11:15:50 +0200 Subject: [PATCH 2/7] Fix response code --- docs/en/wallet-attestation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 636458710..27b6da35f 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -356,7 +356,7 @@ Below an non-normative example of the Wallet Attestation without encoding and si .. code-block:: http - HTTP/1.1 201 OK + HTTP/1.1 200 OK Content-Type: application/jwt eyJhbGciOiJFUzI1NiIsInR5cCI6IndhbGx... redacted From a5f2b71c348a4f9ff64c2b4e2843f11fe0d11a15 Mon Sep 17 00:00:00 2001 From: grausof Date: Wed, 26 Jun 2024 17:44:27 +0200 Subject: [PATCH 3/7] Add normative example --- docs/en/wallet-attestation.rst | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 67a82cf57..88acad70d 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -118,10 +118,27 @@ Wallet Instance Initialization and Registration **Step 9**: The Wallet Instance sends the ``challenge`` with Key Attestation and Cryptographic Hardware Key Tag to the Wallet Provider Backend in order to register the Wallet Instance identified with the Cryptographic Hardware Key public key. -.. note:: +The request to the Wallet Provider endpoint in order to register the Wallet Instance MUST use the HTTP POST method with the parameters in the message body encoded in ``application/json`` format and the following parameters MUST be provided: + +.. _table_http_request_claim: +.. list-table:: Wallet Instance registration http request parameters + :widths: 20 60 20 + :header-rows: 1 - The Key Attestation (``key_attestation``) MUST be encoded in base64. + * - **Claim** + - **Description** + - **Reference** + * - **challenge** + - MUST be set to the challenge obtained from the Wallet Provider throught the ``nonce`` endpoint. + - `OAuth 2.0 Nonce Endpoint`_ + * - **key_attestation** + - It MUST be a ``base64url`` encoded Key Attestation obtained from the **Device Integrity Service**. + - + * - **hardware_key_tag** + - It MUST be set to the unique identifier of the **Cryptographic Hardware Keys** in ``base64url`` encoded + - +Below is a non-normative example of the request. .. code-block:: http From 2da793e49475b261c0ecbf76e2f19535763ca84c Mon Sep 17 00:00:00 2001 From: grausof Date: Wed, 26 Jun 2024 17:48:10 +0200 Subject: [PATCH 4/7] Add normative example --- docs/en/wallet-attestation.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 88acad70d..02a20accb 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -169,6 +169,9 @@ Below is a non-normative example of the request. 4. If these checks are passed, it MUST register the Wallet Instance, keeping the Cryptographic Hardware Key Tag and all useful information related to the device. 5. It SHOULD associate the Wallet Instance with a specific User uniquely identified within the Wallet Provider's systems. This will be useful for the lifecycle of the Wallet Instance and for a future revocation. +The response, in case of success, from the Wallet Provider must necessarily be a 204 No content. +Below is a non-normative example of the response. + .. code-block:: http HTTP/1.1 204 No content @@ -368,6 +371,11 @@ Below an non-normative example of the Wallet Attestation without encoding and si } **Step 18**: The Wallet Instance receives the Wallet Attestation signed by the Wallet Provider and performs security and integrity verifications. +The response is returned by the Wallet Provider at the end of the issuance flow. +If the authentication is successful the http response code MUST be 200 OK. + + +Below is a non-normative example of the response. .. code-block:: http From 98f41776f2171b474845a669ac8b62c41599cdc6 Mon Sep 17 00:00:00 2001 From: Francesco Grauso Date: Thu, 27 Jun 2024 09:09:16 +0200 Subject: [PATCH 5/7] Update docs/en/wallet-attestation.rst Co-authored-by: Giuseppe De Marco --- docs/en/wallet-attestation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 02a20accb..3fe86b15e 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -118,7 +118,7 @@ Wallet Instance Initialization and Registration **Step 9**: The Wallet Instance sends the ``challenge`` with Key Attestation and Cryptographic Hardware Key Tag to the Wallet Provider Backend in order to register the Wallet Instance identified with the Cryptographic Hardware Key public key. -The request to the Wallet Provider endpoint in order to register the Wallet Instance MUST use the HTTP POST method with the parameters in the message body encoded in ``application/json`` format and the following parameters MUST be provided: +In order to register the Wallet Instance, the request to the Wallet Provider MUST use the HTTP POST method. The parameters MUST be encoded using the `application/json` format and included in the message body. The following parameters MUST be provided: .. _table_http_request_claim: .. list-table:: Wallet Instance registration http request parameters From 001a7b301552334cb4b19e4a2c6162786cd810af Mon Sep 17 00:00:00 2001 From: Francesco Grauso Date: Thu, 27 Jun 2024 09:09:23 +0200 Subject: [PATCH 6/7] Update docs/en/wallet-attestation.rst Co-authored-by: Giuseppe De Marco --- docs/en/wallet-attestation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 3fe86b15e..4a6b4d16a 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -135,7 +135,7 @@ In order to register the Wallet Instance, the request to the Wallet Provider MUS - It MUST be a ``base64url`` encoded Key Attestation obtained from the **Device Integrity Service**. - * - **hardware_key_tag** - - It MUST be set to the unique identifier of the **Cryptographic Hardware Keys** in ``base64url`` encoded + - It MUST be set with the unique identifier of the **Cryptographic Hardware Keys** and encoded in ``base64url``. - Below is a non-normative example of the request. From 81d35a4c0d24fb6c716adf5f7fe7ca4e698d54fe Mon Sep 17 00:00:00 2001 From: Francesco Grauso Date: Thu, 27 Jun 2024 09:10:16 +0200 Subject: [PATCH 7/7] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- docs/en/wallet-attestation.rst | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 4a6b4d16a..78c0fa9eb 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -169,7 +169,7 @@ Below is a non-normative example of the request. 4. If these checks are passed, it MUST register the Wallet Instance, keeping the Cryptographic Hardware Key Tag and all useful information related to the device. 5. It SHOULD associate the Wallet Instance with a specific User uniquely identified within the Wallet Provider's systems. This will be useful for the lifecycle of the Wallet Instance and for a future revocation. -The response, in case of success, from the Wallet Provider must necessarily be a 204 No content. +Upon successful registration of the Wallet Instance, the Wallet Provider MUST respond with a status code set to 204 (No Content). Below is a non-normative example of the response. .. code-block:: http @@ -370,9 +370,7 @@ Below an non-normative example of the Wallet Attestation without encoding and si "exp": 1687288395 } -**Step 18**: The Wallet Instance receives the Wallet Attestation signed by the Wallet Provider and performs security and integrity verifications. -The response is returned by the Wallet Provider at the end of the issuance flow. -If the authentication is successful the http response code MUST be 200 OK. +**Step 18**: The response is returned by the Wallet Provider. If successful, the HTTP response code MUST be set to 200 OK and contain the Wallet Attestation signed by the Wallet Provider. The Wallet Instance therefore performs security and integrity verification about the Wallet Attestation. Below is a non-normative example of the response. @@ -382,7 +380,7 @@ Below is a non-normative example of the response. HTTP/1.1 200 OK Content-Type: application/jwt - eyJhbGciOiJFUzI1NiIsInR5cCI6IndhbGx... redacted + eyJhbGciOiJFUzI1NiIsInR5cCI6IndhbGx ... .. _table_wallet_attestation_request_claim: