Deploy to GitHub pages

refs/pull/432/merge/en/_sources/pid-eaa-entity-configuration.rst.txt

@@ -118,12 +118,6 @@ The *openid_credential_issuer* metadata MUST contain the following claims.
 
                 - **name**: String value of a display name for the claim.
                 - **locale**: String value that identifies the language of this object represented as a language tag taken from values defined in *BCP47* :rfc:`5646`. There MUST be only one object for each language identifier.
-  * - **credential_status_detail_supported**
-    - JSON object that outlines the details of each validity status supported by the PID/(Q)EAA Provider related to the Credentials issued. It contains ``Display`` array containing a list of states with the corresponding descriptions and language identifiers. The parameter that MUST be included are:
-
-        - **state**: String value of a Credential status supported.
-        - **description**: String containing the description of the status related to this object.
-        - **locale**: String value that identifies the language of this object represented as a language tag taken from values defined in *BCP47* :rfc:`5646`. There MUST be only one object for each language identifier.
   * - **jwks**
     - JSON Web Key Set document, passed by value, containing the protocol specific keys for the Credential Issuer. See `OID-FED`_ Section 5.2.1 and `JWK`_.
 

refs/pull/432/merge/en/_sources/pid-eaa-issuance.rst.txt

@@ -125,7 +125,7 @@ The PID/(Q)EAA Provider performs the following checks upon the receipt of the PA
     2. It MUST check that the used algorithm for signing the request in the ``alg`` header is one of the listed within the Section `Cryptographic Algorithms <algorithms.html>`_.
     3. It MUST check that the ``client_id`` in the request body of the PAR request matches the ``client_id`` claim included in the Request Object.
     4. It MUST check that the ``iss`` claim in the Request Object matches the ``client_id`` claim in the Request Object (:rfc:`9126`, :rfc:`9101`).
-    5. It MUST check that the ``aud`` claim in the Request Object is equal to the PID/(Q)EAA Provider authorization endpoint uri (:rfc:`9126`, :rfc:`9101`).
+    5. It MUST check that the ``aud`` claim in the Request Object is equal to the identifier of the PID/(Q)EAA Provider (:rfc:`9126`, :rfc:`9101`).
     6. It MUST reject the PAR request, if it contains the ``request_uri`` parameter (:rfc:`9126`).
     7. It MUST check that the Request Object contains all the mandatory parameters which values are validated according to :ref:`Table of the HTTP parameters <table_request_object_claim>` [derived from :rfc:`9126`].
     8. It MUST check that the Request Object is not expired, checking the ``exp`` claim.
@@ -943,7 +943,7 @@ The JWT proof type MUST contain the following parameters for the JOSE header and
     - The value of this claim MUST be the **client_id** of the Wallet Instance.
     - [`OpenID4VCI`_], [:rfc:`7519`, Section 4.1.1].
   * - **aud**
-    - The value of this claim MUST be the identifier URL of the PID/(Q)EAA Issuer.
+    - It MUST be set to the identifier of the PID/(Q)EAA Provider.
     - [`OpenID4VCI`_].
   * - **iat**
     - UNIX Timestamp with the time of JWT issuance, coded as NumericDate as indicated in :rfc:`7519`.

refs/pull/432/merge/en/_sources/remote-flow.rst.txt

@@ -3,7 +3,6 @@
 .. _Trust Model: trust.html
 
 
-
 Remote Flow
 ===========
 
@@ -437,7 +436,7 @@ Where the following parameters are used:
   * - **vp_token**
     - JSON Array containing the Verifiable Presentation(s). There MUST be at least two signed presentations in this Array:
 
-      - The requested Digital Credential (one or more, in format of SD-JWT VC or MDOC CBOR)
+      - The requested Digital Credential (one or more, in format of SD-JWT VC)
       - The Wallet Attestation
   * - **presentation_submission**
     - JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the `Presentation Exchange <https://identity.foundation/presentation-exchange/spec/v2.0.0/>`_. This is expressed via elements in the ``descriptor_map`` array (Input Descriptor Mapping Objects) that contain a field called ``path``, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where ``n`` is the index to select. The Relying Party receiving the `presentation_submission` descriptor therefore is able to use the correct method to decode each credential data format provided within the ``vp_token``.
@@ -446,7 +445,7 @@ Where the following parameters are used:
 
 
 The items contained in the ``vp_token`` array are Verifiable Presentations of Credentials.
-Both SD-JWT and mdoc CBOR provide indications for the presentation, according to their specifications.
+
 
 SD-JWT Presentation
 -------------------
@@ -495,10 +494,18 @@ When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in
     - REQUIRED. The base64url-encoded hash digest over the Issuer-signed JWT and the selected disclosures.
 
 
-MDOC-CBOR Presentation
-----------------------
+Revocation Checks
+~~~~~~~~~~~~~~~~~
+
+The revocation mechanisms that the Relying Parties MUST implement are defined in the section (:ref:`Revocations <revocation-lists.rst>`).
+
+In the context of Digital Credential evaluation, any Relying Parties (RPs) establishes internal policies that define the meaning and value of presented Credentials. This is particularly important in scenarios where a Credential may be suspended but still holds value for certain purposes. For example, a suspended mobile driving license might still be valid for verifying the age of the holder.
+
+The process begins with the RP requesting specific Credentials from the Holder. This request should align with the Relying Party's requirements and the context in which the Credentials will be used. The Holder then responds by releasing the requested Credentials.
+
+Upon receiving the Credentials, the Relying Party evaluates their validity and value based on its internal policies. This evaluation considers the current status of the Credential (e.g., active, suspended, revoked) and the specific use case for which the Credential is being presented.
 
-TBD.
+Relying Parties should develop comprehensive internal policies that outline how different types of Credentials are to be evaluated. These policies should address scenarios where a Credential may be partially valid or have limited applicability. Flexibility in evaluation processes is important to accommodate various use cases. For instance, a Credential that is suspended for driving purposes might still be acceptable for age verification.
 
 
 Authorization Response Errors

refs/pull/432/merge/en/_sources/revocation-lists.rst.txt

@@ -250,7 +250,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`_.
 
-The Revocation Assertion object MUST contain the parameter ``credential_status_validity`` with the value set to ``false``.
+The Revocation Assertion object MUST contain the parameter ``credential_status_validity`` with the value set to ``1``.
 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::
@@ -266,7 +266,7 @@ 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",
-    "credential_status_validity": false,
+    "credential_status_validity": 1,
     "credential_status_detail": {
       "state": "invalid",
       "description": "The Credential is no longer usable as it has been revoked. This state is irreversible"
@@ -411,7 +411,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,
+		"credential_status_validity": 0,
 		"cnf": {
 			"jwk": {...}
 		}
@@ -650,10 +650,13 @@ When the JWT format is used, the Revocation Assertion MUST contain the following
       - Unique identifier for the JWT.
       - :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`.
+      - Numerical value indicating the validity of the Credential linked to the Status Assertion describing its state, mode, condition or stage. It MUST be set with `1` (INVALID status). 
       - `OAUTH-STATUS-ASSERTION`_.
     * - **credential_status_detail**
-      - Object containing detailed information about the real status of the Credential. It MUST contains ``state`` and related ``description`` parameters that MUST be set with one of the values defined in the *credential_status_detail_supported* mapped in the Credential Issuer metadata.
+      - Object containing detailed information about the real status of the Credential. IT MUST contains:
+
+          - **state**: String value of the Credential status,
+          - **description**: String containing the description of the Credential status.
       - `OAUTH-STATUS-ASSERTION`_.
 
 
@@ -704,10 +707,13 @@ When the JWT format is used, the Status Assertion MUST contain the following cla
       - The Algorithm used for hashing the Credential to which the Status Assertion is bound. The value SHOULD be set to ``S256``.
       - `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".
+      - Numerical value indicating the validity of the Credential linked to the Status Assertion describing its state, mode, condition or stage. It MUST be set with values from 0 to 2 with the following meaning: 0-VALID, 1-INVALID, 2-SUSPENDED.
       - `OAUTH-STATUS-ASSERTION`_.
     * - **credential_status_detail**
-      - REQUIRED if **credential_status_validity** is set to `false`. Object containing detailed information about the real status of the Credential. IT MUST contains ``state`` and related ``description`` parameters that MUST be set with one of the values defined in the *credential_status_detail_supported* mapped in the Credential Issuer metadata.
+      - REQUIRED if **credential_status_validity** is not set to `0`. Object containing detailed information about the real status of the Credential. IT MUST contains:
+
+          - **state**: String value of the Credential status,
+          - **description**: String containing the description of the Credential status.
       - `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.