From 1f4cf60032d6b4a58331351f1113dae6eaa7171b Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 31 May 2024 13:13:45 +0200 Subject: [PATCH 001/105] Status assertion first draft --- docs/en/revocation-lists.rst | 154 ++++++++++++++++++++--------------- 1 file changed, 90 insertions(+), 64 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 908e41111..adf5abe0a 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -11,13 +11,13 @@ For these reasons a robust mechanism for managing the life-cycle and the revocat This section outlines the key technical requirements and processes related to the revocation of Digital Credentials. Furthermore, it provides the technical details that the Verifiers MUST implement to verify, in a secure and reliable manner, the validity of a Digital Credential during the presentation phase. -The verification of the validity of a Digital Credential is based on the `[OAuth Status Attestation draft 01] `_ specification. +The verification of the validity of a Digital Credential is based on the `[OAuth Status Assertion draft 01] `_ specification. -A Status Attestation is a signed document serving as proof of a Digital Credential's current validity status. The Issuer provides these attestations to Holders who can present them to Verifiers together with the corresponding Digital Credentials. +A Status Assertion is a signed document serving as proof of a Digital Credential's current validity status. The Issuer provides these assertions to Holders who can present them to Verifiers together with the corresponding Digital Credentials. -The Status Attestations have the following features: +The Status Assertions have the following features: -- automated issuance, as the User authentication is not required for the provisioning of the Status Attestation; +- automated issuance, as the User authentication is not required for the provisioning of the Status Assertion; - verification of the Digital Credential validity status in both online and offline scenarios; - privacy-preserving, according to the following evidences: @@ -30,7 +30,7 @@ The Status Attestations have the following features: Operational Requirements ------------------------ -- **Internet Connection for Status Attestations**: Status Attestations can be obtained only when the Wallet Instance is connected to the internet and actively operated by the User. +- **Internet Connection for Status Assertions**: Status Assertions can be obtained only when the Wallet Instance is connected to the internet and actively operated by the User. - **Role of a Credential Issuer**: A Credential Issuer is responsible for creating and issuing Credentials, as well as managing their lifecycle and validity status. - **Involvement of Authentic Sources**: When one or more Authentic Sources are involved in the issuance of a Digital Credential, the information exchanged between the Authentic Source and the Credential Issuer is crucial for the Digital Credential's issuance. Furthermore, in cases where the Authentic Source initiates a revocation or data changes, revoking the Digital Credential becomes necessary. @@ -40,15 +40,16 @@ Operational Requirements Functional Requirements ----------------------- -**The Status Attestation MUST:** +**The Status Assertion:** -- be presented in conjunction with the Digital Credential; -- be timestamped with the issuance datetime; -- contain the expiration datetime after which it SHOULD NOT be considered valid anymore and it MUST NOT be greater than the one contained in the Digital Credential which it refers to; -- have a validity period not greater than 24 hours; -- provide the proof about the non-revocation of the Digital Credential which is related to and MUST be validated using the cryptographic signature of the Issuer; -- not reveal any information about the Relying Party, the User's device or the User's data contained in the Digital Credential the attestation is related to; -- be non-repudiable even beyond its expiration time and even in the case of cryptographic keys rotation. +- SHOULD be presented in conjunction with the Digital Credential; +- MUST include information that links it to the referenced Digital Credential; +- MUST be timestamped with its issuance datetime, using a timestamp which is at or after the time of Digital Credential issuance which it refers; +- MUST contain the expiration datetime after which both the Status Assertion and the Digital Credential it refers MUST NOT be considered valid anymore. The expiration datetime MUST be superior to the Status Assertion issuance datetime and it MUST end before the expiration datetime of the Digital Credential; +- MUST have a validity period not greater than 24 hours; +- MUST provide the proof about the non-revocation of the Digital Credential which is related to and MUST be validated using the cryptographic signature of the Issuer; +- MUST NOT reveal any information about the Relying Party, the User's device or the User's data contained in the Digital Credential the assertion is related to; +- MUST be non-repudiable even beyond its expiration time and even in the case of cryptographic keys rotation. **The Issuer MUST:** @@ -63,15 +64,15 @@ Functional Requirements - provide a web service for allowing a Wallet Instance, with a proof of possession of a specific Digital Credential, to - request a revocation of that Digital Credential; - - obtain a related Status Attestation; + - obtain a related Status Assertion; - provide out-of-band mechanisms through which the User can request the revocation of their Digital Credentials, using a robust procedure for identity proofing and User authentication, in particular when the User is unable to use the personal Wallet Instance. **The Wallet Instance MUST:** -- check periodically the validity status of the Digital Credential that is stored in it, requesting a Status Attestation for each Digital Credential; -- be able to present a Status Attestation if required by a Verifier, along with the corresponding Digital Credential; +- check periodically the validity status of the Digital Credential that is stored in it, requesting a Status Assertion for each Digital Credential; +- be able to present a Status Assertion if required by a Verifier, along with the corresponding Digital Credential; - request a revocation of a Digital Credential when the Users delete it from the storage. @@ -104,7 +105,7 @@ Credential Revocation Flows can start under different scenarios, such as: The revocation scenarios involve two main flows: - The **Revocation flows**: these flows describe how an Entity requests for a Digital Credential revocation. - - The **Status Attestation flows**: these flows define the technical protocols for requesting and obtaining a Status Attestation and how the Wallet Instance will provide it to a Verifier as a proof of validity of a corresponding Digital Credential. + - The **Status Assertion flows**: these flows define the technical protocols for requesting and obtaining a Status Assertion and how the Wallet Instance will provide it to a Verifier as a proof of validity of a corresponding Digital Credential. .. _sec_revocation_high_level_flow: @@ -150,7 +151,7 @@ Below, is given a non-normative example of a Credential PoP with decoded JWT hea { "alg": "ES256", - "typ": "status-attestation-request+jwt", + "typ": "status-assertion-request+jwt", "kid": $CREDENTIAL-CNF-JWKID } . @@ -192,7 +193,7 @@ The requests to the *Issuer Revocation endpoint* MUST be HTTP with method POST, - **Reference** * - **credential_pop** - It MUST contain a JWT proof of possession of the cryptographic key the Credential to be revoked shall be bound to. See Section :ref:`Credential Proof of Possession ` for more details. - - `[OAuth Status Attestation draft 01] `_ + - `[OAuth Status Assertion draft 01] `_ The Revocation Endpoint MUST be provided by the Issuer within its Metadata. @@ -260,63 +261,77 @@ Below a non-normative example of an HTTP Response with an error. -Status Attestation Flows +Status Assertion Flows ------------------------ -The Status Attestation process is divided into the following phases: +The Status Assertion process is divided into the following phases: - 1. The Status Attestation Request by a Wallet Instance: it involves the Wallet Instance and the Issuer. - 2. The Status Attestation Presentation to a Verifier: it involves the Wallet Instance and the Verifier. + 1. The Status Assertion Request by a Wallet Instance: it involves the Wallet Instance and the Issuer. + 2. The Status Assertion Presentation to a Verifier: it involves the Wallet Instance and the Verifier. .. figure:: ../../images/High-Level-Flow-Status-Attestation.svg :figwidth: 100% :align: center - High-Level Status Attestation Flows + High-Level Status Assertion Flows -.. _sec_revocation_status_attestation_request: +.. _sec_revocation_status_assertion_request: -Status Attestation Request by Wallet Instance +Status Assertion Request by Wallet Instance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The presentation of a Credential to a Verifier may occur long after it has been issued by the Issuer. During this time interval, the Credential can be invalidated for any reason and therefore the Verifier also needs to verify its revocation or suspension status. To address this scenario, the Issuer provides the Wallet Instance with a *Status Attestation*. This Attestation is bound to a Credential so that the Wallet Instance can present it to a Verifier, along with the Credential itself, as proof of non-revocation status of the Credential. +The presentation of a Credential to a Verifier may occur long after it has been issued by the Issuer. During this time interval, the Credential can be invalidated for any reason and therefore the Verifier also needs to verify its revocation or suspension status. To address this scenario, the Issuer provides the Wallet Instance with a *Status Assertion*. This Assertion is bound to a Credential so that the Wallet Instance can present it to a Verifier, along with the Credential itself, as proof of non-revocation status of the Credential. -The following diagram shows how the Wallet Instance requests a Status Attestation to the Issuer. +The following diagram shows how the Wallet Instance requests a Status Assertion to the Issuer. -.. _fig_Low-Level-Flow-Status-Attestation: +.. _fig_Low-Level-Flow-Status-Assertion: .. figure:: ../../images/Low-Level-Flow-Revocation-Attestation.svg :figwidth: 100% :align: center :target: https://www.plantuml.com/plantuml/svg/NP31Rk9038RlynGMsWD8mDwHTWM22tlOHWML2r8rIHmoQZ9EnnuGRryFeK0vsl_tErzcpcA3nBOnDWhvsEOOJAShLxZEUe71pZOD2gozahx00LY6a_l9h9aZXalqb2oYrEXrXWt5SArRDkRaOF8Nt0oobyqMVkjnYGm1FoEo38k0PQhPvhsZxi-lvMtEAFktsuwC-Uw_sSQLLX3k32W4IXdZIGCwOW0tjZo3ROtGomBbOfrdg0Are9Bmh0fxdzQnIzTBi2B1vL5G_NrvQHpJfvsSeRVN0bKfIFS2nKEj952K2LMJF9LQB6hh7RTZPOSuFKoLJE3bNBRwlu95jcRWCmks8xZ_vRB6uWCg2WyUUz-x9P-RoqCbO0etoKtPXGWcJqU-Vnlb53mf-OhSaMVKGUfh0PxvEVeojiqN - Status Attestation Request Flow + Status Assertion Request Flow + +**Step 1 (Status Assertion Request)**: The Wallet Instance sends the Status Assertion Request to the Credential Issuer, where: + +- The request MUST contain the base64url encoded hash value of the Digital Credential, for which the Status Assertion is requested, and enveloped in a signed Status Assertion Request object. + +- The Status Assertion Request object MUST be signed with the private key corresponding to the confirmation claim assigned by the Issuer and contained within the Digital Credential. -**Step 1 (Status Attestation Request)**: The Wallet Instance sends the Status Attestation Request to the Issuer. The request MUST contain the Credential Proof of Possession JWT, signed with the private key related to the public key contained within the Credential. +Below a non-normative example representing a Status Assertion Request array with a +single Status Assertion Request object in JWT format. .. code:: POST /status HTTP/1.1 - Host: pid-provider.example.org - Content-Type: application/x-www-form-urlencoded + Host: issuer.example.org + Content-Type: application/json - credential_pop=$CredentialPoPJWT + { + "status_assertion_requests" : ["${base64url(json({typ: (some pop for status-assertion)+jwt, ...}))}.payload.signature", ... ] + } +The Status Assertion HTTP request can be sent to a single Credential Issuer regarding multiple Digital Credentials, and MUST contain a JSON object with the member `status_assertion_requests`. +The `status_assertion_requests` MUST be set with an array of strings, where each string within the array represents a Digital Credential Status Assertion Request object. A non-normative example of Credential Proof of Possession is provided :ref:`in the previous section `. -**Step 2 (PoP verification)**: The Issuer verifies the signature of the PoP JWTs using the public key that was attested in the Digital Credential, which is proof that the Wallet Instance owns the private keys associated with the Digital Credential. Therefore the Wallet Instance is entitled to request its Status Attestation. +**Step 2 (PoP verification)**: The Credential Issuer that receives the Status Assertion Request object MUST validate that the Wallet Instance making the request is authorized to request Status Assertions. Therefore the following requirements MUST be satisfied: + +- The Credential Issuer MUST verify the compliance of all elements in the `status_assertion_requests` object using the confirmation method contained within the Digital Credential where the Status Assertion Request object is referred to; -**Step 3 (Check for validity)**: The Issuer checks that the User's attributes are not updated by the Authentic Source or that the latter has not revoked them. The technical mechanisms for obtaining this information are out-of-scope of this technical implementation profile. +- The Credential Issuer MUST verify that it is the legitimate Issuer of the Digital Credential to which each Status Assertion Request object refers. +**Step 3 (Check for validity)**: The Credential Issuer checks that the User's attributes are not updated by the Authentic Source or that the latter has not revoked them. The technical mechanisms for obtaining this information are out-of-scope of this technical implementation profile. -**Step 4 (Status Attestation Creation)**: The Issuer creates the corresponding Status Attestation. A non-normative example of a Status Attestation is given below. +**Step 4 (Status Assertion Creation)**: The Credential Issuer creates the corresponding Status Assertion. A non-normative example of a Status Assertion is given below. .. code:: { "alg": "ES256", - "typ": "status-attestation+jwt, + "typ": "status-assertion+jwt, "kid": $ISSUER-JWKID } . @@ -331,19 +346,30 @@ A non-normative example of Credential Proof of Possession is provided :ref:`in t } } -**Step 4 (Status Attestation Response)**: The Issuer then returns the Status Attestation to the Wallet Instance, as in the following non-normative example. +**Step 4 (Status Assertion Response)**: The response MUST include a JSON object with a member named `status_assertion_responses`, which contains the Status Assertions and or the Status Assertion Errors related to the request made by the Wallet Instance, as in the following non-normative example. .. code:: - HTTP/1.1 201 Created - Content-Type: application/json - - { - "status_attestation": "eyJhbGciOiJFUzI1NiIsInR5cCI6IndhbGxldC1...", - } + HTTP/1.1 200 Created + Content-Type: application/json + + { + "status_assertion_responses": ["${base64url(json({typ: status-assertion+jwt, ...}))}.payload.signature", ... ] + } +The member `status_assertion_responses` MUST be an array of strings, where each of them represent a Status Assertion Response object, as defined in [the section Status Assertion](#status-assertion) or a Status Assertion Error object, as defined in [the section Status Error](#status-assertion-error). + +For each entry in the `status_assertion_responses` array, the following requirements are met: + +- Each element in the array MUST match the corresponding element in the request array at +the same position index to which it is related, eg: _[requestAboutA, requestAboutB]_ produces _[responseAboutA, responseErrorAboutB]_. + +- Each element MUST contain the error or the status of the assertion using the `typ` member. +set to "status-assertion+{jwt,cwt}" or "status-assertion-error+{jwt,cwt}", depending by the object type. +- The corresponding entry in the response MUST be of the same data format as requested. For example, +if the entry in the request is "jwt", then the entry at the same position in the response MUST also be "jwt". -Status Attestation HTTP Request +Status Assertion HTTP Request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The requests to the *Credential status endpoint* of the Issuers MUST be HTTP with method POST, using the same mandatory parameters as in the :ref:`Table of Credential Request parameters `. These MUST be encoded in ``application/x-www-form-urlencoded`` format. @@ -359,12 +385,12 @@ The requests to the *Credential status endpoint* of the Issuers MUST be HTTP wit - It MUST contain a signed JWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession ` for more details. - `[OAuth Status Attestation draft 01] `_ -The *typ* value in the *credential_pop* JWT MUST be set to **status-attestation+jwt** +The *typ* value in the *credential_pop* JWT MUST be set to **status-assertion+jwt** -The *Credential status endpoint* MUST be provided by the Issuers within their Metadata. The Issuers MUST include in the issued Digital Credentials the object *status* with the JSON member *status_attestation* set to a JSON Object containing the *credential_hash_alg* claim. It MUST contain the algorithm used for hashing the Digital Credential. Among the hash algorithms, the value ``sha-256`` is RECOMMENDED . +The *Credential status endpoint* MUST be provided by the Issuers within their Metadata. The Issuers MUST include in the issued Digital Credentials the object *status* with the JSON member *status_assertion* set to a JSON Object containing the *credential_hash_alg* claim. It MUST contain the algorithm used for hashing the Digital Credential. Among the hash algorithms, the value ``sha-256`` is RECOMMENDED . -Status Attestation HTTP Response +Status Assertion HTTP Response ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The *Credential status endpoint* MUST return a HTTP response with status code *201 Created* if the Credential is valid at the time of the request. The responses MUST be encoded in ``application/json`` format. It MUST contain the following mandatory claims. @@ -377,8 +403,8 @@ The *Credential status endpoint* MUST return a HTTP response with status code *2 * - **Claim** - **Description** - **Reference** - * - **status_attestation** - - It MUST contain the Status Attestation as a signed JWT. + * - **status_assertion** + - It MUST contain the Status Assertion as a signed JWT. - `[OAuth Status Attestation draft 01] `_. The following HTTP Status Codes MUST be supported: @@ -391,8 +417,8 @@ The following HTTP Status Codes MUST be supported: - **Body** - **Description** * - *201 Created* - - Status Attestation response - - The Status Attestation has been successfully created and it has been returned. + - Status Assertion response + - The Status Assertion has been successfully created and it has been returned. * - *400 Bad Request* - Error code and description - The issuer cannot fulfill the request because of invalid parameters. @@ -441,10 +467,10 @@ Below a non-normative example of an HTTP Response with an error. .. _sec_revocation_nra_presentation: -Status Attestation Presentation to the Verifiers +Status Assertion Presentation to the Verifiers ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -During the presentation phase, a Verifier MAY request the Wallet Instance to provide a Non-Revocation Attestation along with the requested Credential. If a Verifier requests a Status Attestation for a requested Digital Credential, the Wallet Instance MUST provide the Status Attestations in the *vp_token* JSON array. If the Status Attestation is requested by the Verifier and the Wallet Instance is not able to provide it or it is expired or it is issued far back in time, the Verifier MAY decide to accept or reject the Credential according to its security policy. +During the presentation phase, a Verifier MAY request the Wallet Instance to provide a Non-Revocation Assertion along with the requested Credential. If a Verifier requests a Status Assertion for a requested Digital Credential, the Wallet Instance MUST provide the Status Assertions in the *vp_token* JSON array. If the Status Assertion is requested by the Verifier and the Wallet Instance is not able to provide it or it is expired or it is issued far back in time, the Verifier MAY decide to accept or reject the Credential according to its security policy. Law-Enforcement Authorities or Third Parties authorized by national law, MAY require deferred non-revocation status verification but the definition of these protocols is currently out-of-scope for this technical implementation profile. @@ -465,7 +491,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - **Description** - **Reference** * - **typ** - - In case of revocation request it MUST be set to ``revocation-request+jwt``. In case of Status Attestation request it MUST be set to ``status-attestation-request+jwt``, according to `[OAuth Status Attestation draft 01] `_. + - In case of revocation request it MUST be set to ``revocation-request+jwt``. In case of Status Assertion request it MUST be set to ``status-assertion-request+jwt``, according to `[OAuth Status Attestation draft 01] `_. - :rfc:`7516#section-4.1.1`. * - **alg** - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. @@ -482,7 +508,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - **Description** - **Reference** * - **iss** - - Thumbprint of the JWK in the ``cnf`` parameter of the Wallet Attestation. + - Thumbprint of the JWK in the ``cnf`` parameter of the Wallet Assertion. - :rfc:`9126` and :rfc:`7519`. * - **aud** - It MUST be set to the Issuer endpoint at which the JWT is used. @@ -505,12 +531,12 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST -Status Attestation +Status Assertion ------------------ -The Status Attestation MUST contain the following claims. +When the JWT or CWT format are used, the Status Assertion MUST contain the following claims. -.. _table_non_revocation_attestation_header: +.. _table_non_revocation_assertion_header: .. list-table:: :widths: 20 60 20 :header-rows: 1 @@ -522,13 +548,13 @@ The Status Attestation MUST contain the following claims. - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms in Section :ref:`Cryptographic Algorithms ` and MUST NOT be set to ``none`` or to a symmetric algorithm (MAC) identifier. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - - It MUST be set to `status-attestation+jwt`. + - It MUST be set to `status-assertion-request+jwt` when JWT format is used. It MUST be set to `status-assertion-request+cwt` when CWT format is used. - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_.. * - **kid** - Unique identifier of the Issuer ``jwk`` as base64url-encoded JWK Thumbprint value. - :rfc:`7638#section_3`. -.. _table_non_revocation_attestation_claim: +.. _table_non_revocation_assertion_claim: .. list-table:: :widths: 20 60 20 :header-rows: 1 @@ -546,10 +572,10 @@ The Status Attestation MUST contain the following claims. - UNIX Timestamp with the expiry time of the JWT. - :rfc:`9126` and :rfc:`7519`. * - **credential_hash** - - Hash value of the Credential the Status Attestation is bound to. + - Hash value of the Credential the Status Assertion is bound to. - `[OAuth Status Attestation draft 01] `_. * - **credential_hash_alg** - - The Algorithm used for hashing the Credential to which the Status Attestation is bound. The value SHOULD be set to ``S256``. + - The Algorithm used for hashing the Credential to which the Status Assertion is bound. The value SHOULD be set to ``S256``. - `[OAuth Status Attestation draft 01] `_. * - **cnf** - JSON object containing the proof-of-possession key materials. The ``cnf`` jwk value MUST match with the one provided within the related Credential. From eca844c6dee95ed4e6d1863ec2e89acfbc4b488e Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Wed, 5 Jun 2024 12:00:07 +0200 Subject: [PATCH 002/105] status assertion response completed --- docs/en/revocation-lists.rst | 101 +++++++++++++++++++++-------------- 1 file changed, 62 insertions(+), 39 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index adf5abe0a..29da90676 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -325,26 +325,26 @@ A non-normative example of Credential Proof of Possession is provided :ref:`in t **Step 3 (Check for validity)**: The Credential Issuer checks that the User's attributes are not updated by the Authentic Source or that the latter has not revoked them. The technical mechanisms for obtaining this information are out-of-scope of this technical implementation profile. -**Step 4 (Status Assertion Creation)**: The Credential Issuer creates the corresponding Status Assertion. A non-normative example of a Status Assertion is given below. +**Step 4 (Status Assertion Creation)**: The Credential Issuer creates the corresponding Status Assertion. When a Status Assertion is requested to a Credential Issuer, the Issuer checks the status of the Digital Credential and creates a Status Assertion bound to it. If the Digital Credential is valid, the Credential Issuer creates a new Status Assertion, which a non-normative example is given below where the format is JWT. .. code:: { - "alg": "ES256", - "typ": "status-assertion+jwt, - "kid": $ISSUER-JWKID - } - . - { - "iss": "https://pid-provider.example.org", - "iat": 1504699136, - "exp": 1504700136, - "credential_hash": $CREDENTIAL-HASH, - "credential_hash_alg": "sha-256", - "cnf": { - "jwk": $CREDENTIAL-CNF-JWK - } - } + "alg": "ES256", + "typ": "status-assertion+jwt", + "kid": $ISSUER-JWKID + } + . + { + "iss": "https://issuer.example.org", + "iat": 1504699136, + "exp": 1504785536, + "credential_hash": $CREDENTIAL-HASH, + "credential_hash_alg": "sha-256", + "cnf": { + "jwk": {...} + } + } **Step 4 (Status Assertion Response)**: The response MUST include a JSON object with a member named `status_assertion_responses`, which contains the Status Assertions and or the Status Assertion Errors related to the request made by the Wallet Instance, as in the following non-normative example. @@ -360,11 +360,9 @@ The member `status_assertion_responses` MUST be an array of strings, where each For each entry in the `status_assertion_responses` array, the following requirements are met: -- Each element in the array MUST match the corresponding element in the request array at -the same position index to which it is related, eg: _[requestAboutA, requestAboutB]_ produces _[responseAboutA, responseErrorAboutB]_. +- Each element in the array MUST match the corresponding element in the request array at the same position index to which it is related, eg: _[requestAboutA, requestAboutB]_ produces _[responseAboutA, responseErrorAboutB]_. -- Each element MUST contain the error or the status of the assertion using the `typ` member. -set to "status-assertion+{jwt,cwt}" or "status-assertion-error+{jwt,cwt}", depending by the object type. +- Each element MUST contain the error or the status of the assertion using the `typ` member set to "status-assertion+{jwt,cwt}" or "status-assertion-error+{jwt,cwt}", depending by the object type. - The corresponding entry in the response MUST be of the same data format as requested. For example, if the entry in the request is "jwt", then the entry at the same position in the response MUST also be "jwt". @@ -372,7 +370,7 @@ if the entry in the request is "jwt", then the entry at the same position in the Status Assertion HTTP Request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The requests to the *Credential status endpoint* of the Issuers MUST be HTTP with method POST, using the same mandatory parameters as in the :ref:`Table of Credential Request parameters `. These MUST be encoded in ``application/x-www-form-urlencoded`` format. +The requests to the *Credential status endpoint* of the Issuers MUST be HTTP with method POST, using the same mandatory parameters as in the :ref:`Table of Credential Request parameters `. These MUST be encoded in ``application/json`` format. .. list-table:: :widths: 20 60 20 @@ -387,13 +385,21 @@ The requests to the *Credential status endpoint* of the Issuers MUST be HTTP wit The *typ* value in the *credential_pop* JWT MUST be set to **status-assertion+jwt** -The *Credential status endpoint* MUST be provided by the Issuers within their Metadata. The Issuers MUST include in the issued Digital Credentials the object *status* with the JSON member *status_assertion* set to a JSON Object containing the *credential_hash_alg* claim. It MUST contain the algorithm used for hashing the Digital Credential. Among the hash algorithms, the value ``sha-256`` is RECOMMENDED . +The *Credential status endpoint* MUST be provided by the Credential Issuers within their Metadata. The Credential Issuers MUST include in the issued Digital Credentials the object *status* with the JSON member *status_assertion* set to a JSON Object containing the *credential_hash_alg* claim. It MUST contain the algorithm used for hashing the Digital Credential. Among the hash algorithms, the value ``sha-256`` is RECOMMENDED . Status Assertion HTTP Response ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The *Credential status endpoint* MUST return a HTTP response with status code *201 Created* if the Credential is valid at the time of the request. The responses MUST be encoded in ``application/json`` format. It MUST contain the following mandatory claims. +The *the Credential Issuer* MUST return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Status Assertion Error object. The status code 200 MUST be returned if the Status Assertion is requested for a valid, non-existent, expired, revoked or invalid Digital Credential. + +The response MUST: + +- include a JSON object with a member named `status_assertion_responses`; + +- be encoded in ``application/json`` format. + +It MUST contain the following mandatory claims. .. _table_http_response_claim: .. list-table:: @@ -403,10 +409,11 @@ The *Credential status endpoint* MUST return a HTTP response with status code *2 * - **Claim** - **Description** - **Reference** - * - **status_assertion** - - It MUST contain the Status Assertion as a signed JWT. + * - **status_assertion_responses** + - the Status Assertions and or the Status Assertion Errors related to the request made by the Wallet Instance. - `[OAuth Status Attestation draft 01] `_. + The following HTTP Status Codes MUST be supported: .. list-table:: @@ -416,7 +423,7 @@ The following HTTP Status Codes MUST be supported: * - **Status Code** - **Body** - **Description** - * - *201 Created* + * - *200 Created* - Status Assertion response - The Status Assertion has been successfully created and it has been returned. * - *400 Bad Request* @@ -432,13 +439,13 @@ The following HTTP Status Codes MUST be supported: - - The Issuer is temporary unavailable. (:rfc:`6749#section-5.2`). -For HTTP error responses that involve a body, the body MUST be encoded in ``application/json`` format and MUST contain the following parameters: +The Status Assertion Error object MUST contain the following parameters: - - *error*. The error code, as registerd in the table below. + - *error*. The error code, as registerd in the table below; - *error_description*. Text in human-readable form providing further details to clarify the nature of the error encountered. -Error codes are meant to provide additional information about the failure so that the User can be informed and take the appropriate action. -The following Error Codes MUST be supported: +Errors are meant to provide additional information about the failure so that the User can be informed and take the appropriate action. +The `error` parameter for the Status Assertion Error object MUST be set with one of the values defined in the table below, in addition to the values specified in :rfc:`6749#section-5.2`: .. list-table:: :widths: 20 80 @@ -450,20 +457,36 @@ The following Error Codes MUST be supported: - The request is not valid due to the lack or incorrectness of one or more parameters. (:rfc:`6749#section-5.2`). * - ``credential_revoked`` - The Digital Credential is revoked. The reason of revocation MUST be provided in the *error_description* field. - * - ``credential_updated`` - - One or more attributes contained in the Digital Credential are changed. The *error_description* field MUST contain a list of updated attributes. - -Below a non-normative example of an HTTP Response with an error. + * - ``credential_updated`` + - One or more information contained in the Digital Credential are changed. The `error_description` field SHOULD contain a human-readable text describing the general parameters updated without specifying each one. + * - ``credential_invalid`` + - The Digital Credential is invalid. The `error_description` field SHOULD contain the reason of invalidation. + * - ``invalid_request_signature`` + - The Status Assertion Request signature validation has failed. This error type is used when the proof of possession of the Digital Credential is found not valid within the Status Assertion Request. + * - ``credential_not_found`` + - The `credential_hash` value provided in the Status Assertion Request doesn't match with any active Digital Credential. + * - ``unsupported_hash_alg`` + - The hash algorithm set in `credential_hash_alg` is not supported. + +Below a non-normative example of a Status Assertion Error object in JWT format, with the headers and payload represented in JSON and without applying the signature. .. code:: - HTTP/1.1 400 Bad Request - Content-Type: application/json;charset=UTF-8 - { - "error": "invalid_request" - "error_description": "The signature of credential_pop JWT is not valid" + "alg": "ES256", + "typ": "status-assertion-error+jwt", + "kid": "Issuer-JWK-KID" } + . + { + "iss": "https://issuer.example.org", + "jti": "6f204f7e-e453-4dfd-814e-9d155319408c" + "credential_hash": $CREDENTIAL-HASH, + "credential_hash_alg": "sha-256", + "error": "credential_revoked", + "error_description": "Credential is revoked." + } + .. _sec_revocation_nra_presentation: From 86fc5879f97fc8b5512978fc1a03dca2bcf64a07 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Wed, 5 Jun 2024 12:07:21 +0200 Subject: [PATCH 003/105] Editorial change --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 29da90676..e39e310b4 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -451,7 +451,7 @@ The `error` parameter for the Status Assertion Error object MUST be set with one :widths: 20 80 :header-rows: 1 - * - **Error Code** + * - **Error** - **Description** * - ``invalid_request`` - The request is not valid due to the lack or incorrectness of one or more parameters. (:rfc:`6749#section-5.2`). From c59fd028716ef40cbefe6144aab3bc63a53f835d Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 6 Jun 2024 06:53:31 +0200 Subject: [PATCH 004/105] Revocation flow completed --- docs/en/revocation-lists.rst | 134 ++++++++++++++++++++++------------- 1 file changed, 84 insertions(+), 50 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index e39e310b4..b092a795e 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -132,26 +132,30 @@ A Wallet Instance MUST request the revocation of a Digital Credential as defined Wallet Instance Initiated Revocation Flow -**Step 1 (Credential Revocation Request)**: The Wallet Instance initiates the process by creating a Credential Revocation Request. This request includes a Digital Credential Proof of Possession as a JWT. It MUST be signed with the private key related to the public key contained within the Credential (such as the Issuer Signed JWT in the case of SD-JWT, or the MSO in the case of Mdoc CBOR). Then, the Wallet Instance sends the request to the Issuer as in the following non-normative example. +**Step 1 (Credential Revocation Request)**: The Wallet Instance initiates the process by creating a Credential Revocation Request. This request can be sent to a single Credential Issuer, regarding multiple Digital Credentials, and MUST contain a JSON object with the member `revocation_assertion_requests`. + +The `revocation_assertion_requests` MUST be set with an array of strings, where each string within the array represents a Credential Revocation Request object. + +It MUST be signed with the private key related to the public key contained within the Credential (such as the Issuer Signed JWT in the case of SD-JWT, or the MSO in the case of Mdoc CBOR). Then, the Wallet Instance sends the request to the Issuer as in the following non-normative example representing a Revocation Assertion Request array. .. _credential_revocation_request_ex: .. code-block:: POST /revoke HTTP/1.1 Host: pid-provider.example.org - Content-Type: application/x-www-form-urlencoded + Content-Type: application/json - credential_pop=$CredentialPoPJWT + revocation_assertion_requests : ["${base64url(json({typ: (some pop for revocation-assertion)+jwt, ...}))}.payload.signature", ... ] -Below, is given a non-normative example of a Credential PoP with decoded JWT headers and payload and without signature for better readability: +Below, is given a non-normative example of a single Revocation Assertion Request object with decoded JWT headers and payload and without signature for better readability: .. _credential_pop_jwt_ex: .. code-block:: { "alg": "ES256", - "typ": "status-assertion-request+jwt", + "typ": "revocation-assertion-request+jwt", "kid": $CREDENTIAL-CNF-JWKID } . @@ -165,23 +169,26 @@ Below, is given a non-normative example of a Credential PoP with decoded JWT hea "credential_hash_alg": "sha-256", } -**Step 2 (PoP verification)**: The Issuer verifies the signature of the PoP JWTs using the public key that was attested in the issued Digital Credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Digital Credential, and therefore is entitled to request its revocation. +**Step 2 (PoP verification)**: The Credential Issuer verifies the signature of the PoP using the the confirmation method that was attested in the issued Digital Credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Digital Credential, and therefore is entitled to request its revocation. -**Step 3 (Credential Revocation)**: The Issuer revokes the Credential provided in the Credential PoP JWT. After the revocation, the Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. +**Step 3 (Credential Revocation)**: The Credential Issuer revokes the Credential provided in the revocation_assertion_requests object. After the revocation, the Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. **Step 4 (Credential Revocation Response)**: The Issuer sends a response back to the Wallet Instance with the result of the revocation request. .. code:: .. code-block:: http + HTTP/1.1 200 Created + Content-Type: application/json - HTTP/1.1 204 No Content - - + { + "revocation_assertion_responses": ["${base64url(json({typ: revocation_assertion+jwt, ...}))}.payload.signature", ... ] + } + Credential Revocation HTTP Request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The requests to the *Issuer Revocation endpoint* MUST be HTTP with method POST, using the mandatory parameters listed below within the HTTP request message body. These MUST be encoded in ``application/x-www-form-urlencoded`` format. +The requests to the *Issuer Revocation endpoint* MUST be HTTP with method POST, using the mandatory parameters listed below within the HTTP request message body. These MUST be encoded in ``application/JSON`` format. .. _table_revocation_request_params: .. list-table:: @@ -191,8 +198,8 @@ The requests to the *Issuer Revocation endpoint* MUST be HTTP with method POST, * - **Claim** - **Description** - **Reference** - * - **credential_pop** - - It MUST contain a JWT proof of possession of the cryptographic key the Credential to be revoked shall be bound to. See Section :ref:`Credential Proof of Possession ` for more details. + * - **revocation_assertion_requests** + - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession ` for more details. - `[OAuth Status Assertion draft 01] `_ The Revocation Endpoint MUST be provided by the Issuer within its Metadata. @@ -201,8 +208,15 @@ The Revocation Endpoint MUST be provided by the Issuer within its Metadata. Credential Revocation HTTP Response ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In case of successful revocation, the Issuer MUST return an HTTP Response with status code *204 No Content*. -Otherwise, an HTTP error response MUST be provided by the Issuer using status codes according to the table below. +The *Credential Issuer* SOULD return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Revocation Assertion Error object. The status code 200 MUST be returned if the Revocation Assertion is requested for a valid, non-existent, expired, already revoked or invalid Digital Credential. + +The response MUST: + +- include a JSON object with a member named `revocation_assertion_responses`; + +- be encoded in ``application/json`` format. + +Otherwise, an HTTP error response MUST be provided by the Credential Issuer using status codes according to the table below. The following HTTP Status Codes MUST be supported: @@ -213,15 +227,12 @@ The following HTTP Status Codes MUST be supported: * - **Status Code** - **Body** - **Description** - * - *204 No Content* - - - - The Digital Credential has been successfully revoked. + * - *200 Created* + - Revocation Assertion Response + - The Revocation Assertion Response has been successfully created. * - *400 Bad Request* - Error code and description - The issuer cannot fulfill the request because of invalid parameters. - * - *404 Not Found* - - - - The Digital Credential to be revoked can not be found by the Issuer. * - *500 Internal Server Error* - - The Issuer encountered an internal problem. (:rfc:`6749#section-5.2`). @@ -229,13 +240,27 @@ The following HTTP Status Codes MUST be supported: - - The Issuer is temporary unavailable. (:rfc:`6749#section-5.2`). -For HTTP error responses that involve a body, the body MUST be encoded in ``application/json`` format and MUST contain the following parameters: +The ``revocation_assertion_responses`` object MUST contain the following mandatory claims. + +.. _table_http_response_claim: +.. list-table:: + :widths: 20 60 20 + :header-rows: 1 + + * - **Claim** + - **Description** + - **Reference** + * - **revocation_assertion_responses** + - the Revocation Assertions and or the Revocation Assertion Errors related to the request made by the Wallet Instance. + - `[OAuth Status Attestation draft 01] `_. + +The Revocation Assertion Error object MUST contain the following parameters: - - *error*. The error code, as registerd in the table below. + - *error*. The error code, as registerd in the table below; - *error_description*. Text in human-readable form providing further details to clarify the nature of the error encountered. -Error codes are meant to provide additional information about the failure so that the User can be informed and take the appropriate action. -The following Error Codes MUST be supported: +Errors are meant to provide additional information about the failure so that the User can be informed and take the appropriate action. +The `error` parameter for the Revocation Assertion Error object MUST be set with one of the values defined in the table below, in addition to the values specified in :rfc:`6749#section-5.2`: .. list-table:: :widths: 20 80 @@ -245,20 +270,37 @@ The following Error Codes MUST be supported: - **Description** * - ``invalid_request`` - The request is not valid due to the lack or incorrectness of one or more parameters. (:rfc:`6749#section-5.2`). + * - ``credential_already_revoked`` + - The Digital Credential is already revoked. + * - ``credential_updated`` + - One or more information contained in the Digital Credential are changed. The `error_description` field SHOULD contain a human-readable text describing the general parameters updated without specifying each one. + * - ``credential_invalid`` + - The Digital Credential is invalid. The `error_description` field SHOULD contain the reason of invalidation. + * - ``invalid_request_signature`` + - The Revocation Assertion Request signature validation has failed. This error type is used when the proof of possession of the Digital Credential is found not valid within the Revocation Assertion Request. + * - ``credential_not_found`` + - The `credential_hash` value provided in the Revocation Assertion Request doesn't match with any active Digital Credential. + * - ``unsupported_hash_alg`` + - The hash algorithm set in `credential_hash_alg` is not supported. - -Below a non-normative example of an HTTP Response with an error. +Below a non-normative example of a Revocation Assertion Error object in JWT format, with the headers and payload represented in JSON and without applying the signature. .. code:: - HTTP/1.1 400 Bad Request - Content-Type: application/json;charset=UTF-8 - { - "error": "invalid_request" - "error_description": "The signature of credential_pop JWT is not valid" + "alg": "ES256", + "typ": "revocation-assertion-error+jwt", + "kid": "Issuer-JWK-KID" + } + . + { + "iss": "https://issuer.example.org", + "jti": "6f204f7e-e453-4dfd-814e-9d155319408c" + "credential_hash": $CREDENTIAL-HASH, + "credential_hash_alg": "sha-256", + "error": "unsupported_hash_alg", + "error_description": "The hash algorithm set is not supported" } - Status Assertion Flows @@ -300,8 +342,7 @@ The following diagram shows how the Wallet Instance requests a Status Assertion - The Status Assertion Request object MUST be signed with the private key corresponding to the confirmation claim assigned by the Issuer and contained within the Digital Credential. -Below a non-normative example representing a Status Assertion Request array with a -single Status Assertion Request object in JWT format. +Below a non-normative example representing a Status Assertion Request array with a single Status Assertion Request object in JWT format. .. code:: @@ -356,16 +397,9 @@ A non-normative example of Credential Proof of Possession is provided :ref:`in t { "status_assertion_responses": ["${base64url(json({typ: status-assertion+jwt, ...}))}.payload.signature", ... ] } -The member `status_assertion_responses` MUST be an array of strings, where each of them represent a Status Assertion Response object, as defined in [the section Status Assertion](#status-assertion) or a Status Assertion Error object, as defined in [the section Status Error](#status-assertion-error). -For each entry in the `status_assertion_responses` array, the following requirements are met: +The member `status_assertion_responses` MUST be an array of strings, where each of them represent a Status Assertion Response object as defined in `[OAuth Status Attestation draft 01] `_. -- Each element in the array MUST match the corresponding element in the request array at the same position index to which it is related, eg: _[requestAboutA, requestAboutB]_ produces _[responseAboutA, responseErrorAboutB]_. - -- Each element MUST contain the error or the status of the assertion using the `typ` member set to "status-assertion+{jwt,cwt}" or "status-assertion-error+{jwt,cwt}", depending by the object type. - -- The corresponding entry in the response MUST be of the same data format as requested. For example, -if the entry in the request is "jwt", then the entry at the same position in the response MUST also be "jwt". Status Assertion HTTP Request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -379,19 +413,19 @@ The requests to the *Credential status endpoint* of the Issuers MUST be HTTP wit * - **Claim** - **Description** - **Reference** - * - **credential_pop** - - It MUST contain a signed JWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession ` for more details. + * - **status_assertion_requests** + - It MUST be an array of strings, where each of them represent a Status Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession ` for more details. - `[OAuth Status Attestation draft 01] `_ The *typ* value in the *credential_pop* JWT MUST be set to **status-assertion+jwt** -The *Credential status endpoint* MUST be provided by the Credential Issuers within their Metadata. The Credential Issuers MUST include in the issued Digital Credentials the object *status* with the JSON member *status_assertion* set to a JSON Object containing the *credential_hash_alg* claim. It MUST contain the algorithm used for hashing the Digital Credential. Among the hash algorithms, the value ``sha-256`` is RECOMMENDED . +The *Credential status endpoint* MUST be provided by the Credential Issuers within their Metadata. The Credential Issuers MUST include in the issued Digital Credentials the object *status_assertion_requests* with the JSON member *status_assertion* set to a JSON Object containing the *credential_hash_alg* claim. It MUST contain the algorithm used for hashing the Digital Credential. Among the hash algorithms, the value ``sha-256`` is RECOMMENDED . Status Assertion HTTP Response ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The *the Credential Issuer* MUST return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Status Assertion Error object. The status code 200 MUST be returned if the Status Assertion is requested for a valid, non-existent, expired, revoked or invalid Digital Credential. +The *Credential Issuer* MUST return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Status Assertion Error object. The status code 200 MUST be returned if the Status Assertion is requested for a valid, non-existent, expired, revoked or invalid Digital Credential. The response MUST: @@ -424,8 +458,8 @@ The following HTTP Status Codes MUST be supported: - **Body** - **Description** * - *200 Created* - - Status Assertion response - - The Status Assertion has been successfully created and it has been returned. + - Status Assertion Response + - The Status Assertion Response has been successfully created and it has been returned. * - *400 Bad Request* - Error code and description - The issuer cannot fulfill the request because of invalid parameters. @@ -451,7 +485,7 @@ The `error` parameter for the Status Assertion Error object MUST be set with one :widths: 20 80 :header-rows: 1 - * - **Error** + * - **Error Code** - **Description** * - ``invalid_request`` - The request is not valid due to the lack or incorrectness of one or more parameters. (:rfc:`6749#section-5.2`). From 46453c3b65a2a7986e505d3915d7909b913fd983 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 6 Jun 2024 07:15:43 +0200 Subject: [PATCH 005/105] Editorial review --- docs/en/revocation-lists.rst | 62 ++++++++++++++++++------------------ 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index b092a795e..ddd60615a 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -13,7 +13,7 @@ Furthermore, it provides the technical details that the Verifiers MUST implement The verification of the validity of a Digital Credential is based on the `[OAuth Status Assertion draft 01] `_ specification. -A Status Assertion is a signed document serving as proof of a Digital Credential's current validity status. The Issuer provides these assertions to Holders who can present them to Verifiers together with the corresponding Digital Credentials. +A Status Assertion is a signed document serving as proof of a Digital Credential's current validity status. The Credential Issuer provides these assertions to Holders who can present them to Verifiers together with the corresponding Digital Credentials. The Status Assertions have the following features: @@ -22,7 +22,7 @@ The Status Assertions have the following features: - privacy-preserving, according to the following evidences: 1. the Verifier cannot check over time the validity of a given Digital Credential related to the User; - 2. the Issuers cannot track when and where a Digital Credential is verified; + 2. the Credential Issuers cannot track when and where a Digital Credential is verified; 3. it doesn't reveal any information about the Users or the content of their Digital Credentials. .. _sec_revocation_assumption: @@ -47,12 +47,12 @@ Functional Requirements - MUST be timestamped with its issuance datetime, using a timestamp which is at or after the time of Digital Credential issuance which it refers; - MUST contain the expiration datetime after which both the Status Assertion and the Digital Credential it refers MUST NOT be considered valid anymore. The expiration datetime MUST be superior to the Status Assertion issuance datetime and it MUST end before the expiration datetime of the Digital Credential; - MUST have a validity period not greater than 24 hours; -- MUST provide the proof about the non-revocation of the Digital Credential which is related to and MUST be validated using the cryptographic signature of the Issuer; +- MUST provide the proof about the non-revocation of the Digital Credential which is related to and MUST be validated using the cryptographic signature of the Credential Issuer; - MUST NOT reveal any information about the Relying Party, the User's device or the User's data contained in the Digital Credential the assertion is related to; - MUST be non-repudiable even beyond its expiration time and even in the case of cryptographic keys rotation. -**The Issuer MUST:** +**The Credential Issuer MUST:** - ensure that the data contained in a Digital Credential is kept up to date, including the status of validity of the data from the Authentic Source; - revoke a Digital Credential when the following circumstances occur: @@ -79,7 +79,7 @@ Functional Requirements **The Authentic Sources MUST:** - provide web services for the providing of updated User data and the validity status; -- store in local databases only the minimum information required to provide the Issuer with the User data or a change in the validity status. +- store in local databases only the minimum information required to provide the Credential Issuer with the User data or a change in the validity status. Revocation Use Cases @@ -98,8 +98,8 @@ Credential Revocation Flows can start under different scenarios, such as: - The User notifies an Authentic Source that one or more attributes are changed (e.g. the current resident address): in this case the Credentials SHALL be revoked, as they are no longer valid due to the change in attributes. - Users who lose access to their Wallet Instance (e.g., due to theft or loss of the device) can request the Credential Issuer to revoke their Credentials or ask the Wallet Provider to revoke the Wallet Instance. If the Wallet Provider is authorized by the User and is aware of the types of Credentials and their issuers stored in the Wallet, it can then initiate the revocation of all Digital Credentials contained within the Wallet Instance on behalf of the User. - The Law-Enforcing Authorities, for the fulfillment of their functions and any other judicial reasons, may request the Authentic Source to revoke entitlements, licenses, certificates, identification documents, etc., which in turn leads to the revocation of any linked Credentials. - - The Authentic Sources that for any administrative reasons update one or more attributes of a User, shall inform the Issuer of related Credentials. - - The Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys, death of the User, etc.), can decide to revoke the Credentials. + - The Authentic Sources that for any administrative reasons update one or more attributes of a User, shall inform the Credential Issuer of related Credentials. + - The Credential Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys, death of the User, etc.), can decide to revoke the Credentials. The revocation scenarios involve two main flows: @@ -114,7 +114,7 @@ Revocation Flows ---------------- Depending on the different scenarios that may involve the revocation of a Digital Credential, different processes and technical flows may be implemented, according to national laws or Regulations of specific domains. -The subsequent sections define the protocol interface between the Wallet Instances and the Issuers during the revocation request. The communication between the Issuers and other Entities is out-of-scope of this technical implementation profile. +The subsequent sections define the protocol interface between the Wallet Instances and the Credential Issuers during the revocation request. The communication between the Credential Issuers and other Entities is out-of-scope of this technical implementation profile. .. _sec_revocation_wi_initiated_flow: @@ -136,7 +136,7 @@ A Wallet Instance MUST request the revocation of a Digital Credential as defined The `revocation_assertion_requests` MUST be set with an array of strings, where each string within the array represents a Credential Revocation Request object. -It MUST be signed with the private key related to the public key contained within the Credential (such as the Issuer Signed JWT in the case of SD-JWT, or the MSO in the case of Mdoc CBOR). Then, the Wallet Instance sends the request to the Issuer as in the following non-normative example representing a Revocation Assertion Request array. +It MUST be signed with the private key related to the public key contained within the Credential (such as the Credential Issuer Signed JWT in the case of SD-JWT, or the MSO in the case of Mdoc CBOR). Then, the Wallet Instance sends the request to the Credential Issuer as in the following non-normative example representing a Revocation Assertion Request array. .. _credential_revocation_request_ex: .. code-block:: @@ -171,9 +171,9 @@ Below, is given a non-normative example of a single Revocation Assertion Request **Step 2 (PoP verification)**: The Credential Issuer verifies the signature of the PoP using the the confirmation method that was attested in the issued Digital Credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Digital Credential, and therefore is entitled to request its revocation. -**Step 3 (Credential Revocation)**: The Credential Issuer revokes the Credential provided in the revocation_assertion_requests object. After the revocation, the Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. +**Step 3 (Credential Revocation)**: The Credential Issuer revokes the Credential provided in the revocation_assertion_requests object. After the revocation, the Credential Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. -**Step 4 (Credential Revocation Response)**: The Issuer sends a response back to the Wallet Instance with the result of the revocation request. +**Step 4 (Credential Revocation Response)**: The Credential Issuer sends a response back to the Wallet Instance with the result of the revocation request. .. code:: @@ -188,7 +188,7 @@ Below, is given a non-normative example of a single Revocation Assertion Request Credential Revocation HTTP Request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The requests to the *Issuer Revocation endpoint* MUST be HTTP with method POST, using the mandatory parameters listed below within the HTTP request message body. These MUST be encoded in ``application/JSON`` format. +The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with method POST, using the mandatory parameters listed below within the HTTP request message body. These MUST be encoded in ``application/JSON`` format. .. _table_revocation_request_params: .. list-table:: @@ -202,13 +202,13 @@ The requests to the *Issuer Revocation endpoint* MUST be HTTP with method POST, - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession ` for more details. - `[OAuth Status Assertion draft 01] `_ -The Revocation Endpoint MUST be provided by the Issuer within its Metadata. +The Revocation Endpoint MUST be provided by the Credential Issuer within its Metadata. Credential Revocation HTTP Response ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The *Credential Issuer* SOULD return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Revocation Assertion Error object. The status code 200 MUST be returned if the Revocation Assertion is requested for a valid, non-existent, expired, already revoked or invalid Digital Credential. +The *Credential Issuer* MUST return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Revocation Assertion object. The status code 200 MUST be returned if the Revocation Assertion is requested for a valid, non-existent, expired, already revoked or invalid Digital Credential. The response MUST: @@ -232,13 +232,13 @@ The following HTTP Status Codes MUST be supported: - The Revocation Assertion Response has been successfully created. * - *400 Bad Request* - Error code and description - - The issuer cannot fulfill the request because of invalid parameters. + - The Credential Issuer cannot fulfill the request because of invalid parameters. * - *500 Internal Server Error* - - - The Issuer encountered an internal problem. (:rfc:`6749#section-5.2`). + - The Credential Issuer encountered an internal problem. (:rfc:`6749#section-5.2`). * - *503 Service Unavailable* - - - The Issuer is temporary unavailable. (:rfc:`6749#section-5.2`). + - The Credential Issuer is temporary unavailable. (:rfc:`6749#section-5.2`). The ``revocation_assertion_responses`` object MUST contain the following mandatory claims. @@ -308,7 +308,7 @@ Status Assertion Flows The Status Assertion process is divided into the following phases: - 1. The Status Assertion Request by a Wallet Instance: it involves the Wallet Instance and the Issuer. + 1. The Status Assertion Request by a Wallet Instance: it involves the Wallet Instance and the Credential Issuer. 2. The Status Assertion Presentation to a Verifier: it involves the Wallet Instance and the Verifier. @@ -324,9 +324,9 @@ The Status Assertion process is divided into the following phases: Status Assertion Request by Wallet Instance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The presentation of a Credential to a Verifier may occur long after it has been issued by the Issuer. During this time interval, the Credential can be invalidated for any reason and therefore the Verifier also needs to verify its revocation or suspension status. To address this scenario, the Issuer provides the Wallet Instance with a *Status Assertion*. This Assertion is bound to a Credential so that the Wallet Instance can present it to a Verifier, along with the Credential itself, as proof of non-revocation status of the Credential. +The presentation of a Credential to a Verifier may occur long after it has been issued by the Credential Issuer. During this time interval, the Credential can be invalidated for any reason and therefore the Verifier also needs to verify its revocation or suspension status. To address this scenario, the Credential Issuer provides the Wallet Instance with a *Status Assertion*. This Assertion is bound to a Credential so that the Wallet Instance can present it to a Verifier, along with the Credential itself, as proof of non-revocation status of the Credential. -The following diagram shows how the Wallet Instance requests a Status Assertion to the Issuer. +The following diagram shows how the Wallet Instance requests a Status Assertion to the Credential Issuer. .. _fig_Low-Level-Flow-Status-Assertion: .. figure:: ../../images/Low-Level-Flow-Revocation-Attestation.svg @@ -353,6 +353,7 @@ Below a non-normative example representing a Status Assertion Request array with { "status_assertion_requests" : ["${base64url(json({typ: (some pop for status-assertion)+jwt, ...}))}.payload.signature", ... ] } + The Status Assertion HTTP request can be sent to a single Credential Issuer regarding multiple Digital Credentials, and MUST contain a JSON object with the member `status_assertion_requests`. The `status_assertion_requests` MUST be set with an array of strings, where each string within the array represents a Digital Credential Status Assertion Request object. @@ -366,7 +367,7 @@ A non-normative example of Credential Proof of Possession is provided :ref:`in t **Step 3 (Check for validity)**: The Credential Issuer checks that the User's attributes are not updated by the Authentic Source or that the latter has not revoked them. The technical mechanisms for obtaining this information are out-of-scope of this technical implementation profile. -**Step 4 (Status Assertion Creation)**: The Credential Issuer creates the corresponding Status Assertion. When a Status Assertion is requested to a Credential Issuer, the Issuer checks the status of the Digital Credential and creates a Status Assertion bound to it. If the Digital Credential is valid, the Credential Issuer creates a new Status Assertion, which a non-normative example is given below where the format is JWT. +**Step 4 (Status Assertion Creation)**: The Credential Issuer creates the corresponding Status Assertion. When a Status Assertion is requested to a Credential Issuer, the Credential Issuer checks the status of the Digital Credential and creates a Status Assertion bound to it. If the Digital Credential is valid, the Credential Issuer creates a new Status Assertion, which a non-normative example is given below where the format is JWT. .. code:: @@ -404,7 +405,7 @@ The member `status_assertion_responses` MUST be an array of strings, where each Status Assertion HTTP Request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The requests to the *Credential status endpoint* of the Issuers MUST be HTTP with method POST, using the same mandatory parameters as in the :ref:`Table of Credential Request parameters `. These MUST be encoded in ``application/json`` format. +The requests to the *Credential status endpoint* of the Credential Issuers MUST be HTTP with method POST, using the same mandatory parameters as in the :ref:`Table of Credential Request parameters `. These MUST be encoded in ``application/json`` format. .. list-table:: :widths: 20 60 20 @@ -425,7 +426,7 @@ The *Credential status endpoint* MUST be provided by the Credential Issuers with Status Assertion HTTP Response ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The *Credential Issuer* MUST return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Status Assertion Error object. The status code 200 MUST be returned if the Status Assertion is requested for a valid, non-existent, expired, revoked or invalid Digital Credential. +The *Credential Issuer* MUST return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Status Assertion object. The status code 200 MUST be returned if the Status Assertion is requested for a valid, non-existent, expired, revoked or invalid Digital Credential. The response MUST: @@ -462,16 +463,16 @@ The following HTTP Status Codes MUST be supported: - The Status Assertion Response has been successfully created and it has been returned. * - *400 Bad Request* - Error code and description - - The issuer cannot fulfill the request because of invalid parameters. + - The Credential Issuer cannot fulfill the request because of invalid parameters. * - *404 Not Found* - - - The Digital Credential can not be found by the Issuer. + - The Digital Credential can not be found by the Credential Issuer. * - *500 Internal Server Error* - - - The Issuer encountered an internal problem. (:rfc:`6749#section-5.2`). + - The Credential Issuer encountered an internal problem. (:rfc:`6749#section-5.2`). * - *503 Service Unavailable* - - - The Issuer is temporary unavailable. (:rfc:`6749#section-5.2`). + - The Credential Issuer is temporary unavailable. (:rfc:`6749#section-5.2`). The Status Assertion Error object MUST contain the following parameters: @@ -568,7 +569,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - Thumbprint of the JWK in the ``cnf`` parameter of the Wallet Assertion. - :rfc:`9126` and :rfc:`7519`. * - **aud** - - It MUST be set to the Issuer endpoint at which the JWT is used. + - It MUST be set to the Credential Issuer endpoint at which the JWT is used. - :rfc:`9126` and :rfc:`7519`. * - **exp** - UNIX Timestamp with the expiry time of the JWT. @@ -608,7 +609,7 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - It MUST be set to `status-assertion-request+jwt` when JWT format is used. It MUST be set to `status-assertion-request+cwt` when CWT format is used. - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_.. * - **kid** - - Unique identifier of the Issuer ``jwk`` as base64url-encoded JWK Thumbprint value. + - Unique identifier of the Credential Issuer ``jwk`` as base64url-encoded JWK Thumbprint value. - :rfc:`7638#section_3`. .. _table_non_revocation_assertion_claim: @@ -620,7 +621,7 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - **Description** - **Reference** * - **iss** - - It MUST be set to the identifier of the Issuer. + - It MUST be set to the identifier of the Credential Issuer. - :rfc:`9126` and :rfc:`7519`. * - **iat** - UNIX Timestamp with the time of JWT issuance. @@ -637,4 +638,3 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo * - **cnf** - JSON object containing the proof-of-possession key materials. The ``cnf`` jwk value MUST match with the one provided within the related Credential. - `[RFC7800, Section 3.1] `_. - From 6af17019c70eeeccb252d4e85515c21b9ddf38da Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 6 Jun 2024 09:43:35 +0200 Subject: [PATCH 006/105] Specification tables JSON objects added --- docs/en/revocation-lists.rst | 130 +++++++++++++++++++++++++++++++---- 1 file changed, 116 insertions(+), 14 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index ddd60615a..bd8c9e803 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -254,6 +254,25 @@ The ``revocation_assertion_responses`` object MUST contain the following mandato - the Revocation Assertions and or the Revocation Assertion Errors related to the request made by the Wallet Instance. - `[OAuth Status Attestation draft 01] `_. +The Revocation Assertion object MUST contain the parameter ``msg`` with the value set to ``OK``. +Below a non-normative example of a Revocation Assertion object in JWT format, with the headers and payload represented in JSON and without applying the signature. + +.. code:: + + { + "alg": "ES256", + "typ": "revocation-assertion-error+jwt", + "kid": "Issuer-JWK-KID" + } + . + { + "iss": "https://issuer.example.org", + "jti": "6f204f7e-e453-4dfd-814e-9d155319408c" + "credential_hash": $CREDENTIAL-HASH, + "credential_hash_alg": "sha-256", + "msg": "Revoked" + } + The Revocation Assertion Error object MUST contain the following parameters: - *error*. The error code, as registerd in the table below; @@ -539,43 +558,43 @@ Law-Enforcement Authorities or Third Parties authorized by national law, MAY req Credential Proof of Possession ------------------------------ -The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST contain the parameters (JOSE Header and claims) in the following table. +The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT that MUST contain the parameters (Header and Payload) in the following table. .. list-table:: :widths: 20 60 20 :header-rows: 1 - * - **JOSE header** + * - **Header** - **Description** - **Reference** * - **typ** - - In case of revocation request it MUST be set to ``revocation-request+jwt``. In case of Status Assertion request it MUST be set to ``status-assertion-request+jwt``, according to `[OAuth Status Attestation draft 01] `_. + - In case of revocation request it MUST be set to ``revocation-request+{jwt,cwt}``. In case of Status Assertion request it MUST be set to ``status-assertion-request+{jwt,cwt}``, according to `[OAuth Status Attestation draft 01] `_. - :rfc:`7516#section-4.1.1`. * - **alg** - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. - :rfc:`7516#section-4.1.1`. * - **kid** - - Unique identifier of the ``jwk`` inside the ``cnf`` claim of the Credential to be revoked, as base64url-encoded JWK Thumbprint value. + - Unique identifier of the ``jwk`` or ``COSE_Key`` inside the ``cnf`` claim of the Credential to be revoked, as base64url-encoded JWK Thumbprint value, according to `[OAuth Status Attestation draft 01] `_. - :rfc:`7638#section_3`. .. list-table:: :widths: 20 60 20 :header-rows: 1 - * - **Claim** + * - **Payload** - **Description** - **Reference** * - **iss** - Thumbprint of the JWK in the ``cnf`` parameter of the Wallet Assertion. - :rfc:`9126` and :rfc:`7519`. * - **aud** - - It MUST be set to the Credential Issuer endpoint at which the JWT is used. + - It MUST be set to the Credential Issuer endpoint at which the JWT/CWT is used. - :rfc:`9126` and :rfc:`7519`. * - **exp** - - UNIX Timestamp with the expiry time of the JWT. + - UNIX Timestamp with the expiry time of the JWT/CWT. It MUST be greater than the value set for `iat`. - :rfc:`9126` and :rfc:`7519`. * - **iat** - - UNIX Timestamp with the time of JWT issuance. + - UNIX Timestamp with the time of JWT/CWT issuance. - :rfc:`9126` and :rfc:`7519`. * - **jti** - Unique identifier for the PoP proof JWT. The value SHOULD be set using a *UUID v4* value according to [:rfc:`4122`]. @@ -587,7 +606,45 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - It MUST contain the Algorithm used for hashing the Digital Credential. The value SHOULD be set to `S256`. - `[OAuth Status Attestation draft 01] `_. +Revocation Assertion +------------------ + +When the JWT or CWT format are used, the Revocation Assertion MUST contain the following claims. +.. _table_non_revocation_assertion_header: +.. list-table:: + :widths: 20 60 20 + :header-rows: 1 + + * - **Header** + - **Description** + - **Reference** + * - **alg** + - Algorithm used to verify the cryptographic signature of the Revocation Assertion. Revocation Assertion that do not need to be signed SHOULD set the `alg` value to `none` in according with `[OAuth Status Attestation draft 01] `_. + - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. + * - **typ** + - It MUST be set to `revocation-assertion-respone+jwt` when JWT format is used. It MUST be set to `revocation-assertion-response+cwt` when CWT format is used. + - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_.. + + +.. _table_non_revocation_assertion_claim: +.. list-table:: + :widths: 20 60 20 + :header-rows: 1 + + * - **Payload** + - **Description** + - **Reference** + * - **iss** + - It MUST be set to the identifier of the Credential Issuer. + - :rfc:`9126` and :rfc:`7519`. + * - **jti** + - Unique identifier for the JWT. + - `[RFC7519, Section 4.1.7] `_. + * - **msg** + - Message returned from the Credential Issuer after revocation. It MUST be set with the value "OK". + - This specification. + Status Assertion ------------------ @@ -599,7 +656,7 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo :widths: 20 60 20 :header-rows: 1 - * - **JOSE Header** + * - **Header** - **Description** - **Reference** * - **alg** @@ -617,17 +674,17 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo :widths: 20 60 20 :header-rows: 1 - * - **Claim** + * - **Payload** - **Description** - **Reference** * - **iss** - It MUST be set to the identifier of the Credential Issuer. - :rfc:`9126` and :rfc:`7519`. * - **iat** - - UNIX Timestamp with the time of JWT issuance. + - UNIX Timestamp with the time of JWT/CWT issuance. - :rfc:`9126` and :rfc:`7519`. * - **exp** - - UNIX Timestamp with the expiry time of the JWT. + - UNIX Timestamp with the expiry time of the JWT/CWT. It MUST be greater than the value set for `iat`. - :rfc:`9126` and :rfc:`7519`. * - **credential_hash** - Hash value of the Credential the Status Assertion is bound to. @@ -636,5 +693,50 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - The Algorithm used for hashing the Credential to which the Status Assertion is bound. The value SHOULD be set to ``S256``. - `[OAuth Status Attestation draft 01] `_. * - **cnf** - - JSON object containing the proof-of-possession key materials. The ``cnf`` jwk value MUST match with the one provided within the related Credential. - - `[RFC7800, Section 3.1] `_. + - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT and `Cose_Key` for CWT, MUST match with the one provided within the related Digital + Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. + - `[RFC7800, Section 3.1] `_ and `[RFC8747, Section 3.1] `_. + + +Error Assertion +------------------ + +When the JWT or CWT format are used, the Revocation or Status Assertion Error MUST contain the following claims. + +.. _table_non_revocation_assertion_header: +.. list-table:: + :widths: 20 60 20 + :header-rows: 1 + + * - **Header** + - **Description** + - **Reference** + * - **alg** + - Algorithm used to verify the cryptographic signature of the Assertion Error. Assertion Error that do not need to be signed SHOULD set the `alg` value to `none` in according with `[OAuth Status Attestation draft 01] `_. + - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. + * - **typ** + - It MUST be set to `status-assertion-response+jwt` or `revocation-assertion-response+jwt`when JWT format is used. It MUST be set to `status-assertion-response+cwt` or `revocation-assertion-response+cwt`when CWT format is used. + - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_. + + +.. _table_non_revocation_assertion_claim: +.. list-table:: + :widths: 20 60 20 + :header-rows: 1 + + * - **Payload** + - **Description** + - **Reference** + * - **iss** + - It MUST be set to the identifier of the Credential Issuer. + - :rfc:`9126` and :rfc:`7519`. + * - **jti** + - Unique identifier for the JWT. + - `[RFC7519, Section 4.1.7] `_. + * - **error** + - Status code returned from the Credential Issuer after revocation. The value SHOULD be assigned with one of the error types defined in {{RFC6749}}[Section 5.2] or defined in `[OAuth Status Attestation draft 01] `_ + - `[RFC6749, Section 5.2] `_, `[OAuth Status Attestation draft 01] `_ + * - **error_description** + - Text that clarifies the nature of the error, such as attribute changes, revocation reasons, in relation to the `error` value. + - `[OAuth Status Attestation draft 01] `_. + From 901cee36ea4e39f7140b52af5ce02fa2916f5aed Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 10 Jun 2024 10:16:04 +0200 Subject: [PATCH 007/105] Accepted review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index bd8c9e803..2c3f655da 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -264,7 +264,7 @@ Below a non-normative example of a Revocation Assertion object in JWT format, wi "typ": "revocation-assertion-error+jwt", "kid": "Issuer-JWK-KID" } - . +. { "iss": "https://issuer.example.org", "jti": "6f204f7e-e453-4dfd-814e-9d155319408c" From 9d5d9dc46b6345419780f58a24ea5b54e2a18e5d Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 10 Jun 2024 10:16:29 +0200 Subject: [PATCH 008/105] Accepted review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 2c3f655da..d1d593fba 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -366,8 +366,8 @@ Below a non-normative example representing a Status Assertion Request array with .. code:: POST /status HTTP/1.1 - Host: issuer.example.org - Content-Type: application/json + Host: issuer.example.org + Content-Type: application/json { "status_assertion_requests" : ["${base64url(json({typ: (some pop for status-assertion)+jwt, ...}))}.payload.signature", ... ] From 257745cb5d8e34873093179a61a2e1d0a03443ad Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 10 Jun 2024 10:16:55 +0200 Subject: [PATCH 009/105] Accepted review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index d1d593fba..13f15caeb 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -311,7 +311,7 @@ Below a non-normative example of a Revocation Assertion Error object in JWT form "typ": "revocation-assertion-error+jwt", "kid": "Issuer-JWK-KID" } - . +. { "iss": "https://issuer.example.org", "jti": "6f204f7e-e453-4dfd-814e-9d155319408c" From 871a4d265b75d31900295e10189b5c2f920566ec Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 10 Jun 2024 10:18:01 +0200 Subject: [PATCH 010/105] Accepted review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 13f15caeb..e4b71f421 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -623,7 +623,7 @@ When the JWT or CWT format are used, the Revocation Assertion MUST contain the f - Algorithm used to verify the cryptographic signature of the Revocation Assertion. Revocation Assertion that do not need to be signed SHOULD set the `alg` value to `none` in according with `[OAuth Status Attestation draft 01] `_. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - - It MUST be set to `revocation-assertion-respone+jwt` when JWT format is used. It MUST be set to `revocation-assertion-response+cwt` when CWT format is used. + - It MUST be set to `revocation-assertion-response+jwt` when JWT format is used. It MUST be set to `revocation-assertion-response+cwt` when CWT format is used. - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_.. From 342cff9b8f72d991055752f2612cd43ae6e2352d Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 17 Jun 2024 17:15:57 +0200 Subject: [PATCH 011/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index e4b71f421..4ed843197 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -155,7 +155,7 @@ Below, is given a non-normative example of a single Revocation Assertion Request { "alg": "ES256", - "typ": "revocation-assertion-request+jwt", + "typ": "credential-revocation-request+jwt", "kid": $CREDENTIAL-CNF-JWKID } . From 90ce6167840e0910394bba709bf99a25eeb180a9 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 17 Jun 2024 17:16:21 +0200 Subject: [PATCH 012/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 4ed843197..6c57fd2ef 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -188,7 +188,7 @@ Below, is given a non-normative example of a single Revocation Assertion Request Credential Revocation HTTP Request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with method POST, using the mandatory parameters listed below within the HTTP request message body. These MUST be encoded in ``application/JSON`` format. +The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with method POST, using the mandatory parameters listed below within the HTTP request message body. These MUST be encoded in ``application/json`` format. .. _table_revocation_request_params: .. list-table:: From d7fc2781ef8de35bd4b0f4bf08540d0e406ace4e Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 17 Jun 2024 17:16:41 +0200 Subject: [PATCH 013/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 6c57fd2ef..c03a1f4ad 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -200,7 +200,7 @@ The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with me - **Reference** * - **revocation_assertion_requests** - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession ` for more details. - - `[OAuth Status Assertion draft 01] `_ + - `[OAuth Status Assertion draft 01] `_ The Revocation Endpoint MUST be provided by the Credential Issuer within its Metadata. From a454d23f86eaabcb5fb790c68bbaa71bf667c8d4 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 17 Jun 2024 17:18:34 +0200 Subject: [PATCH 014/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index c03a1f4ad..864b789ae 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -178,7 +178,7 @@ Below, is given a non-normative example of a single Revocation Assertion Request .. code:: .. code-block:: http - HTTP/1.1 200 Created + HTTP/1.1 200 Ok Content-Type: application/json { From c243d2e39e545b71caff7182a36f918bbcfd10c7 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 28 Jun 2024 10:24:13 +0200 Subject: [PATCH 015/105] Alignment with the "draft-demarco-oauth-status-assertions" specifications --- docs/en/revocation-lists.rst | 59 +++++++++++++++++++++++++++--------- 1 file changed, 44 insertions(+), 15 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 864b789ae..41d8eff7f 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -45,7 +45,8 @@ Functional Requirements - SHOULD be presented in conjunction with the Digital Credential; - MUST include information that links it to the referenced Digital Credential; - MUST be timestamped with its issuance datetime, using a timestamp which is at or after the time of Digital Credential issuance which it refers; -- MUST contain the expiration datetime after which both the Status Assertion and the Digital Credential it refers MUST NOT be considered valid anymore. The expiration datetime MUST be superior to the Status Assertion issuance datetime and it MUST end before the expiration datetime of the Digital Credential; +- MUST contain the expiration datetime after which both the Status Assertion and the Digital Credential referred to SHOULD NOT be considered as having a valid status,since it appears without verification against any revocation. +- MUST have the expiration datetime greater than the Status Assertion issuance datetime and it MUST end before the expiration datetime of the Digital Credential; - MUST have a validity period not greater than 24 hours; - MUST provide the proof about the non-revocation of the Digital Credential which is related to and MUST be validated using the cryptographic signature of the Credential Issuer; - MUST NOT reveal any information about the Relying Party, the User's device or the User's data contained in the Digital Credential the assertion is related to; @@ -132,9 +133,9 @@ A Wallet Instance MUST request the revocation of a Digital Credential as defined Wallet Instance Initiated Revocation Flow -**Step 1 (Credential Revocation Request)**: The Wallet Instance initiates the process by creating a Credential Revocation Request. This request can be sent to a single Credential Issuer, regarding multiple Digital Credentials, and MUST contain a JSON object with the member `revocation_assertion_requests`. +**Step 1 (Credential Revocation Request)**: The Wallet Instance initiates the process by creating a Credential Revocation Request. This request can be sent to a single Credential Issuer, regarding multiple Digital Credentials, and MUST contain a JSON object with the member `revocation_requests`. -The `revocation_assertion_requests` MUST be set with an array of strings, where each string within the array represents a Credential Revocation Request object. +The `revocation_requests` MUST be set with an array of strings, where each string within the array represents a Credential Revocation Request object. It MUST be signed with the private key related to the public key contained within the Credential (such as the Credential Issuer Signed JWT in the case of SD-JWT, or the MSO in the case of Mdoc CBOR). Then, the Wallet Instance sends the request to the Credential Issuer as in the following non-normative example representing a Revocation Assertion Request array. @@ -145,7 +146,7 @@ It MUST be signed with the private key related to the public key contained withi Host: pid-provider.example.org Content-Type: application/json - revocation_assertion_requests : ["${base64url(json({typ: (some pop for revocation-assertion)+jwt, ...}))}.payload.signature", ... ] + revocation_requests : ["${base64url(json({typ: (some pop for revocation-assertion)+jwt, ...}))}.payload.signature", ... ] Below, is given a non-normative example of a single Revocation Assertion Request object with decoded JWT headers and payload and without signature for better readability: @@ -165,13 +166,13 @@ Below, is given a non-normative example of a single Revocation Assertion Request "iat": 1698744039, "exp": 1698744139, "jti": "6f204f7e-e453-4dfd-814e-9d155319408c", - "credential_hash": $Issuer-Signed-JWT-Hash - "credential_hash_alg": "sha-256", + "credential_hash": $Issuer-Signed-JWT-Hash, + "credential_hash_alg": "sha-256" } **Step 2 (PoP verification)**: The Credential Issuer verifies the signature of the PoP using the the confirmation method that was attested in the issued Digital Credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Digital Credential, and therefore is entitled to request its revocation. -**Step 3 (Credential Revocation)**: The Credential Issuer revokes the Credential provided in the revocation_assertion_requests object. After the revocation, the Credential Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. +**Step 3 (Credential Revocation)**: The Credential Issuer revokes the Credential provided in the revocation_requests object. After the revocation, the Credential Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. **Step 4 (Credential Revocation Response)**: The Credential Issuer sends a response back to the Wallet Instance with the result of the revocation request. @@ -198,7 +199,7 @@ The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with me * - **Claim** - **Description** - **Reference** - * - **revocation_assertion_requests** + * - **revocation_requests** - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession ` for more details. - `[OAuth Status Assertion draft 01] `_ @@ -254,14 +255,14 @@ The ``revocation_assertion_responses`` object MUST contain the following mandato - the Revocation Assertions and or the Revocation Assertion Errors related to the request made by the Wallet Instance. - `[OAuth Status Attestation draft 01] `_. -The Revocation Assertion object MUST contain the parameter ``msg`` with the value set to ``OK``. +The Revocation Assertion object MUST contain the parameter ``credential_status_validity`` with the value set to ``false`` and the parameter ``revoked`` set to ``true``. Below a non-normative example of a Revocation Assertion object in JWT format, with the headers and payload represented in JSON and without applying the signature. .. code:: { "alg": "ES256", - "typ": "revocation-assertion-error+jwt", + "typ": "revocation-error+jwt", "kid": "Issuer-JWK-KID" } . @@ -270,7 +271,20 @@ Below a non-normative example of a Revocation Assertion object in JWT format, wi "jti": "6f204f7e-e453-4dfd-814e-9d155319408c" "credential_hash": $CREDENTIAL-HASH, "credential_hash_alg": "sha-256", - "msg": "Revoked" + "credential_status_validity": false, + "credential_status": { + "revoked": true, + "suspended": false + }, + "cnf": { + "jwk": { + "alg": "ES256", + "kty": "EC", + "crv": "P-256", + "x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc", + "y": "MV3C88MhhEMba6oyMBWuGeB3dKHP4YADJmGyJwwILsk" + } + } } The Revocation Assertion Error object MUST contain the following parameters: @@ -402,6 +416,7 @@ A non-normative example of Credential Proof of Possession is provided :ref:`in t "exp": 1504785536, "credential_hash": $CREDENTIAL-HASH, "credential_hash_alg": "sha-256", + "credential_status_validity": true, "cnf": { "jwk": {...} } @@ -641,9 +656,15 @@ When the JWT or CWT format are used, the Revocation Assertion MUST contain the f * - **jti** - Unique identifier for the JWT. - `[RFC7519, Section 4.1.7] `_. - * - **msg** - - Message returned from the Credential Issuer after revocation. It MUST be set with the value "OK". - - This specification. + * - **credential_status_validity** + - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It MUST be set with the value `false`. + - `[OAuth Status Attestation draft 01] `_. + * - **revoked** + - Boolean value indicating the status of Credential revocation. It MUST be set with the value `true` in revocation scenario. + - `[OAuth Status Attestation draft 01] `_. + * - **suspended** + - Boolean value indicating the status of Credential suspension. It MUST be set with the value `false` in revocation scenario. + - `[OAuth Status Attestation draft 01] `_. Status Assertion @@ -691,6 +712,15 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - `[OAuth Status Attestation draft 01] `_. * - **credential_hash_alg** - The Algorithm used for hashing the Credential to which the Status Assertion is bound. The value SHOULD be set to ``S256``. + - `[OAuth Status Attestation draft 01] `_. + * - **credential_status_validity** + - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It is REQUIRED and it MUST be set with the value "false" or "true". + - `[OAuth Status Attestation draft 01] `_. + * - **revoked** + - Boolean value indicating the status of Credential revocation when the `credential_status_validity` is set to `false`. It MAY be set with the value `false` or `true`. + - `[OAuth Status Attestation draft 01] `_. + * - **suspended** + - Boolean value indicating the status of Credential suspension. It MAY be set with the value `false` or `true`. - `[OAuth Status Attestation draft 01] `_. * - **cnf** - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT and `Cose_Key` for CWT, MUST match with the one provided within the related Digital @@ -739,4 +769,3 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU * - **error_description** - Text that clarifies the nature of the error, such as attribute changes, revocation reasons, in relation to the `error` value. - `[OAuth Status Attestation draft 01] `_. - From eff29199de5c66b073f90ad570e69f2cef0e0e52 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 28 Jun 2024 10:34:49 +0200 Subject: [PATCH 016/105] white spaces fixed --- docs/en/revocation-lists.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 41d8eff7f..85d6775ff 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -45,7 +45,7 @@ Functional Requirements - SHOULD be presented in conjunction with the Digital Credential; - MUST include information that links it to the referenced Digital Credential; - MUST be timestamped with its issuance datetime, using a timestamp which is at or after the time of Digital Credential issuance which it refers; -- MUST contain the expiration datetime after which both the Status Assertion and the Digital Credential referred to SHOULD NOT be considered as having a valid status,since it appears without verification against any revocation. +- MUST contain the expiration datetime after which both the Status Assertion and the Digital Credential referred to SHOULD NOT be considered as having a valid status, since it appears without verification against any revocation. - MUST have the expiration datetime greater than the Status Assertion issuance datetime and it MUST end before the expiration datetime of the Digital Credential; - MUST have a validity period not greater than 24 hours; - MUST provide the proof about the non-revocation of the Digital Credential which is related to and MUST be validated using the cryptographic signature of the Credential Issuer; @@ -265,7 +265,7 @@ Below a non-normative example of a Revocation Assertion object in JWT format, wi "typ": "revocation-error+jwt", "kid": "Issuer-JWK-KID" } -. + . { "iss": "https://issuer.example.org", "jti": "6f204f7e-e453-4dfd-814e-9d155319408c" @@ -325,7 +325,7 @@ Below a non-normative example of a Revocation Assertion Error object in JWT form "typ": "revocation-assertion-error+jwt", "kid": "Issuer-JWK-KID" } -. + . { "iss": "https://issuer.example.org", "jti": "6f204f7e-e453-4dfd-814e-9d155319408c" From 4031593f4f11670778b963b77f7a9c6e97ab1b34 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Tue, 9 Jul 2024 17:26:23 +0200 Subject: [PATCH 017/105] update status code 404 not fount description in status attestation http response section --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index a37ace2fc..1f73a53f4 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -399,7 +399,7 @@ The following HTTP Status Codes MUST be supported: - The issuer cannot fulfill the request because of invalid parameters. * - *404 Not Found* - - - The Digital Credential can not be found by the Issuer. + - The Digital Credential may not be found by the Issuer, or the Status Attestation cannot be issued because the Credential has been revoked or updated. * - *500 Internal Server Error* - - The Issuer encountered an internal problem. (:rfc:`6749#section-5.2`). From 9d3978250ddc3c5a1dfc1178806258e0ebbf507b Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Tue, 9 Jul 2024 17:32:37 +0200 Subject: [PATCH 018/105] Add Credential PoP extra claims --- docs/en/revocation-lists.rst | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index a37ace2fc..183a1ab1e 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -160,8 +160,11 @@ Below, is given a non-normative example of a Credential PoP with decoded JWT hea "iat": 1698744039, "exp": 1698744139, "jti": "6f204f7e-e453-4dfd-814e-9d155319408c", - "credential_hash": $Issuer-Signed-JWT-Hash + "credential_hash": $Issuer-Signed-JWT-Hash, "credential_hash_alg": "sha-256", + "credential_type": "PersonalIdentiticationData", + "user_identifier": "001", + "document_id": "PID-98765" } **Step 2 (PoP verification)**: The Issuer verifies the signature of the PoP JWTs using the public key that was attested in the issued Digital Credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Digital Credential, and therefore is entitled to request its revocation. @@ -503,7 +506,15 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST * - **credential_hash_alg** - It MUST contain the Algorithm used for hashing the Digital Credential. The value SHOULD be set to `S256`. - `[OAuth Status Attestation draft 01] `_. - + * - **credential_type** + - Type of credential (e.g., Personal Identification Data, European Disability Card, European Health Insurance Card, Driver's License, etc.) + - + * - **user_identifier** + - Identifier used to avoid direct linking between the credential hash and the owner. + - + * - **document_id** + - Unique identifier of the document to which the attestation refers. + - Status Attestation From f2783f00c983e8707ff1dd7401f337bb53c73f50 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 11:42:23 +0200 Subject: [PATCH 019/105] Editorial review --- docs/en/revocation-lists.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index cb49b8a0c..20ab9cd7e 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -529,15 +529,15 @@ The `error` parameter for the Status Assertion Error object MUST be set with one - The request is not valid due to the lack or incorrectness of one or more parameters. (:rfc:`6749#section-5.2`). * - ``credential_revoked`` - The Digital Credential is revoked. The reason of revocation MUST be provided in the *error_description* field. - * - ``credential_updated`` + * - ``credential_updated`` - One or more information contained in the Digital Credential are changed. The `error_description` field SHOULD contain a human-readable text describing the general parameters updated without specifying each one. - * - ``credential_invalid`` + * - ``credential_invalid`` - The Digital Credential is invalid. The `error_description` field SHOULD contain the reason of invalidation. * - ``invalid_request_signature`` - The Status Assertion Request signature validation has failed. This error type is used when the proof of possession of the Digital Credential is found not valid within the Status Assertion Request. - * - ``credential_not_found`` + * - ``credential_not_found`` - The `credential_hash` value provided in the Status Assertion Request doesn't match with any active Digital Credential. - * - ``unsupported_hash_alg`` + * - ``unsupported_hash_alg`` - The hash algorithm set in `credential_hash_alg` is not supported. Below a non-normative example of a Status Assertion Error object in JWT format, with the headers and payload represented in JSON and without applying the signature. From 2500f1515103610d61bb15f862204a1cc518ea61 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 11:47:39 +0200 Subject: [PATCH 020/105] code fixed --- docs/en/revocation-lists.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 20ab9cd7e..4c595e97b 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -671,10 +671,10 @@ When the JWT or CWT format are used, the Revocation Assertion MUST contain the f * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It MUST be set with the value `false`. - `[OAuth Status Attestation draft 01] `_. - * - **revoked** + * - **revoked** - Boolean value indicating the status of Credential revocation. It MUST be set with the value `true` in revocation scenario. - `[OAuth Status Attestation draft 01] `_. - * - **suspended** + * - **suspended** - Boolean value indicating the status of Credential suspension. It MUST be set with the value `false` in revocation scenario. - `[OAuth Status Attestation draft 01] `_. From 172153c85212d05ecd1c7476baa785c503973f06 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 11:53:39 +0200 Subject: [PATCH 021/105] tab spaces fixed --- docs/en/revocation-lists.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 4c595e97b..72ae2b48f 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -308,16 +308,16 @@ The `error` parameter for the Revocation Assertion Error object MUST be set with - The request is not valid due to the lack or incorrectness of one or more parameters. (:rfc:`6749#section-5.2`). * - ``credential_already_revoked`` - The Digital Credential is already revoked. - * - ``credential_updated`` + * - ``credential_updated`` - One or more information contained in the Digital Credential are changed. The `error_description` field SHOULD contain a human-readable text describing the general parameters updated without specifying each one. - * - ``credential_invalid`` - - The Digital Credential is invalid. The `error_description` field SHOULD contain the reason of invalidation. - * - ``invalid_request_signature`` - - The Revocation Assertion Request signature validation has failed. This error type is used when the proof of possession of the Digital Credential is found not valid within the Revocation Assertion Request. - * - ``credential_not_found`` - - The `credential_hash` value provided in the Revocation Assertion Request doesn't match with any active Digital Credential. - * - ``unsupported_hash_alg`` - - The hash algorithm set in `credential_hash_alg` is not supported. + * - ``credential_invalid`` + - The Digital Credential is invalid. The `error_description` field SHOULD contain the reason of invalidation. + * - ``invalid_request_signature`` + - The Revocation Assertion Request signature validation has failed. This error type is used when the proof of possession of the Digital Credential is found not valid within the Revocation Assertion Request. + * - ``credential_not_found`` + - The `credential_hash` value provided in the Revocation Assertion Request doesn't match with any active Digital Credential. + * - ``unsupported_hash_alg`` + - The hash algorithm set in `credential_hash_alg` is not supported. Below a non-normative example of a Revocation Assertion Error object in JWT format, with the headers and payload represented in JSON and without applying the signature. From 4937dd1f2cb278b1c1190c66a603d65237d13e95 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 12:06:45 +0200 Subject: [PATCH 022/105] Editorial review --- docs/en/revocation-lists.rst | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 72ae2b48f..74a97f531 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -298,7 +298,9 @@ The Revocation Assertion Error object MUST contain the following parameters: Errors are meant to provide additional information about the failure so that the User can be informed and take the appropriate action. The `error` parameter for the Revocation Assertion Error object MUST be set with one of the values defined in the table below, in addition to the values specified in :rfc:`6749#section-5.2`: -.. list-table:: +Here's the fixed table in reStructuredText (reST) format: + +.. list-table:: :widths: 20 80 :header-rows: 1 @@ -310,14 +312,14 @@ The `error` parameter for the Revocation Assertion Error object MUST be set with - The Digital Credential is already revoked. * - ``credential_updated`` - One or more information contained in the Digital Credential are changed. The `error_description` field SHOULD contain a human-readable text describing the general parameters updated without specifying each one. - * - ``credential_invalid`` - - The Digital Credential is invalid. The `error_description` field SHOULD contain the reason of invalidation. - * - ``invalid_request_signature`` - - The Revocation Assertion Request signature validation has failed. This error type is used when the proof of possession of the Digital Credential is found not valid within the Revocation Assertion Request. - * - ``credential_not_found`` - - The `credential_hash` value provided in the Revocation Assertion Request doesn't match with any active Digital Credential. - * - ``unsupported_hash_alg`` - - The hash algorithm set in `credential_hash_alg` is not supported. + * - ``credential_invalid`` + - The Digital Credential is invalid. The `error_description` field SHOULD contain the reason of invalidation. + * - ``invalid_request_signature`` + - The Revocation Assertion Request signature validation has failed. This error type is used when the proof of possession of the Digital Credential is found not valid within the Revocation Assertion Request. + * - ``credential_not_found`` + - The `credential_hash` value provided in the Revocation Assertion Request doesn't match with any active Digital Credential. + * - ``unsupported_hash_alg`` + - The hash algorithm set in `credential_hash_alg` is not supported. Below a non-normative example of a Revocation Assertion Error object in JWT format, with the headers and payload represented in JSON and without applying the signature. @@ -638,7 +640,7 @@ Revocation Assertion When the JWT or CWT format are used, the Revocation Assertion MUST contain the following claims. -.. _table_non_revocation_assertion_header: +.. _table_revocation_assertion_header: .. list-table:: :widths: 20 60 20 :header-rows: 1 @@ -654,7 +656,7 @@ When the JWT or CWT format are used, the Revocation Assertion MUST contain the f - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_.. -.. _table_non_revocation_assertion_claim: +.. _table_revocation_assertion_claim: .. list-table:: :widths: 20 60 20 :header-rows: 1 @@ -745,7 +747,7 @@ Error Assertion When the JWT or CWT format are used, the Revocation or Status Assertion Error MUST contain the following claims. -.. _table_non_revocation_assertion_header: +.. _table_non_revocation_assertion_error_header: .. list-table:: :widths: 20 60 20 :header-rows: 1 @@ -761,7 +763,7 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_. -.. _table_non_revocation_assertion_claim: +.. _table_non_revocation_assertion_error_claim: .. list-table:: :widths: 20 60 20 :header-rows: 1 From fa42a40d0ba15bbd41848d187a94f3ab733f2d6c Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 12:13:48 +0200 Subject: [PATCH 023/105] Editorial changes --- docs/en/revocation-lists.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 74a97f531..aa48b1857 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -727,13 +727,13 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo * - **credential_hash_alg** - The Algorithm used for hashing the Credential to which the Status Assertion is bound. The value SHOULD be set to ``S256``. - `[OAuth Status Attestation draft 01] `_. - * - **credential_status_validity** + * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It is REQUIRED and it MUST be set with the value "false" or "true". - `[OAuth Status Attestation draft 01] `_. - * - **revoked** + * - **revoked** - Boolean value indicating the status of Credential revocation when the `credential_status_validity` is set to `false`. It MAY be set with the value `false` or `true`. - `[OAuth Status Attestation draft 01] `_. - * - **suspended** + * - **suspended** - Boolean value indicating the status of Credential suspension. It MAY be set with the value `false` or `true`. - `[OAuth Status Attestation draft 01] `_. * - **cnf** @@ -759,7 +759,7 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU - Algorithm used to verify the cryptographic signature of the Assertion Error. Assertion Error that do not need to be signed SHOULD set the `alg` value to `none` in according with `[OAuth Status Attestation draft 01] `_. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - - It MUST be set to `status-assertion-response+jwt` or `revocation-assertion-response+jwt`when JWT format is used. It MUST be set to `status-assertion-response+cwt` or `revocation-assertion-response+cwt`when CWT format is used. + - It MUST be set to `status-assertion-response+jwt` or `revocation-assertion-response+jwt` when JWT format is used. It MUST be set to `status-assertion-response+cwt` or `revocation-assertion-response+cwt` when CWT format is used. - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_. From 497ba115672a402799bf0af3e673d482dece28f6 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 12:28:21 +0200 Subject: [PATCH 024/105] Duplicate explicit target name and table structure fixed --- docs/en/revocation-lists.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index aa48b1857..75ebd920f 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -11,7 +11,7 @@ For these reasons a robust mechanism for managing the life-cycle and the revocat This section outlines the key technical requirements and processes related to the revocation of Digital Credentials. Furthermore, it provides the technical details that the Verifiers MUST implement to verify, in a secure and reliable manner, the validity of a Digital Credential during the presentation phase. -The verification of the validity of a Digital Credential is based on the `[OAuth Status Assertion draft 01] `_ specification. +The verification of the validity of a Digital Credential is based on the `[OAuth Status Attestation draft 01] `_ specification. A Status Assertion is a signed document serving as proof of a Digital Credential's current validity status. The Credential Issuer provides these assertions to Holders who can present them to Verifiers together with the corresponding Digital Credentials. @@ -203,8 +203,8 @@ The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with me - **Description** - **Reference** * - **revocation_requests** - - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession ` for more details. - - `[OAuth Status Assertion draft 01] `_ + - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession ` for more details. + - `[OAuth Status Attestation draft 01] `_ The Revocation Endpoint MUST be provided by the Credential Issuer within its Metadata. @@ -737,8 +737,7 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - Boolean value indicating the status of Credential suspension. It MAY be set with the value `false` or `true`. - `[OAuth Status Attestation draft 01] `_. * - **cnf** - - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT and `Cose_Key` for CWT, MUST match with the one provided within the related Digital - Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. + - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT and `Cose_Key` for CWT, MUST match with the one provided within the related Digital Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. - `[RFC7800, Section 3.1] `_ and `[RFC8747, Section 3.1] `_. From 34d3394bf5c5e5ac7d278206a62d63c5a9e9804c Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 12:35:39 +0200 Subject: [PATCH 025/105] code fixed --- docs/en/revocation-lists.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 75ebd920f..9553c99fd 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -636,7 +636,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT t - Revocation Assertion ------------------- +-------------------- When the JWT or CWT format are used, the Revocation Assertion MUST contain the following claims. @@ -779,6 +779,6 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU * - **error** - Status code returned from the Credential Issuer after revocation. The value SHOULD be assigned with one of the error types defined in {{RFC6749}}[Section 5.2] or defined in `[OAuth Status Attestation draft 01] `_ - `[RFC6749, Section 5.2] `_, `[OAuth Status Attestation draft 01] `_ - * - **error_description** + * - **error_description** - Text that clarifies the nature of the error, such as attribute changes, revocation reasons, in relation to the `error` value. - `[OAuth Status Attestation draft 01] `_. From 864b1910e69fc063a19dfd58ac55f0d2b9f3c8a2 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 12:39:00 +0200 Subject: [PATCH 026/105] duplicate table name fixed --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 9553c99fd..3f48ad166 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -475,7 +475,7 @@ The response MUST: It MUST contain the following mandatory claims. -.. _table_http_response_claim: +.. _table_http_status_assertion_response_claim: .. list-table:: :widths: 20 60 20 :header-rows: 1 From 454673d989c96612991dc7e8bda1fc970217fcff Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 15:56:44 +0200 Subject: [PATCH 027/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 3f48ad166..aa7a38224 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -11,7 +11,7 @@ For these reasons a robust mechanism for managing the life-cycle and the revocat This section outlines the key technical requirements and processes related to the revocation of Digital Credentials. Furthermore, it provides the technical details that the Verifiers MUST implement to verify, in a secure and reliable manner, the validity of a Digital Credential during the presentation phase. -The verification of the validity of a Digital Credential is based on the `[OAuth Status Attestation draft 01] `_ specification. +The verification of the validity of a Digital Credential is based on the `[OAuth Status Attestation draft 01] `_ specification. A Status Assertion is a signed document serving as proof of a Digital Credential's current validity status. The Credential Issuer provides these assertions to Holders who can present them to Verifiers together with the corresponding Digital Credentials. From 98136f003cb59e60bb9917ac9b8fd9c649af7334 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 16:06:51 +0200 Subject: [PATCH 028/105] review suggestion applied The suggestion mentioned in the comment https://github.com/italia/eudi-wallet-it-docs/pull/308#discussion_r1673884846 has been applied. --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index aa7a38224..4e29677b3 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -100,7 +100,7 @@ Credential Revocation Flows can start under different scenarios, such as: - Users who lose access to their Wallet Instance (e.g., due to theft or loss of the device) can request the Credential Issuer to revoke their Credentials or ask the Wallet Provider to revoke the Wallet Instance. If the Wallet Provider is authorized by the User and is aware of the types of Credentials and their issuers stored in the Wallet, it can then initiate the revocation of all Digital Credentials contained within the Wallet Instance on behalf of the User. - The Law-Enforcing Authorities, for the fulfillment of their functions and any other judicial reasons, may request the Authentic Source to revoke entitlements, licenses, certificates, identification documents, etc., which in turn leads to the revocation of any linked Credentials. - The Authentic Sources that for any administrative reasons update one or more attributes of a User, shall inform the Credential Issuer of related Credentials. - - The Credential Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys, death of the User, etc.), can decide to revoke the Credentials. + - The Credential Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys, loss of device, etc.), SHOULD decide to revoke the Credentials. The revocation scenarios involve two main flows: From 64fee645c6ea1988de67f97ee43044d0dc97c214 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 16:45:35 +0200 Subject: [PATCH 029/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 4e29677b3..3b8431ec2 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -99,7 +99,7 @@ Credential Revocation Flows can start under different scenarios, such as: - The User notifies an Authentic Source that one or more attributes are changed (e.g. the current resident address): in this case the Credentials SHALL be revoked, as they are no longer valid due to the change in attributes. - Users who lose access to their Wallet Instance (e.g., due to theft or loss of the device) can request the Credential Issuer to revoke their Credentials or ask the Wallet Provider to revoke the Wallet Instance. If the Wallet Provider is authorized by the User and is aware of the types of Credentials and their issuers stored in the Wallet, it can then initiate the revocation of all Digital Credentials contained within the Wallet Instance on behalf of the User. - The Law-Enforcing Authorities, for the fulfillment of their functions and any other judicial reasons, may request the Authentic Source to revoke entitlements, licenses, certificates, identification documents, etc., which in turn leads to the revocation of any linked Credentials. - - The Authentic Sources that for any administrative reasons update one or more attributes of a User, shall inform the Credential Issuer of related Credentials. + - The Authentic Sources that for any update of one or more User attributes, shall inform the Credential Issuer that has previously requested those data for the issuance of a Credential about that User. - The Credential Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys, loss of device, etc.), SHOULD decide to revoke the Credentials. From 8f356a3a4f39005107c24788238f0821d165c9bd Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 11 Jul 2024 16:46:06 +0200 Subject: [PATCH 030/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 3b8431ec2..a4c13153c 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -106,7 +106,7 @@ Credential Revocation Flows can start under different scenarios, such as: The revocation scenarios involve two main flows: - The **Revocation flows**: these flows describe how an Entity requests for a Digital Credential revocation. - - The **Status Assertion flows**: these flows define the technical protocols for requesting and obtaining a Status Assertion and how the Wallet Instance will provide it to a Verifier as a proof of validity of a corresponding Digital Credential. + - The **Status Assertion flows**: these flows define the technical protocols for requesting and obtaining a Status Assertion and how the Wallet Instance SHOULD provide it to a Verifier as a proof of validity of a corresponding Digital Credential. .. _sec_revocation_high_level_flow: From 19d73b802909218aa755eaa06da3b978c9fbd79e Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 12 Jul 2024 11:08:52 +0200 Subject: [PATCH 031/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index a4c13153c..8f8f2177f 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -133,7 +133,7 @@ A Wallet Instance MUST request the revocation of a Digital Credential as defined Wallet Instance Initiated Revocation Flow -**Step 1 (Credential Revocation Request)**: The Wallet Instance initiates the process by creating a Credential Revocation Request. This request can be sent to a single Credential Issuer, regarding multiple Digital Credentials, and MUST contain a JSON object with the member `revocation_requests`. +**Step 1 (Credential Revocation Request)**: The Wallet Instance initiates the process by creating a Credential Revocation Request. This request MUST be sent to the Credential Issuer who has previously issued that Credential. The Credential Revocation Request MUST contain a JSON object with the member `revocation_requests`. The `revocation_requests` MUST be set with an array of strings, where each string within the array represents a Credential Revocation Request object. From 1ffe8edeeba30610878b542864cb9a54d2f0453b Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 12 Jul 2024 11:09:30 +0200 Subject: [PATCH 032/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 8f8f2177f..385db81ca 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -175,7 +175,7 @@ Below, is given a non-normative example of a single Revocation Assertion Request **Step 2 (PoP verification)**: The Credential Issuer verifies the signature of the PoP using the the confirmation method that was attested in the issued Digital Credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Digital Credential, and therefore is entitled to request its revocation. -**Step 3 (Credential Revocation)**: The Credential Issuer revokes the Credential provided in the revocation_requests object. After the revocation, the Credential Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. +**Step 3 (Credential Revocation)**: The Credential Issuer revokes the Credential provided in the Revocation Request object. After the revocation, the Credential Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. **Step 4 (Credential Revocation Response)**: The Credential Issuer sends a response back to the Wallet Instance with the result of the revocation request. From fd2e8efde74d601a1427f671e080e89c745dc0e6 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 12 Jul 2024 11:12:19 +0200 Subject: [PATCH 033/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 385db81ca..0787df826 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -204,7 +204,7 @@ The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with me - **Reference** * - **revocation_requests** - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession ` for more details. - - `[OAuth Status Attestation draft 01] `_ + - `[OAuth Status Assertions] `_ The Revocation Endpoint MUST be provided by the Credential Issuer within its Metadata. From 5d8d7dec715a282cc676d851ca15d72e7f01cdb6 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 12 Jul 2024 11:12:49 +0200 Subject: [PATCH 034/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 0787df826..85d00f64b 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -256,7 +256,7 @@ The ``revocation_assertion_responses`` object MUST contain the following mandato - **Reference** * - **revocation_assertion_responses** - the Revocation Assertions and or the Revocation Assertion Errors related to the request made by the Wallet Instance. - - `[OAuth Status Attestation draft 01] `_. + - `[OAuth Status Attestation] `_. The Revocation Assertion object MUST contain the parameter ``credential_status_validity`` with the value set to ``false`` and the parameter ``revoked`` set to ``true``. Below a non-normative example of a Revocation Assertion object in JWT format, with the headers and payload represented in JSON and without applying the signature. From 0ac1a73097cebc757cfbccb081fd2422d15cf40d Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 12 Jul 2024 11:13:12 +0200 Subject: [PATCH 035/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 85d00f64b..62e79a6ab 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -337,7 +337,7 @@ Below a non-normative example of a Revocation Assertion Error object in JWT form "credential_hash": $CREDENTIAL-HASH, "credential_hash_alg": "sha-256", "error": "unsupported_hash_alg", - "error_description": "The hash algorithm set is not supported" + "error_description": "The hash algorithm is not supported" } From 282388fd480b8183ce4041ead4f498d90f32f824 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 12 Jul 2024 11:14:08 +0200 Subject: [PATCH 036/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 62e79a6ab..ea858b954 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -588,7 +588,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT t - **Description** - **Reference** * - **typ** - - In case of revocation request it MUST be set to ``revocation-request+{jwt,cwt}``. In case of Status Assertion request it MUST be set to ``status-assertion-request+{jwt,cwt}``, according to `[OAuth Status Attestation draft 01] `_. + - In case of revocation request it MUST be set to ``revocation-request+{jwt,cwt}``. In case of Status Assertion request it MUST be set to ``status-assertion-request+{jwt,cwt}``, according to `[OAuth Status Assertions] `_. - :rfc:`7516#section-4.1.1`. * - **alg** - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. From ed2c4e7e688124057018a832df8eeeb97e811528 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 12 Jul 2024 11:15:35 +0200 Subject: [PATCH 037/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index ea858b954..1dabdedbe 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -594,7 +594,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT t - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. - :rfc:`7516#section-4.1.1`. * - **kid** - - Unique identifier of the ``jwk`` or ``COSE_Key`` inside the ``cnf`` claim of the Credential to be revoked, as base64url-encoded JWK Thumbprint value, according to `[OAuth Status Attestation draft 01] `_. + - Unique identifier of the ``jwk`` or ``COSE_Key`` inside the ``cnf`` claim of the Credential to be revoked, as base64url-encoded JWK Thumbprint value, according to `[OAuth Status Assertions] `_. - :rfc:`7638#section_3`. .. list-table:: From 62b648757a8cdfaca0353e1b0aa6f46bf95ab072 Mon Sep 17 00:00:00 2001 From: m-basili Date: Thu, 18 Jul 2024 10:30:47 +0200 Subject: [PATCH 038/105] Update common_definitions.rst --- docs/common/common_definitions.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/common/common_definitions.rst b/docs/common/common_definitions.rst index c0fe87160..c4af0ba03 100644 --- a/docs/common/common_definitions.rst +++ b/docs/common/common_definitions.rst @@ -57,5 +57,6 @@ .. _RFC 7519: https://www.rfc-editor.org/rfc/rfc7519 .. _OAUTH2: https://www.rfc-editor.org/rfc/rfc6749 .. _OPENID4VC-HAIP: https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.html +.. _OAUTH-STATUS-ASSERTION: https://datatracker.ietf.org/doc/draft-demarco-oauth-status-assertions/02/ From 95319910a9896e10d7fa602d6597cf796589f5fe Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 11:35:26 +0200 Subject: [PATCH 039/105] a Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 1dabdedbe..367bff395 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -168,7 +168,6 @@ Below, is given a non-normative example of a single Revocation Assertion Request "jti": "6f204f7e-e453-4dfd-814e-9d155319408c", "credential_hash": $Issuer-Signed-JWT-Hash, "credential_hash_alg": "sha-256", - "credential_type": "PersonalIdentiticationData", "user_identifier": "001", "document_id": "PID-98765" } From fa05eb182201a0555e84f7606678a1bf4f81245e Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 11:40:24 +0200 Subject: [PATCH 040/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 367bff395..8ea86fc26 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -135,7 +135,7 @@ A Wallet Instance MUST request the revocation of a Digital Credential as defined **Step 1 (Credential Revocation Request)**: The Wallet Instance initiates the process by creating a Credential Revocation Request. This request MUST be sent to the Credential Issuer who has previously issued that Credential. The Credential Revocation Request MUST contain a JSON object with the member `revocation_requests`. -The `revocation_requests` MUST be set with an array of strings, where each string within the array represents a Credential Revocation Request object. +The `revocation_requests` MUST be set with an array of strings, where each string within the array represents a Credential Revocation Request object, enabling the Wallet Instance to request multiple Credential Revocation Requests to a single Credential Issuer. It MUST be signed with the private key related to the public key contained within the Credential (such as the Credential Issuer Signed JWT in the case of SD-JWT, or the MSO in the case of Mdoc CBOR). Then, the Wallet Instance sends the request to the Credential Issuer as in the following non-normative example representing a Revocation Assertion Request array. From 4a2b16cc3456fb0d1f22e855d76d1f7ea8f8fcdc Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 11:41:26 +0200 Subject: [PATCH 041/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 8ea86fc26..b4f524f5b 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -137,7 +137,7 @@ A Wallet Instance MUST request the revocation of a Digital Credential as defined The `revocation_requests` MUST be set with an array of strings, where each string within the array represents a Credential Revocation Request object, enabling the Wallet Instance to request multiple Credential Revocation Requests to a single Credential Issuer. -It MUST be signed with the private key related to the public key contained within the Credential (such as the Credential Issuer Signed JWT in the case of SD-JWT, or the MSO in the case of Mdoc CBOR). Then, the Wallet Instance sends the request to the Credential Issuer as in the following non-normative example representing a Revocation Assertion Request array. +The request MUST be signed with the private key related to the public key contained within the Credential (such as the Credential Issuer Signed JWT in the case of SD-JWT, or the MSO in the case of Mdoc CBOR). Then, the Wallet Instance sends the request to the Credential Issuer as in the following non-normative example representing a Revocation Assertion Request array. .. _credential_revocation_request_ex: .. code-block:: From a21f5b2fa45bcc6d3ffb9ce31fa45492dc43293a Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 11:42:19 +0200 Subject: [PATCH 042/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index b4f524f5b..695d47260 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -168,8 +168,6 @@ Below, is given a non-normative example of a single Revocation Assertion Request "jti": "6f204f7e-e453-4dfd-814e-9d155319408c", "credential_hash": $Issuer-Signed-JWT-Hash, "credential_hash_alg": "sha-256", - "user_identifier": "001", - "document_id": "PID-98765" } **Step 2 (PoP verification)**: The Credential Issuer verifies the signature of the PoP using the the confirmation method that was attested in the issued Digital Credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Digital Credential, and therefore is entitled to request its revocation. From 5b6a5fdbb8cadb249c81935d3f8f658455151e64 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 11:43:02 +0200 Subject: [PATCH 043/105] Commit suggestion applied Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 695d47260..0b3252935 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -170,7 +170,7 @@ Below, is given a non-normative example of a single Revocation Assertion Request "credential_hash_alg": "sha-256", } -**Step 2 (PoP verification)**: The Credential Issuer verifies the signature of the PoP using the the confirmation method that was attested in the issued Digital Credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Digital Credential, and therefore is entitled to request its revocation. +**Step 2 (PoP verification)**: The Credential Issuer verifies the proof of possession of the Credential requested to be revoked, using the the confirmation method that was attested in the Credential. If the verification is successful the revocation request is allowed. **Step 3 (Credential Revocation)**: The Credential Issuer revokes the Credential provided in the Revocation Request object. After the revocation, the Credential Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. From 95743913980fea3accba6b711996d602d7b8279a Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:00:16 +0200 Subject: [PATCH 044/105] Accepted review suggestion Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 0b3252935..7dfc7f808 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -11,7 +11,7 @@ For these reasons a robust mechanism for managing the life-cycle and the revocat This section outlines the key technical requirements and processes related to the revocation of Digital Credentials. Furthermore, it provides the technical details that the Verifiers MUST implement to verify, in a secure and reliable manner, the validity of a Digital Credential during the presentation phase. -The verification of the validity of a Digital Credential is based on the `[OAuth Status Attestation draft 01] `_ specification. +The verification of the validity of a Digital Credential is based on the `OAUTH-STATUS-ASSERTION`_ draft 02. A Status Assertion is a signed document serving as proof of a Digital Credential's current validity status. The Credential Issuer provides these assertions to Holders who can present them to Verifiers together with the corresponding Digital Credentials. From 6b6ca32219d03943d6815fd66b294f881471d4fd Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:11:55 +0200 Subject: [PATCH 045/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 7dfc7f808..85cfb06e9 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -40,7 +40,7 @@ Operational Requirements Functional Requirements ----------------------- -**The Status Assertion:** +In addition to the requirements in Section 5 of `OAUTH-STATUS-ASSERTION`_ draft 02, **The Status Assertion:** - SHOULD be presented in conjunction with the Digital Credential; - MUST include information that links it to the referenced Digital Credential; From 2e335330a483acc0e009bc66186a1d224351597f Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:48:14 +0200 Subject: [PATCH 046/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 6 ------ 1 file changed, 6 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 85cfb06e9..7eb7ff2ad 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -42,13 +42,7 @@ Functional Requirements In addition to the requirements in Section 5 of `OAUTH-STATUS-ASSERTION`_ draft 02, **The Status Assertion:** -- SHOULD be presented in conjunction with the Digital Credential; -- MUST include information that links it to the referenced Digital Credential; -- MUST be timestamped with its issuance datetime, using a timestamp which is at or after the time of Digital Credential issuance which it refers; -- MUST contain the expiration datetime after which both the Status Assertion and the Digital Credential referred to SHOULD NOT be considered as having a valid status, since it appears without verification against any revocation. -- MUST have the expiration datetime greater than the Status Assertion issuance datetime and it MUST end before the expiration datetime of the Digital Credential; - MUST have a validity period not greater than 24 hours; -- MUST provide the proof about the non-revocation of the Digital Credential which is related to and MUST be validated using the cryptographic signature of the Credential Issuer; - MUST NOT reveal any information about the Relying Party, the User's device or the User's data contained in the Digital Credential the assertion is related to; - MUST be non-repudiable even beyond its expiration time and even in the case of cryptographic keys rotation. From ca06e2c1c1d39e6a964d990863f961c7cca0a36a Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:48:51 +0200 Subject: [PATCH 047/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 7eb7ff2ad..9a6a4884c 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -93,7 +93,7 @@ Credential Revocation Flows can start under different scenarios, such as: - The User notifies an Authentic Source that one or more attributes are changed (e.g. the current resident address): in this case the Credentials SHALL be revoked, as they are no longer valid due to the change in attributes. - Users who lose access to their Wallet Instance (e.g., due to theft or loss of the device) can request the Credential Issuer to revoke their Credentials or ask the Wallet Provider to revoke the Wallet Instance. If the Wallet Provider is authorized by the User and is aware of the types of Credentials and their issuers stored in the Wallet, it can then initiate the revocation of all Digital Credentials contained within the Wallet Instance on behalf of the User. - The Law-Enforcing Authorities, for the fulfillment of their functions and any other judicial reasons, may request the Authentic Source to revoke entitlements, licenses, certificates, identification documents, etc., which in turn leads to the revocation of any linked Credentials. - - The Authentic Sources that for any update of one or more User attributes, shall inform the Credential Issuer that has previously requested those data for the issuance of a Credential about that User. + - The Authentic Sources that for any update of one or more User attributes, SHOULD inform the Credential Issuer that has previously requested those data for the issuance of a Credential about that User. - The Credential Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys, loss of device, etc.), SHOULD decide to revoke the Credentials. From 999725f6f9423475d02fa3806555363ad4a2003f Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:49:43 +0200 Subject: [PATCH 048/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 9a6a4884c..23466c06f 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -90,7 +90,7 @@ The revocation of a Digital Credential MAY be triggered by: Credential Revocation Flows can start under different scenarios, such as: - The User reports the loss or theft of their own physical document to the Law-Enforcement Authorities: this implies that the Credentials, if any, shall be revoked. - - The User notifies an Authentic Source that one or more attributes are changed (e.g. the current resident address): in this case the Credentials SHALL be revoked, as they are no longer valid due to the change in attributes. + - The User notifies an Authentic Source that one or more attributes are changed (e.g. the current resident address): in this case the Credentials MUST be revoked, as they are no longer valid due to the change in attributes. - Users who lose access to their Wallet Instance (e.g., due to theft or loss of the device) can request the Credential Issuer to revoke their Credentials or ask the Wallet Provider to revoke the Wallet Instance. If the Wallet Provider is authorized by the User and is aware of the types of Credentials and their issuers stored in the Wallet, it can then initiate the revocation of all Digital Credentials contained within the Wallet Instance on behalf of the User. - The Law-Enforcing Authorities, for the fulfillment of their functions and any other judicial reasons, may request the Authentic Source to revoke entitlements, licenses, certificates, identification documents, etc., which in turn leads to the revocation of any linked Credentials. - The Authentic Sources that for any update of one or more User attributes, SHOULD inform the Credential Issuer that has previously requested those data for the issuance of a Credential about that User. From 16ed07255b294386f94e4e16e42b0bcab7c4c42b Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:53:05 +0200 Subject: [PATCH 049/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 23466c06f..1de535986 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -194,7 +194,7 @@ The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with me - **Description** - **Reference** * - **revocation_requests** - - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession ` for more details. + - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession `_ for more details. - `[OAuth Status Assertions] `_ The Revocation Endpoint MUST be provided by the Credential Issuer within its Metadata. From a6f04db1ee8fe7565df2708aa56ef0bc0ca58ab5 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:54:04 +0200 Subject: [PATCH 050/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 1de535986..84e126de2 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -94,7 +94,7 @@ Credential Revocation Flows can start under different scenarios, such as: - Users who lose access to their Wallet Instance (e.g., due to theft or loss of the device) can request the Credential Issuer to revoke their Credentials or ask the Wallet Provider to revoke the Wallet Instance. If the Wallet Provider is authorized by the User and is aware of the types of Credentials and their issuers stored in the Wallet, it can then initiate the revocation of all Digital Credentials contained within the Wallet Instance on behalf of the User. - The Law-Enforcing Authorities, for the fulfillment of their functions and any other judicial reasons, may request the Authentic Source to revoke entitlements, licenses, certificates, identification documents, etc., which in turn leads to the revocation of any linked Credentials. - The Authentic Sources that for any update of one or more User attributes, SHOULD inform the Credential Issuer that has previously requested those data for the issuance of a Credential about that User. - - The Credential Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys, loss of device, etc.), SHOULD decide to revoke the Credentials. + - The Credential Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys), SHOULD decide to revoke the Credentials. The revocation scenarios involve two main flows: From e41249ac4e27f563cc4bf3d56d3bcf7c092319df Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:55:06 +0200 Subject: [PATCH 051/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 84e126de2..a9576e263 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -195,7 +195,7 @@ The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with me - **Reference** * - **revocation_requests** - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession `_ for more details. - - `[OAuth Status Assertions] `_ + - `OAUTH-STATUS-ASSERTION`_ draft 02. The Revocation Endpoint MUST be provided by the Credential Issuer within its Metadata. From 1993af14719a22f2988d900dbcd71acb2dc427fa Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:56:01 +0200 Subject: [PATCH 052/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index a9576e263..ad28eec29 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -247,7 +247,7 @@ The ``revocation_assertion_responses`` object MUST contain the following mandato - **Reference** * - **revocation_assertion_responses** - the Revocation Assertions and or the Revocation Assertion Errors related to the request made by the Wallet Instance. - - `[OAuth Status Attestation] `_. + - `OAUTH-STATUS-ASSERTION`_ draft 02`_. The Revocation Assertion object MUST contain the parameter ``credential_status_validity`` with the value set to ``false`` and the parameter ``revoked`` set to ``true``. Below a non-normative example of a Revocation Assertion object in JWT format, with the headers and payload represented in JSON and without applying the signature. From c5565c8bbf014beb77b2a32af5916102740c28b2 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:57:40 +0200 Subject: [PATCH 053/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index ad28eec29..aa187f2b9 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -249,7 +249,7 @@ The ``revocation_assertion_responses`` object MUST contain the following mandato - the Revocation Assertions and or the Revocation Assertion Errors related to the request made by the Wallet Instance. - `OAUTH-STATUS-ASSERTION`_ draft 02`_. -The Revocation Assertion object MUST contain the parameter ``credential_status_validity`` with the value set to ``false`` and the parameter ``revoked`` set to ``true``. +The Revocation Assertion object MUST contain the parameter ``credential_status_validity`` with the value set to ``false``. Below a non-normative example of a Revocation Assertion object in JWT format, with the headers and payload represented in JSON and without applying the signature. .. code:: From 36393a3d110352aecc7c48cd7c6fc845c99c0ca5 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 15:59:49 +0200 Subject: [PATCH 054/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 4 ---- 1 file changed, 4 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index aa187f2b9..0b075403b 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -266,10 +266,6 @@ Below a non-normative example of a Revocation Assertion object in JWT format, wi "credential_hash": $CREDENTIAL-HASH, "credential_hash_alg": "sha-256", "credential_status_validity": false, - "credential_status": { - "revoked": true, - "suspended": false - }, "cnf": { "jwk": { "alg": "ES256", From 5d46c0cad1b01915838f98feaf5c38743c0340ab Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:11:24 +0200 Subject: [PATCH 055/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 0b075403b..2900eb691 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -425,7 +425,7 @@ A non-normative example of Credential Proof of Possession is provided :ref:`in t "status_assertion_responses": ["${base64url(json({typ: status-assertion+jwt, ...}))}.payload.signature", ... ] } -The member `status_assertion_responses` MUST be an array of strings, where each of them represent a Status Assertion Response object as defined in `[OAuth Status Attestation draft 01] `_. +The member `status_assertion_responses` MUST be an array of strings, where each of them represent a Status Assertion Response object as defined in `OAUTH-STATUS-ASSERTION`_ draft 02`_. Status Assertion HTTP Request From 7d091f5340df6ee4744539b33157a2c17134ec53 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:13:08 +0200 Subject: [PATCH 056/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 2900eb691..e9aa2152e 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -285,7 +285,6 @@ The Revocation Assertion Error object MUST contain the following parameters: Errors are meant to provide additional information about the failure so that the User can be informed and take the appropriate action. The `error` parameter for the Revocation Assertion Error object MUST be set with one of the values defined in the table below, in addition to the values specified in :rfc:`6749#section-5.2`: -Here's the fixed table in reStructuredText (reST) format: .. list-table:: :widths: 20 80 From 95d898aa77364233ede94f1cff7a40e3669bace1 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:14:56 +0200 Subject: [PATCH 057/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index e9aa2152e..e6cdfe451 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -440,7 +440,7 @@ The requests to the *Credential status endpoint* of the Credential Issuers MUST - **Description** - **Reference** * - **status_assertion_requests** - - It MUST be an array of strings, where each of them represent a Status Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession ` for more details. + - It MUST be an array of strings, where each of them represent a Status Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession `_ for more details. - `[OAuth Status Attestation draft 01] `_ The *typ* value in the *credential_pop* JWT MUST be set to **status-assertion+jwt** From 958f6b31fbd20902607a160b8d9135ffb6bf9630 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:15:45 +0200 Subject: [PATCH 058/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index e6cdfe451..1bfea3600 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -441,7 +441,7 @@ The requests to the *Credential status endpoint* of the Credential Issuers MUST - **Reference** * - **status_assertion_requests** - It MUST be an array of strings, where each of them represent a Status Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession `_ for more details. - - `[OAuth Status Attestation draft 01] `_ + - `OAUTH-STATUS-ASSERTION`_ draft 02. The *typ* value in the *credential_pop* JWT MUST be set to **status-assertion+jwt** From a8f56c0c82dcde36dbec1ccd33ee7bbdf484af65 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:16:26 +0200 Subject: [PATCH 059/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 1bfea3600..732d128db 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -471,7 +471,7 @@ It MUST contain the following mandatory claims. - **Reference** * - **status_assertion_responses** - the Status Assertions and or the Status Assertion Errors related to the request made by the Wallet Instance. - - `[OAuth Status Attestation draft 01] `_. + - `OAUTH-STATUS-ASSERTION`_ draft 02. The following HTTP Status Codes MUST be supported: From 3a14c6a96577cef26d2ff6fae8f7bb3ef5a34353 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:17:49 +0200 Subject: [PATCH 060/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 732d128db..e5bfb916a 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -574,7 +574,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT t - **Description** - **Reference** * - **typ** - - In case of revocation request it MUST be set to ``revocation-request+{jwt,cwt}``. In case of Status Assertion request it MUST be set to ``status-assertion-request+{jwt,cwt}``, according to `[OAuth Status Assertions] `_. + - In case of revocation request it MUST be set to ``revocation-request+{jwt,cwt}``. In case of Status Assertion request it MUST be set to ``status-assertion-request+{jwt,cwt}``, according to `OAUTH-STATUS-ASSERTION`_ draft 02. - :rfc:`7516#section-4.1.1`. * - **alg** - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. From 1042bb46507e6a9e4c2d12766134786c1dd2b925 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:19:23 +0200 Subject: [PATCH 061/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index e5bfb916a..5070e51d5 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -580,7 +580,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT t - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. - :rfc:`7516#section-4.1.1`. * - **kid** - - Unique identifier of the ``jwk`` or ``COSE_Key`` inside the ``cnf`` claim of the Credential to be revoked, as base64url-encoded JWK Thumbprint value, according to `[OAuth Status Assertions] `_. + - Unique identifier of the ``jwk`` or ``COSE_Key`` inside the ``cnf`` claim of the Credential to be revoked, as base64url-encoded JWK Thumbprint value, according to `OAUTH-STATUS-ASSERTION`_ draft 02. - :rfc:`7638#section_3`. .. list-table:: From a81c1de2ad42740c4f595c634812cd072de208e6 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:21:44 +0200 Subject: [PATCH 062/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 9 --------- 1 file changed, 9 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 5070e51d5..1887feaf1 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -611,15 +611,6 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT t * - **credential_hash_alg** - It MUST contain the Algorithm used for hashing the Digital Credential. The value SHOULD be set to `S256`. - `[OAuth Status Attestation draft 01] `_. - * - **credential_type** - - Type of credential (e.g., Personal Identification Data, European Disability Card, European Health Insurance Card, Driver's License, etc.) - - - * - **user_identifier** - - Identifier used to avoid direct linking between the credential hash and the owner. - - - * - **document_id** - - Unique identifier of the document to which the attestation refers. - - Revocation Assertion -------------------- From fe89b9d6ce6688e26704df5005b435c93a66b442 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:22:47 +0200 Subject: [PATCH 063/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 1887feaf1..e79ee9039 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -626,7 +626,7 @@ When the JWT or CWT format are used, the Revocation Assertion MUST contain the f - **Description** - **Reference** * - **alg** - - Algorithm used to verify the cryptographic signature of the Revocation Assertion. Revocation Assertion that do not need to be signed SHOULD set the `alg` value to `none` in according with `[OAuth Status Attestation draft 01] `_. + - Algorithm used to verify the cryptographic signature of the Revocation Assertion. Revocation Assertion that do not need to be signed SHOULD set the `alg` value to `none` in according with `OAUTH-STATUS-ASSERTION`_ draft 02. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - It MUST be set to `revocation-assertion-response+jwt` when JWT format is used. It MUST be set to `revocation-assertion-response+cwt` when CWT format is used. From ca09c25943f9b0100d19a48cd6b59adc6273988e Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:25:25 +0200 Subject: [PATCH 064/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index e79ee9039..3604045c4 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -630,7 +630,7 @@ When the JWT or CWT format are used, the Revocation Assertion MUST contain the f - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - It MUST be set to `revocation-assertion-response+jwt` when JWT format is used. It MUST be set to `revocation-assertion-response+cwt` when CWT format is used. - - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_.. + - [:rfc:`7515`], [:rfc:`7517`], `OAUTH-STATUS-ASSERTION`_ draft 02. .. _table_revocation_assertion_claim: From c29d043aaac57c2e950486f6b6a02dafad751c72 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:26:48 +0200 Subject: [PATCH 065/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 6 ------ 1 file changed, 6 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 3604045c4..9ffa9df90 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -650,12 +650,6 @@ When the JWT or CWT format are used, the Revocation Assertion MUST contain the f * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It MUST be set with the value `false`. - `[OAuth Status Attestation draft 01] `_. - * - **revoked** - - Boolean value indicating the status of Credential revocation. It MUST be set with the value `true` in revocation scenario. - - `[OAuth Status Attestation draft 01] `_. - * - **suspended** - - Boolean value indicating the status of Credential suspension. It MUST be set with the value `false` in revocation scenario. - - `[OAuth Status Attestation draft 01] `_. Status Assertion From 21337627586ee7cb87a39126f376c442fe9503c7 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:28:03 +0200 Subject: [PATCH 066/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 9ffa9df90..df517f9c0 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -694,7 +694,7 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - :rfc:`9126` and :rfc:`7519`. * - **credential_hash** - Hash value of the Credential the Status Assertion is bound to. - - `[OAuth Status Attestation draft 01] `_. + - `OAUTH-STATUS-ASSERTION`_ draft 02. * - **credential_hash_alg** - The Algorithm used for hashing the Credential to which the Status Assertion is bound. The value SHOULD be set to ``S256``. - `[OAuth Status Attestation draft 01] `_. From 89c4a9d5fcbb59f6a26f3f1a391d8ebc2cc384cc Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:29:01 +0200 Subject: [PATCH 067/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index df517f9c0..5ad9ec1e5 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -697,7 +697,7 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - `OAUTH-STATUS-ASSERTION`_ draft 02. * - **credential_hash_alg** - The Algorithm used for hashing the Credential to which the Status Assertion is bound. The value SHOULD be set to ``S256``. - - `[OAuth Status Attestation draft 01] `_. + - `OAUTH-STATUS-ASSERTION`_ draft 02. * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It is REQUIRED and it MUST be set with the value "false" or "true". - `[OAuth Status Attestation draft 01] `_. From d9ddb8dac61f18125a5cea4061162400201ceee4 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 16:30:39 +0200 Subject: [PATCH 068/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 5ad9ec1e5..93ee2fe9f 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -700,7 +700,7 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - `OAUTH-STATUS-ASSERTION`_ draft 02. * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It is REQUIRED and it MUST be set with the value "false" or "true". - - `[OAuth Status Attestation draft 01] `_. + - `OAUTH-STATUS-ASSERTION`_ draft 02. * - **revoked** - Boolean value indicating the status of Credential revocation when the `credential_status_validity` is set to `false`. It MAY be set with the value `false` or `true`. - `[OAuth Status Attestation draft 01] `_. From 50861b3151fd15eaefa4b7ac832369d073c4e662 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 17:01:56 +0200 Subject: [PATCH 069/105] Commit suggestion applied Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 5 ----- 1 file changed, 5 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 93ee2fe9f..5eda88c0c 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -701,11 +701,6 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It is REQUIRED and it MUST be set with the value "false" or "true". - `OAUTH-STATUS-ASSERTION`_ draft 02. - * - **revoked** - - Boolean value indicating the status of Credential revocation when the `credential_status_validity` is set to `false`. It MAY be set with the value `false` or `true`. - - `[OAuth Status Attestation draft 01] `_. - * - **suspended** - - Boolean value indicating the status of Credential suspension. It MAY be set with the value `false` or `true`. - `[OAuth Status Attestation draft 01] `_. * - **cnf** - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT and `Cose_Key` for CWT, MUST match with the one provided within the related Digital Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. From 2baf35d6880ac41d9b9d97a3deb8d208b559c3ad Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 17:09:49 +0200 Subject: [PATCH 070/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 5eda88c0c..22bd0ed1b 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -701,7 +701,7 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It is REQUIRED and it MUST be set with the value "false" or "true". - `OAUTH-STATUS-ASSERTION`_ draft 02. - - `[OAuth Status Attestation draft 01] `_. + - `OAUTH-STATUS-ASSERTION`_ draft 02. * - **cnf** - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT and `Cose_Key` for CWT, MUST match with the one provided within the related Digital Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. - `[RFC7800, Section 3.1] `_ and `[RFC8747, Section 3.1] `_. From 9c0958dd5a69fb0b50cd2c2c1b40531655cbebb5 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 17:16:44 +0200 Subject: [PATCH 071/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 22bd0ed1b..c2f944a70 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -721,7 +721,7 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU - **Description** - **Reference** * - **alg** - - Algorithm used to verify the cryptographic signature of the Assertion Error. Assertion Error that do not need to be signed SHOULD set the `alg` value to `none` in according with `[OAuth Status Attestation draft 01] `_. + - Algorithm used to verify the cryptographic signature of the Assertion Error. Assertion Error that do not need to be signed SHOULD set the `alg` value to `none` in according with `OAUTH-STATUS-ASSERTION`_ draft 02. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - It MUST be set to `status-assertion-response+jwt` or `revocation-assertion-response+jwt` when JWT format is used. It MUST be set to `status-assertion-response+cwt` or `revocation-assertion-response+cwt` when CWT format is used. From fc9c8b93c5485ee84669c1ea51f635ca1ba8e0be Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 17:17:53 +0200 Subject: [PATCH 072/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index c2f944a70..36eeb670a 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -725,7 +725,7 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - It MUST be set to `status-assertion-response+jwt` or `revocation-assertion-response+jwt` when JWT format is used. It MUST be set to `status-assertion-response+cwt` or `revocation-assertion-response+cwt` when CWT format is used. - - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_. + - [:rfc:`7515`], [:rfc:`7517`], `OAUTH-STATUS-ASSERTION`_ draft 02. .. _table_non_revocation_assertion_error_claim: From 40a8501076c93fccfe352fd1a9e8409db3ff0bcf Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 17:19:58 +0200 Subject: [PATCH 073/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 36eeb670a..3479a4fec 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -743,7 +743,7 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU - Unique identifier for the JWT. - `[RFC7519, Section 4.1.7] `_. * - **error** - - Status code returned from the Credential Issuer after revocation. The value SHOULD be assigned with one of the error types defined in {{RFC6749}}[Section 5.2] or defined in `[OAuth Status Attestation draft 01] `_ + - Status code returned from the Credential Issuer after revocation. The value SHOULD be assigned with one of the error types defined in {{RFC6749}}[Section 5.2] or defined in `OAUTH-STATUS-ASSERTION`_ draft 02. - `[RFC6749, Section 5.2] `_, `[OAuth Status Attestation draft 01] `_ * - **error_description** - Text that clarifies the nature of the error, such as attribute changes, revocation reasons, in relation to the `error` value. From 1af52f8503376e5ef1b422aa6f0c97186a29e3d6 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 17:24:23 +0200 Subject: [PATCH 074/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 3479a4fec..3a77a9a69 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -744,7 +744,7 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU - `[RFC7519, Section 4.1.7] `_. * - **error** - Status code returned from the Credential Issuer after revocation. The value SHOULD be assigned with one of the error types defined in {{RFC6749}}[Section 5.2] or defined in `OAUTH-STATUS-ASSERTION`_ draft 02. - - `[RFC6749, Section 5.2] `_, `[OAuth Status Attestation draft 01] `_ + - `[RFC6749, Section 5.2] `_, `OAUTH-STATUS-ASSERTION`_ draft 02 * - **error_description** - Text that clarifies the nature of the error, such as attribute changes, revocation reasons, in relation to the `error` value. - `[OAuth Status Attestation draft 01] `_. From 8c363dd9ba3bac8851a7e2f291533bc0af35aaa8 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 18 Jul 2024 17:24:53 +0200 Subject: [PATCH 075/105] external link fixed Co-authored-by: m-basili --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 3a77a9a69..bee5a2194 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -747,4 +747,4 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU - `[RFC6749, Section 5.2] `_, `OAUTH-STATUS-ASSERTION`_ draft 02 * - **error_description** - Text that clarifies the nature of the error, such as attribute changes, revocation reasons, in relation to the `error` value. - - `[OAuth Status Attestation draft 01] `_. + - `OAUTH-STATUS-ASSERTION`_ draft 02. From 97c9d01eb296f7a942323b6ab870bccb707e3600 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Fri, 19 Jul 2024 11:52:28 +0200 Subject: [PATCH 076/105] cwt occurences removed As CWT is not supported, all occurrences of CWT have been removed as requested in the comment https://github.com/italia/eudi-wallet-it-docs/pull/308/files#r1674043524 --- docs/en/revocation-lists.rst | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index bee5a2194..dff4ba17a 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -194,7 +194,7 @@ The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with me - **Description** - **Reference** * - **revocation_requests** - - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession `_ for more details. + - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession `_ for more details. - `OAUTH-STATUS-ASSERTION`_ draft 02. The Revocation Endpoint MUST be provided by the Credential Issuer within its Metadata. @@ -440,7 +440,7 @@ The requests to the *Credential status endpoint* of the Credential Issuers MUST - **Description** - **Reference** * - **status_assertion_requests** - - It MUST be an array of strings, where each of them represent a Status Assertion Request object. Each element MUST contain a signed JWT/CWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession `_ for more details. + - It MUST be an array of strings, where each of them represent a Status Assertion Request object. Each element MUST contain a signed JWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession `_ for more details. - `OAUTH-STATUS-ASSERTION`_ draft 02. The *typ* value in the *credential_pop* JWT MUST be set to **status-assertion+jwt** @@ -564,7 +564,7 @@ Law-Enforcement Authorities or Third Parties authorized by national law, MAY req Credential Proof of Possession ------------------------------ -The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT that MUST contain the parameters (Header and Payload) in the following table. +The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST contain the parameters (Header and Payload) in the following table. .. list-table:: :widths: 20 60 20 @@ -574,7 +574,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT t - **Description** - **Reference** * - **typ** - - In case of revocation request it MUST be set to ``revocation-request+{jwt,cwt}``. In case of Status Assertion request it MUST be set to ``status-assertion-request+{jwt,cwt}``, according to `OAUTH-STATUS-ASSERTION`_ draft 02. + - In case of revocation request it MUST be set to ``revocation-request+jwt``. In case of Status Assertion request it MUST be set to ``status-assertion-request+jwt``, according to `OAUTH-STATUS-ASSERTION`_ draft 02. - :rfc:`7516#section-4.1.1`. * - **alg** - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. @@ -594,13 +594,13 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT t - Thumbprint of the JWK in the ``cnf`` parameter of the Wallet Assertion. - :rfc:`9126` and :rfc:`7519`. * - **aud** - - It MUST be set to the Credential Issuer endpoint at which the JWT/CWT is used. + - It MUST be set to the Credential Issuer endpoint at which the JWT is used. - :rfc:`9126` and :rfc:`7519`. * - **exp** - - UNIX Timestamp with the expiry time of the JWT/CWT. It MUST be greater than the value set for `iat`. + - UNIX Timestamp with the expiry time of the JWT. It MUST be greater than the value set for `iat`. - :rfc:`9126` and :rfc:`7519`. * - **iat** - - UNIX Timestamp with the time of JWT/CWT issuance. + - UNIX Timestamp with the time of JWT issuance. - :rfc:`9126` and :rfc:`7519`. * - **jti** - Unique identifier for the PoP proof JWT. The value SHOULD be set using a *UUID v4* value according to [:rfc:`4122`]. @@ -615,7 +615,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT or a CWT t Revocation Assertion -------------------- -When the JWT or CWT format are used, the Revocation Assertion MUST contain the following claims. +When the JWT format is used, the Revocation Assertion MUST contain the following claims. .. _table_revocation_assertion_header: .. list-table:: @@ -629,7 +629,7 @@ When the JWT or CWT format are used, the Revocation Assertion MUST contain the f - Algorithm used to verify the cryptographic signature of the Revocation Assertion. Revocation Assertion that do not need to be signed SHOULD set the `alg` value to `none` in according with `OAUTH-STATUS-ASSERTION`_ draft 02. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - - It MUST be set to `revocation-assertion-response+jwt` when JWT format is used. It MUST be set to `revocation-assertion-response+cwt` when CWT format is used. + - It MUST be set to `revocation-assertion-response+jwt` when JWT format is used. - [:rfc:`7515`], [:rfc:`7517`], `OAUTH-STATUS-ASSERTION`_ draft 02. @@ -655,7 +655,7 @@ When the JWT or CWT format are used, the Revocation Assertion MUST contain the f Status Assertion ------------------ -When the JWT or CWT format are used, the Status Assertion MUST contain the following claims. +When the JWT format is used, the Status Assertion MUST contain the following claims. .. _table_non_revocation_assertion_header: .. list-table:: @@ -669,7 +669,7 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms in Section :ref:`Cryptographic Algorithms ` and MUST NOT be set to ``none`` or to a symmetric algorithm (MAC) identifier. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - - It MUST be set to `status-assertion-request+jwt` when JWT format is used. It MUST be set to `status-assertion-request+cwt` when CWT format is used. + - It MUST be set to `status-assertion-request+jwt` when JWT format is used. - [:rfc:`7515`], [:rfc:`7517`], `[OAuth Status Attestation draft 01] `_.. * - **kid** - Unique identifier of the Credential Issuer ``jwk`` as base64url-encoded JWK Thumbprint value. @@ -687,10 +687,10 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - It MUST be set to the identifier of the Credential Issuer. - :rfc:`9126` and :rfc:`7519`. * - **iat** - - UNIX Timestamp with the time of JWT/CWT issuance. + - UNIX Timestamp with the time of JWT issuance. - :rfc:`9126` and :rfc:`7519`. * - **exp** - - UNIX Timestamp with the expiry time of the JWT/CWT. It MUST be greater than the value set for `iat`. + - UNIX Timestamp with the expiry time of the JWT. It MUST be greater than the value set for `iat`. - :rfc:`9126` and :rfc:`7519`. * - **credential_hash** - Hash value of the Credential the Status Assertion is bound to. @@ -703,14 +703,14 @@ When the JWT or CWT format are used, the Status Assertion MUST contain the follo - `OAUTH-STATUS-ASSERTION`_ draft 02. - `OAUTH-STATUS-ASSERTION`_ draft 02. * - **cnf** - - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT and `Cose_Key` for CWT, MUST match with the one provided within the related Digital Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. + - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT, MUST match with the one provided within the related Digital Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. - `[RFC7800, Section 3.1] `_ and `[RFC8747, Section 3.1] `_. Error Assertion ------------------ -When the JWT or CWT format are used, the Revocation or Status Assertion Error MUST contain the following claims. +When the JWT format is used, the Revocation or Status Assertion Error MUST contain the following claims. .. _table_non_revocation_assertion_error_header: .. list-table:: @@ -724,7 +724,7 @@ When the JWT or CWT format are used, the Revocation or Status Assertion Error MU - Algorithm used to verify the cryptographic signature of the Assertion Error. Assertion Error that do not need to be signed SHOULD set the `alg` value to `none` in according with `OAUTH-STATUS-ASSERTION`_ draft 02. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - - It MUST be set to `status-assertion-response+jwt` or `revocation-assertion-response+jwt` when JWT format is used. It MUST be set to `status-assertion-response+cwt` or `revocation-assertion-response+cwt` when CWT format is used. + - It MUST be set to `status-assertion-response+jwt` or `revocation-assertion-response+jwt` when JWT format is used. - [:rfc:`7515`], [:rfc:`7517`], `OAUTH-STATUS-ASSERTION`_ draft 02. From 84bf2ea3217c44f5a44276774025b6b9f7257718 Mon Sep 17 00:00:00 2001 From: Marco Basili Date: Fri, 19 Jul 2024 16:20:08 +0200 Subject: [PATCH 077/105] fix: table error fixed --- docs/en/revocation-lists.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index dff4ba17a..8c2ece537 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -701,7 +701,6 @@ When the JWT format is used, the Status Assertion MUST contain the following cla * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It is REQUIRED and it MUST be set with the value "false" or "true". - `OAUTH-STATUS-ASSERTION`_ draft 02. - - `OAUTH-STATUS-ASSERTION`_ draft 02. * - **cnf** - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT, MUST match with the one provided within the related Digital Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. - `[RFC7800, Section 3.1] `_ and `[RFC8747, Section 3.1] `_. From a5e0736e93797a07e0da327028fae1acaf5dbeea Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:14:43 +0200 Subject: [PATCH 078/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 8c2ece537..983cd4cc6 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -649,7 +649,7 @@ When the JWT format is used, the Revocation Assertion MUST contain the following - `[RFC7519, Section 4.1.7] `_. * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It MUST be set with the value `false`. - - `[OAuth Status Attestation draft 01] `_. + - `OAUTH-STATUS-ASSERTION`_. Status Assertion From e60774cf24e527799540b0c02b621f77823f5005 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:15:02 +0200 Subject: [PATCH 079/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 983cd4cc6..3e84f7804 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -694,7 +694,7 @@ When the JWT format is used, the Status Assertion MUST contain the following cla - :rfc:`9126` and :rfc:`7519`. * - **credential_hash** - Hash value of the Credential the Status Assertion is bound to. - - `OAUTH-STATUS-ASSERTION`_ draft 02. + - `OAUTH-STATUS-ASSERTION`_. * - **credential_hash_alg** - The Algorithm used for hashing the Credential to which the Status Assertion is bound. The value SHOULD be set to ``S256``. - `OAUTH-STATUS-ASSERTION`_ draft 02. From ec83559d4f0c858668edf34e85556179daa1c0a3 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:19:06 +0200 Subject: [PATCH 080/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 3e84f7804..aaabde4bc 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -697,7 +697,7 @@ When the JWT format is used, the Status Assertion MUST contain the following cla - `OAUTH-STATUS-ASSERTION`_. * - **credential_hash_alg** - The Algorithm used for hashing the Credential to which the Status Assertion is bound. The value SHOULD be set to ``S256``. - - `OAUTH-STATUS-ASSERTION`_ draft 02. + - `OAUTH-STATUS-ASSERTION`_. * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It is REQUIRED and it MUST be set with the value "false" or "true". - `OAUTH-STATUS-ASSERTION`_ draft 02. From 699d928707084ceea583b7584f266ac8740998e4 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:20:31 +0200 Subject: [PATCH 081/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index aaabde4bc..aee46f8ce 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -700,7 +700,7 @@ When the JWT format is used, the Status Assertion MUST contain the following cla - `OAUTH-STATUS-ASSERTION`_. * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It is REQUIRED and it MUST be set with the value "false" or "true". - - `OAUTH-STATUS-ASSERTION`_ draft 02. + - `OAUTH-STATUS-ASSERTION`_. * - **cnf** - JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT, MUST match with the one provided within the related Digital Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. - `[RFC7800, Section 3.1] `_ and `[RFC8747, Section 3.1] `_. From ad89df2ba31050c23da3d88853369f931135855f Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:21:37 +0200 Subject: [PATCH 082/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index aee46f8ce..99f600289 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -720,7 +720,7 @@ When the JWT format is used, the Revocation or Status Assertion Error MUST conta - **Description** - **Reference** * - **alg** - - Algorithm used to verify the cryptographic signature of the Assertion Error. Assertion Error that do not need to be signed SHOULD set the `alg` value to `none` in according with `OAUTH-STATUS-ASSERTION`_ draft 02. + - Algorithm used to verify the cryptographic signature of the Assertion Error. Assertion Error that do not need to be signed SHOULD set the `alg` value to `none` in according with `OAUTH-STATUS-ASSERTION`_. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - It MUST be set to `status-assertion-response+jwt` or `revocation-assertion-response+jwt` when JWT format is used. From 21ae7949d879e01afff7335dffde2776b714cbc7 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:22:06 +0200 Subject: [PATCH 083/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 99f600289..b2f4c2f0a 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -724,7 +724,7 @@ When the JWT format is used, the Revocation or Status Assertion Error MUST conta - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - It MUST be set to `status-assertion-response+jwt` or `revocation-assertion-response+jwt` when JWT format is used. - - [:rfc:`7515`], [:rfc:`7517`], `OAUTH-STATUS-ASSERTION`_ draft 02. + - [:rfc:`7515`], [:rfc:`7517`], `OAUTH-STATUS-ASSERTION`_ . .. _table_non_revocation_assertion_error_claim: From 9e6a84d63b0c2b555c2bfe14e0db02a6dc9f5a7e Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:22:33 +0200 Subject: [PATCH 084/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index b2f4c2f0a..c458055d5 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -742,7 +742,7 @@ When the JWT format is used, the Revocation or Status Assertion Error MUST conta - Unique identifier for the JWT. - `[RFC7519, Section 4.1.7] `_. * - **error** - - Status code returned from the Credential Issuer after revocation. The value SHOULD be assigned with one of the error types defined in {{RFC6749}}[Section 5.2] or defined in `OAUTH-STATUS-ASSERTION`_ draft 02. + - Status code returned from the Credential Issuer after revocation. The value SHOULD be assigned with one of the error types defined in {{RFC6749}}[Section 5.2] or defined in `OAUTH-STATUS-ASSERTION`_. - `[RFC6749, Section 5.2] `_, `OAUTH-STATUS-ASSERTION`_ draft 02 * - **error_description** - Text that clarifies the nature of the error, such as attribute changes, revocation reasons, in relation to the `error` value. From c639d5567b12f81facfa414cf7b466f9e0a33368 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:22:51 +0200 Subject: [PATCH 085/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index c458055d5..df35273c1 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -743,7 +743,7 @@ When the JWT format is used, the Revocation or Status Assertion Error MUST conta - `[RFC7519, Section 4.1.7] `_. * - **error** - Status code returned from the Credential Issuer after revocation. The value SHOULD be assigned with one of the error types defined in {{RFC6749}}[Section 5.2] or defined in `OAUTH-STATUS-ASSERTION`_. - - `[RFC6749, Section 5.2] `_, `OAUTH-STATUS-ASSERTION`_ draft 02 + - `[RFC6749, Section 5.2] `_, `OAUTH-STATUS-ASSERTION`_ * - **error_description** - Text that clarifies the nature of the error, such as attribute changes, revocation reasons, in relation to the `error` value. - `OAUTH-STATUS-ASSERTION`_ draft 02. From 23f9a51f5b2ce29677191bfa8da0b0c10ac00379 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:23:13 +0200 Subject: [PATCH 086/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index df35273c1..313978a32 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -746,4 +746,4 @@ When the JWT format is used, the Revocation or Status Assertion Error MUST conta - `[RFC6749, Section 5.2] `_, `OAUTH-STATUS-ASSERTION`_ * - **error_description** - Text that clarifies the nature of the error, such as attribute changes, revocation reasons, in relation to the `error` value. - - `OAUTH-STATUS-ASSERTION`_ draft 02. + - `OAUTH-STATUS-ASSERTION`_. From 6d3289f1c99a17078954349a0ed7fdfe6bce0a1f Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:23:34 +0200 Subject: [PATCH 087/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 313978a32..366e12cbf 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -630,7 +630,7 @@ When the JWT format is used, the Revocation Assertion MUST contain the following - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - It MUST be set to `revocation-assertion-response+jwt` when JWT format is used. - - [:rfc:`7515`], [:rfc:`7517`], `OAUTH-STATUS-ASSERTION`_ draft 02. + - [:rfc:`7515`], [:rfc:`7517`], `OAUTH-STATUS-ASSERTION`_. .. _table_revocation_assertion_claim: From affcd1e00c4208b03594887c8d3dac2ff5c0a501 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:24:03 +0200 Subject: [PATCH 088/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 366e12cbf..a371a6efc 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -626,7 +626,7 @@ When the JWT format is used, the Revocation Assertion MUST contain the following - **Description** - **Reference** * - **alg** - - Algorithm used to verify the cryptographic signature of the Revocation Assertion. Revocation Assertion that do not need to be signed SHOULD set the `alg` value to `none` in according with `OAUTH-STATUS-ASSERTION`_ draft 02. + - Algorithm used to verify the cryptographic signature of the Revocation Assertion. Revocation Assertion that do not need to be signed SHOULD set the `alg` value to `none` in according with `OAUTH-STATUS-ASSERTION`_. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **typ** - It MUST be set to `revocation-assertion-response+jwt` when JWT format is used. From acf73f0883cb4da102add74fce2bd31a7ec8e0d0 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:24:26 +0200 Subject: [PATCH 089/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index a371a6efc..959f902a7 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -610,7 +610,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - `[OAuth Status Attestation draft 01] `_. * - **credential_hash_alg** - It MUST contain the Algorithm used for hashing the Digital Credential. The value SHOULD be set to `S256`. - - `[OAuth Status Attestation draft 01] `_. + - `OAUTH-STATUS-ASSERTION`_. Revocation Assertion -------------------- From b87243d1f2486e19eb9a9af47272843fe9f43aac Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:25:16 +0200 Subject: [PATCH 090/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 959f902a7..dbbcccaba 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -580,7 +580,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. - :rfc:`7516#section-4.1.1`. * - **kid** - - Unique identifier of the ``jwk`` or ``COSE_Key`` inside the ``cnf`` claim of the Credential to be revoked, as base64url-encoded JWK Thumbprint value, according to `OAUTH-STATUS-ASSERTION`_ draft 02. + - Unique identifier of the ``jwk`` or ``COSE_Key`` inside the ``cnf`` claim of the Credential to be revoked, as base64url-encoded JWK Thumbprint value, according to `OAUTH-STATUS-ASSERTION`_. - :rfc:`7638#section_3`. .. list-table:: From 4627e0efb1ee9cf5fdf33183f40d26502aaba8d0 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:25:46 +0200 Subject: [PATCH 091/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index dbbcccaba..bba245aaa 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -574,7 +574,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - **Description** - **Reference** * - **typ** - - In case of revocation request it MUST be set to ``revocation-request+jwt``. In case of Status Assertion request it MUST be set to ``status-assertion-request+jwt``, according to `OAUTH-STATUS-ASSERTION`_ draft 02. + - In case of revocation request it MUST be set to ``revocation-request+jwt``. In case of Status Assertion request it MUST be set to ``status-assertion-request+jwt``, according to `OAUTH-STATUS-ASSERTION`_ . - :rfc:`7516#section-4.1.1`. * - **alg** - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. From fca8a86a475b2c3108879aa3268f8fbe9a98067e Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:26:46 +0200 Subject: [PATCH 092/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index bba245aaa..52e87ff50 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -471,7 +471,7 @@ It MUST contain the following mandatory claims. - **Reference** * - **status_assertion_responses** - the Status Assertions and or the Status Assertion Errors related to the request made by the Wallet Instance. - - `OAUTH-STATUS-ASSERTION`_ draft 02. + - `OAUTH-STATUS-ASSERTION`_. The following HTTP Status Codes MUST be supported: From 7141d6f5ba6ea69a439b3307b86a69660f1db108 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:27:12 +0200 Subject: [PATCH 093/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 52e87ff50..9d7f8e706 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -441,7 +441,7 @@ The requests to the *Credential status endpoint* of the Credential Issuers MUST - **Reference** * - **status_assertion_requests** - It MUST be an array of strings, where each of them represent a Status Assertion Request object. Each element MUST contain a signed JWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession `_ for more details. - - `OAUTH-STATUS-ASSERTION`_ draft 02. + - `OAUTH-STATUS-ASSERTION`_ . The *typ* value in the *credential_pop* JWT MUST be set to **status-assertion+jwt** From b03afaef2598832d3ddd14ca74a18f339811ac96 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:27:30 +0200 Subject: [PATCH 094/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 9d7f8e706..50d0861bb 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -424,7 +424,7 @@ A non-normative example of Credential Proof of Possession is provided :ref:`in t "status_assertion_responses": ["${base64url(json({typ: status-assertion+jwt, ...}))}.payload.signature", ... ] } -The member `status_assertion_responses` MUST be an array of strings, where each of them represent a Status Assertion Response object as defined in `OAUTH-STATUS-ASSERTION`_ draft 02`_. +The member `status_assertion_responses` MUST be an array of strings, where each of them represent a Status Assertion Response object as defined in `OAUTH-STATUS-ASSERTION`_. Status Assertion HTTP Request From 3099b85150b3f963229c45ec4ce472ba603a92cc Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:27:49 +0200 Subject: [PATCH 095/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 50d0861bb..9461e531b 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -195,7 +195,7 @@ The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with me - **Reference** * - **revocation_requests** - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession `_ for more details. - - `OAUTH-STATUS-ASSERTION`_ draft 02. + - `OAUTH-STATUS-ASSERTION`_ . The Revocation Endpoint MUST be provided by the Credential Issuer within its Metadata. From c18418ec73c2cebdb48d747d754f8fff06a46c39 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:28:17 +0200 Subject: [PATCH 096/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 9461e531b..64ff5f0d0 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -40,7 +40,7 @@ Operational Requirements Functional Requirements ----------------------- -In addition to the requirements in Section 5 of `OAUTH-STATUS-ASSERTION`_ draft 02, **The Status Assertion:** +In addition to the requirements in Section 5 of `OAUTH-STATUS-ASSERTION`_, **The Status Assertion:** - MUST have a validity period not greater than 24 hours; - MUST NOT reveal any information about the Relying Party, the User's device or the User's data contained in the Digital Credential the assertion is related to; From dc9c8ed82b657bef8152a158303b3f4f32b4db3d Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 25 Jul 2024 12:28:32 +0200 Subject: [PATCH 097/105] Applied code review suggestion Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 64ff5f0d0..191f4e30b 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -11,7 +11,7 @@ For these reasons a robust mechanism for managing the life-cycle and the revocat This section outlines the key technical requirements and processes related to the revocation of Digital Credentials. Furthermore, it provides the technical details that the Verifiers MUST implement to verify, in a secure and reliable manner, the validity of a Digital Credential during the presentation phase. -The verification of the validity of a Digital Credential is based on the `OAUTH-STATUS-ASSERTION`_ draft 02. +The verification of the validity of a Digital Credential is based on the `OAUTH-STATUS-ASSERTION`_. A Status Assertion is a signed document serving as proof of a Digital Credential's current validity status. The Credential Issuer provides these assertions to Holders who can present them to Verifiers together with the corresponding Digital Credentials. From 19f4cd0dc559cd3a7e04c7f1b61a8aa5d338b647 Mon Sep 17 00:00:00 2001 From: Marco Basili Date: Fri, 26 Jul 2024 15:58:45 +0200 Subject: [PATCH 098/105] fix: Alignment with the current draft status --- docs/common/standards.rst | 2 + docs/en/revocation-lists.rst | 73 ++++++++++++++++++------------------ 2 files changed, 38 insertions(+), 37 deletions(-) diff --git a/docs/common/standards.rst b/docs/common/standards.rst index c60f5b327..46f6297c9 100644 --- a/docs/common/standards.rst +++ b/docs/common/standards.rst @@ -55,3 +55,5 @@ Technical References - D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, D. Waite, "OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)". * - `OPENID4VC-HAIP`_ - Lodderstedt, T., K. Yasuda, "OpenID4VC High Assurance Interoperability Profile with SD-JWT VC". + * - `OAUTH-STATUS-ASSERTION`_ + - De Marco, G., Steele, O., Marino, F., "OpenID4VC High Assurance Interoperability Profile with SD-JWT VC", June 2024, Draft 2. diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 191f4e30b..9abb3c8d0 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -203,17 +203,11 @@ The Revocation Endpoint MUST be provided by the Credential Issuer within its Met Credential Revocation HTTP Response ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The *Credential Issuer* MUST return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Revocation Assertion object. The status code 200 MUST be returned if the Revocation Assertion is requested for a valid, non-existent, expired, already revoked or invalid Digital Credential. +In case of succesfully Revocation Request validation, the *Credential Issuer* MUST return an HTTP response with the status code set to 200. If the *Credential Issuer* is able to provide a valid Status Assertion for a requested Credential, the response MUST contains a revocation Assertion object within a JSON Array. Otherwise, a Revocation Assertion Errors related to that Credential MUST be included in the Response JSON Array as an entry. -The response MUST: - -- include a JSON object with a member named `revocation_assertion_responses`; +If the Revocation Request fails (e.g. invalid request, server unavailability, etc.), an HTTP Error Status Code MUST be provided within the Revocation Response. -- be encoded in ``application/json`` format. - -Otherwise, an HTTP error response MUST be provided by the Credential Issuer using status codes according to the table below. - -The following HTTP Status Codes MUST be supported: +In the following table are listed HTTP Status Codes that MUST be supported: .. list-table:: :widths: 20 20 60 @@ -235,6 +229,13 @@ The following HTTP Status Codes MUST be supported: - - The Credential Issuer is temporary unavailable. (:rfc:`6749#section-5.2`). +The response MUST: + +- include a JSON object with a member named `revocation_assertion_responses`; + +- be encoded in ``application/json`` format. + + The ``revocation_assertion_responses`` object MUST contain the following mandatory claims. .. _table_http_response_claim: @@ -247,7 +248,7 @@ The ``revocation_assertion_responses`` object MUST contain the following mandato - **Reference** * - **revocation_assertion_responses** - the Revocation Assertions and or the Revocation Assertion Errors related to the request made by the Wallet Instance. - - `OAUTH-STATUS-ASSERTION`_ draft 02`_. + - `OAUTH-STATUS-ASSERTION`_. The Revocation Assertion object MUST contain the parameter ``credential_status_validity`` with the value set to ``false``. Below a non-normative example of a Revocation Assertion object in JWT format, with the headers and payload represented in JSON and without applying the signature. @@ -256,7 +257,7 @@ Below a non-normative example of a Revocation Assertion object in JWT format, wi { "alg": "ES256", - "typ": "revocation-error+jwt", + "typ": "revocation-assertion+jwt", "kid": "Issuer-JWK-KID" } . @@ -451,30 +452,11 @@ The *Credential status endpoint* MUST be provided by the Credential Issuers with Status Assertion HTTP Response ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The *Credential Issuer* MUST return an HTTP response with the status code set to 200 and the `status_assertion_responses` array with the related Status Assertion object. The status code 200 MUST be returned if the Status Assertion is requested for a valid, non-existent, expired, revoked or invalid Digital Credential. - -The response MUST: - -- include a JSON object with a member named `status_assertion_responses`; - -- be encoded in ``application/json`` format. - -It MUST contain the following mandatory claims. - -.. _table_http_status_assertion_response_claim: -.. list-table:: - :widths: 20 60 20 - :header-rows: 1 - - * - **Claim** - - **Description** - - **Reference** - * - **status_assertion_responses** - - the Status Assertions and or the Status Assertion Errors related to the request made by the Wallet Instance. - - `OAUTH-STATUS-ASSERTION`_. +In case of succesfully Status Assertion Request validation, the *Credential Issuer* MUST return an HTTP response with the status code set to 200. If the *Credential Issuer* is able to provide a valid Status Assertion for a requested Credential, the response MUST contains a Status Assertion object within a JSON Array. Otherwise, a Status Assertion Errors related to that Credential MUST be included in the Response JSON Array as an entry. +If the Status Request fails (e.g. invalid request, server unavailability, etc.), an HTTP Error Status Code MUST be provided within the Status Assertion Response. -The following HTTP Status Codes MUST be supported: +In the following table are listed HTTP Status Codes that MUST be supported: .. list-table:: :widths: 20 20 60 @@ -489,9 +471,6 @@ The following HTTP Status Codes MUST be supported: * - *400 Bad Request* - Error code and description - The Credential Issuer cannot fulfill the request because of invalid parameters. - * - *404 Not Found* - - - - The Digital Credential may not be found by the Issuer, or the Status Attestation cannot be issued because the Credential has been revoked or updated. * - *500 Internal Server Error* - - The Credential Issuer encountered an internal problem. (:rfc:`6749#section-5.2`). @@ -499,6 +478,26 @@ The following HTTP Status Codes MUST be supported: - - The Credential Issuer is temporary unavailable. (:rfc:`6749#section-5.2`). +The response MUST: + +- include a JSON object with a member named `status_assertion_responses`; + +- be encoded in ``application/json`` format. + +The status_assertion_responses object MUST contain the following mandatory claims. + +.. _table_http_status_assertion_response_claim: +.. list-table:: + :widths: 20 60 20 + :header-rows: 1 + + * - **Claim** + - **Description** + - **Reference** + * - **status_assertion_responses** + - the Status Assertions and or the Status Assertion Errors related to the request made by the Wallet Instance. + - `OAUTH-STATUS-ASSERTION`_. + The Status Assertion Error object MUST contain the following parameters: - *error*. The error code, as registerd in the table below; @@ -607,7 +606,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - [:rfc:`7519`. Section 4.1.7]. * - **credential_hash** - It MUST contain the hash value of a Digital Credential, derived by computing the base64url encoded hash of the Digital Credential. - - `[OAuth Status Attestation draft 01] `_. + - `OAUTH-STATUS-ASSERTION`_. * - **credential_hash_alg** - It MUST contain the Algorithm used for hashing the Digital Credential. The value SHOULD be set to `S256`. - `OAUTH-STATUS-ASSERTION`_. From 91c645122d5f7ef7e286b7c999d3848fb2566724 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Mon, 29 Jul 2024 16:23:01 +0200 Subject: [PATCH 099/105] external links fixed --- docs/en/revocation-lists.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 9abb3c8d0..542fd279c 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -194,7 +194,7 @@ The requests to the *Credential Issuer Revocation endpoint* MUST be HTTP with me - **Description** - **Reference** * - **revocation_requests** - - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession `_ for more details. + - It MUST be an array of strings, where each represents a Revocation Assertion Request object. Each element MUST contain a signed JWT as a cryptographic proof of possession to which the Digital Credential to be revoked shall be bound. See Section :ref:`Credential Proof of Possession ` for more details. - `OAUTH-STATUS-ASSERTION`_ . The Revocation Endpoint MUST be provided by the Credential Issuer within its Metadata. @@ -441,7 +441,7 @@ The requests to the *Credential status endpoint* of the Credential Issuers MUST - **Description** - **Reference** * - **status_assertion_requests** - - It MUST be an array of strings, where each of them represent a Status Assertion Request object. Each element MUST contain a signed JWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession `_ for more details. + - It MUST be an array of strings, where each of them represent a Status Assertion Request object. Each element MUST contain a signed JWT as a cryptographic proof of possession of the Digital Credential. See Section :ref:`Credential Proof of Possession ` for more details. - `OAUTH-STATUS-ASSERTION`_ . The *typ* value in the *credential_pop* JWT MUST be set to **status-assertion+jwt** From 6c58779956da9c63daa233cb577c11486749a2af Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Tue, 30 Jul 2024 11:12:11 +0200 Subject: [PATCH 100/105] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index 542fd279c..b37e2a8ec 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -21,7 +21,7 @@ The Status Assertions have the following features: - verification of the Digital Credential validity status in both online and offline scenarios; - privacy-preserving, according to the following evidences: - 1. the Verifier cannot check over time the validity of a given Digital Credential related to the User; + 1. the Verifier can check the validity of the Credential during the presentation phase. It is not able to check the validity of a given Digital Credential related to the User over time and out of the scope of the User authentication; 2. the Credential Issuers cannot track when and where a Digital Credential is verified; 3. it doesn't reveal any information about the Users or the content of their Digital Credentials. From 72391c8ed5248433a3ed0fa822678e5138dbcdcd Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Tue, 30 Jul 2024 11:12:26 +0200 Subject: [PATCH 101/105] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index b37e2a8ec..d9050ba81 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -22,7 +22,7 @@ The Status Assertions have the following features: - privacy-preserving, according to the following evidences: 1. the Verifier can check the validity of the Credential during the presentation phase. It is not able to check the validity of a given Digital Credential related to the User over time and out of the scope of the User authentication; - 2. the Credential Issuers cannot track when and where a Digital Credential is verified; + 2. the Credential Issuers is not able to know to which Verifier the Digital Credential or the Status Assertion will be presented; 3. it doesn't reveal any information about the Users or the content of their Digital Credentials. .. _sec_revocation_assumption: From c850c021ddd5037009469775728b67fd0e2a7ed7 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Tue, 30 Jul 2024 11:21:06 +0200 Subject: [PATCH 102/105] Duplicated RFC 7519 removed RFC 7519 reference retained only in the standards.rst file. --- docs/common/common_definitions.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/common/common_definitions.rst b/docs/common/common_definitions.rst index c4af0ba03..da0322ca9 100644 --- a/docs/common/common_definitions.rst +++ b/docs/common/common_definitions.rst @@ -54,7 +54,6 @@ .. _PresentationExch: https://identity.foundation/presentation-exchange/spec/v2.0.0 .. _JARM: https://openid.net/specs/oauth-v2-jarm-final.html .. _RFC 9449: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop -.. _RFC 7519: https://www.rfc-editor.org/rfc/rfc7519 .. _OAUTH2: https://www.rfc-editor.org/rfc/rfc6749 .. _OPENID4VC-HAIP: https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.html .. _OAUTH-STATUS-ASSERTION: https://datatracker.ietf.org/doc/draft-demarco-oauth-status-assertions/02/ From fb346c899adb0a99cec6810f0dafe6058eb9e220 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Tue, 30 Jul 2024 11:39:11 +0200 Subject: [PATCH 103/105] RFC 7519 referencing fixed --- docs/en/revocation-lists.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index d9050ba81..e4f59b38e 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -603,7 +603,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - :rfc:`9126` and :rfc:`7519`. * - **jti** - Unique identifier for the PoP proof JWT. The value SHOULD be set using a *UUID v4* value according to [:rfc:`4122`]. - - [:rfc:`7519`. Section 4.1.7]. + - :rfc:`7519#section-4.1.7`. * - **credential_hash** - It MUST contain the hash value of a Digital Credential, derived by computing the base64url encoded hash of the Digital Credential. - `OAUTH-STATUS-ASSERTION`_. @@ -645,7 +645,7 @@ When the JWT format is used, the Revocation Assertion MUST contain the following - :rfc:`9126` and :rfc:`7519`. * - **jti** - Unique identifier for the JWT. - - `[RFC7519, Section 4.1.7] `_. + - :rfc:`7519#section-4.1.7`. * - **credential_status_validity** - Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. It MUST be set with the value `false`. - `OAUTH-STATUS-ASSERTION`_. @@ -739,7 +739,7 @@ When the JWT format is used, the Revocation or Status Assertion Error MUST conta - :rfc:`9126` and :rfc:`7519`. * - **jti** - Unique identifier for the JWT. - - `[RFC7519, Section 4.1.7] `_. + - :rfc:`7519#section-4.1.7`. * - **error** - Status code returned from the Credential Issuer after revocation. The value SHOULD be assigned with one of the error types defined in {{RFC6749}}[Section 5.2] or defined in `OAUTH-STATUS-ASSERTION`_. - `[RFC6749, Section 5.2] `_, `OAUTH-STATUS-ASSERTION`_ From 2f0fb85b8900f999d5e047e9d3b636b7f9e09429 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Tue, 30 Jul 2024 11:40:16 +0200 Subject: [PATCH 104/105] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index e4f59b38e..c82459661 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -161,7 +161,7 @@ Below, is given a non-normative example of a single Revocation Assertion Request "exp": 1698744139, "jti": "6f204f7e-e453-4dfd-814e-9d155319408c", "credential_hash": $Issuer-Signed-JWT-Hash, - "credential_hash_alg": "sha-256", + "credential_hash_alg": "sha-256" } **Step 2 (PoP verification)**: The Credential Issuer verifies the proof of possession of the Credential requested to be revoked, using the the confirmation method that was attested in the Credential. If the verification is successful the revocation request is allowed. From 30617653d33080285a5cd2bafafb635589f1bb6f Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Wed, 31 Jul 2024 11:26:35 +0200 Subject: [PATCH 105/105] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- docs/en/revocation-lists.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index c82459661..a4dff0070 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -269,7 +269,6 @@ Below a non-normative example of a Revocation Assertion object in JWT format, wi "credential_status_validity": false, "cnf": { "jwk": { - "alg": "ES256", "kty": "EC", "crv": "P-256", "x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc",