Merge pull request italia#733 from italia/italian-translation-block-1

[IT] Credential Issuer, Authentic Sources Translations Block

Author: pcerqua-ipzs

docs/en/architecture-overview.rst

@@ -35,15 +35,15 @@ External systems provide services that connect the IT-Wallet ecosystem to the na
 
 The architecture enables the following interaction processes:
 
-  1. **Entity Onboarding and Federation**: Only qualified and compliant entities are registered in the IT-Wallet Federation. The Trust Registry is updated during registration, allowing participants to monitor federation status. This process may include technical and security assessments.
+  1. **Entity Onboarding and Federation**: Only qualified and compliant Entities are registered in the IT-Wallet Federation. The Trust Registry is updated during registration, allowing participants to monitor federation status. This process includes administrative, technical and security assessments.
 
-  2. **Credential Issuance**: Credential Issuers connect to Authentic Sources via standardized APIs on the National Digital Data Platform to request verified user attributes. Digital Credentials are based on authoritative, current data with proper authorization and audit trails.
+  2. **Credential Issuance**: Credential Issuers connect to Authentic Sources via standardized APIs (on the National Digital Data Platform if the Authentic Source belongs to the Public sector) to request verified User attributes. Digital Credentials are based on authoritative, current data with proper authorization and audit trails.
 
-  3. **Credential Storage and Management**: IT-Wallet Solutions receive and manage Digital Credentials on user devices, allowing users to control and use credentials from multiple sources.
+  3. **Credential Storage and Management**: IT-Wallet Solutions receive and manage Digital Credentials on User devices, allowing Users to control and use credentials from multiple Issuers.
 
   4. **Credential Presentation and Verification**: Users present Digital Credentials to Relying Parties for verification. Verification systems check claims through cryptographic methods and status checks for both public and private sector use.
 
-The Trust Infrastructure manages onboarding and revocation of entities, provides credential schemas, and lets participants discover and verify authorized entities and their status. It supports automatic trust chain validation, distributed trust anchoring, standardized metadata exchange, and Federation API services for secure, seamless federation operations.
+The Trust Infrastructure manages onboarding and revocation of Entities, provides credential schemas, and lets participants discover and verify authorized entities and their status. It supports automatic trust chain validation, distributed trust anchoring, standardized metadata exchange, and Federation API services for secure, seamless federation operations.
 
 
 .. toctree::

docs/en/credential-data-model.rst

@@ -177,15 +177,15 @@ If the ``status`` parameter is set to ``status_list``, it is a JSON Object conta
      - REQUIRED. The idx (index) claim MUST specify an Integer that represents the index to check for status information in the Status List for the current Digital Credential. The value of idx MUST be a non-negative number, containing a value of zero or greater.
      - TOKEN-STATUS-LIST_
    * - **uri**
-     - REQUIRED. The uri (URI) claim MUST specify a String value that identifies the Status List Token containing the status information for the Digital Credential. The value of uri MUST be a URI conforming to [:rfc:`3986`].
+     - REQUIRED. The ``uri`` (URI) claim MUST specify a String value that identifies the Status List Token containing the status information for the Digital Credential. The value of ``uri`` MUST be a URI conforming to [:rfc:`3986`].
      - TOKEN-STATUS-LIST_
 
 
-If the ``status`` parameter is set to ``status_assertation``, it is a JSON Object containing the *credential_hash_alg* claim indicating the Algorithm used for hashing the Digital Credential to which the Status Assertion is bound. It is RECOMMENDED to use *sha-256*.
+If the ``status`` parameter is set to ``status_assertion``, it is a JSON Object containing the *credential_hash_alg* claim indicating the Algorithm used for hashing the Digital Credential to which the Status Assertion is bound. It is RECOMMENDED to use *sha-256*.
 
 
 .. note::
-  Credential Type Metadata JSON Document MAY be retrieved directly from the URL contained in the claim **vct**, using the HTTP GET method or using the vctm header parameter if provided. Unlike specified in Section 6.3.1 of `SD-JWT-VC`_ the **.well-known** endpoint is not included in the current implementation profile. Implementers may decide to use it for interoperability with other systems.
+  Credential Type Metadata JSON Document MAY be retrieved directly from the URL contained in the claim **vct**, using the HTTP GET method or using the ``vctm`` header parameter if provided. Unlike specified in Section 6.3.1 of `SD-JWT-VC`_ the **.well-known** endpoint is not included in the current implementation profile. Implementers may decide to use it for interoperability with other systems.
 
 
 Digital Credential Metadata Type
@@ -202,10 +202,10 @@ The Metadata type document MUST be a JSON object and contains the following para
       - **Description**
       - **Reference**
     * - **name**
-      - REQUIRED. Human-readable name of the Digital Credential type. In case of multiple languages, the language tags are added to the member name, delimited with the character ``#`` as defined in :rfc:`5646` (e.g. *name#it-IT*).
+      - REQUIRED. Human-readable name of the Digital Credential type. In case of multiple languages, the language tags are added to the member name, delimited with the character `#` as defined in :rfc:`5646` (e.g. *name#it-IT*).
       - [`SD-JWT-VC`_] Section 6.2 and [`OIDC`_] Section 5.2.
     * - **description**
-      - REQUIRED. A human-readable description of the Digital Credential type. In case of multiple languages, the language tags are added to the member name, delimited by a # character as defined in :rfc:`5646`.
+      - REQUIRED. A human-readable description of the Digital Credential type. In case of multiple languages, the language tags are added to the member name, delimited by a `#` character as defined in :rfc:`5646`.
       - [`SD-JWT-VC`_] Section 6.2 and [`OIDC`_] Section 5.2.
     * - **extends**
       - OPTIONAL. String Identifier of an extended metadata type document.
@@ -772,7 +772,7 @@ The `MobileSecurityObject` MUST have the following attributes, unless otherwise
       - [ISO 18013-5#9.1.2.4]
     * - **status**
       - *(map, CONDITIONAL)*. REQUIRED only if the Digital Credential is long-lived. Contains the MSO revocation information. If present, it includes a *status_list* based on the TOKEN-STATUS-LIST_ mechanism. This mechanism uses a bit array to mark revoked MSOs by their index position.
-        The `status_list` MUST contain the following sub-value:
+        The `status_list` MUST contain the following sub-values:
 
           * **idx**. Position index in the status list.
           * **uri**. URI pointing to the status list resource.
@@ -835,7 +835,7 @@ For SD-JWT-VC, parameters are marked with `(hdr)` if they are located in the JOS
    * - **Information Related To**
      - **SD-JWT-VC Parameters**
      - **mdoc-CBOR Parameters**
-   * - Digital Credential definition
+   * - Digital Credential type definition
      - vct (pld)
      - | issuerAuth.doctype
        | issuerAuth.version
@@ -874,7 +874,7 @@ For SD-JWT-VC, parameters are marked with `(hdr)` if they are located in the JOS
        | issuerAuth.validityInfo.validUntil
        | issuerAuth.validityInfo.validFrom
    * - Status mechanism
-     - | status_assertation (pld)
+     - | status_assertion (pld)
        | status_list (pld)
      - | -
        | issuerAuth.status_list

docs/en/credential-issuance-endpoint.rst

@@ -145,7 +145,7 @@ The ``request`` JWT payload contained in the HTTP POST message is given with the
       - A method that was used to derive **code challenge**. It MUST be set to ``S256``.
       - :rfc:`7636#section-4.3`.
     * - **scope**
-      - JSON String. String specifying a unique identifier of the Credential regardless of its format. It MUST be mapped in the `credential_configurations_supported` metadata claim of the Credential Issuer. Unique identifier value MUST match the `credential_type` parameter of the Digital Credentials Catalogue. For example, in the case of the PID, it may be set to ``PersonIdentificationData`` while in case of mobile driving licence ``mDL``. Since it MAY be multivalued, when this occurs each value MUST be separated by a space.
+      - JSON String. String specifying a unique identifier of the Credential regardless of its format. It MUST be mapped in the `credential_configurations_supported` metadata claim of the Credential Issuer. Unique identifier value MUST match the `credential_type` parameter of the :ref:`registry-catalogue:Digital Credentials Catalogue`. For example, in the case of the PID, it may be set to ``PersonIdentificationData`` while in case of mobile driving licence ``mDL``. Since it MAY be multivalued, when this occurs each value MUST be separated by a space.
       - :rfc:`6749`
     * - **authorization_details**
       - Array of JSON Objects. Each JSON Object MUST include the following claims:
@@ -411,7 +411,7 @@ The request to the Credential Issuer Token endpoint MUST be an HTTP request with
 
 The Token endpoint is protected with *OAuth 2.0 Attestation-based Client Authentication* [`OAUTH-ATTESTATION-CLIENT-AUTH`_], therefore
 the request to the Credential Issuer authorization endpoint MUST use the following HTTP Headers parameters **OAuth-Client-Attestation** as **OAuth-Client-Attestation-PoP**
-as defined in the "Pushed Authorization Request (PAR) Endpoint".
+as defined in the :ref:`credential-issuance-endpoint:Pushed Authorization Request Endpoint`"
 
 The Token endpoint issues DPoP tokens, therefore it is REQUIRED that the request includes in its HTTP header the DPoP proof parameter.
 The Authorization Server MUST validate the DPoP proof received at the Token endpoint, according to :rfc:`9449` Section 4.3. This mitigates the misuse of leaked or stolen Access Tokens/Refresh Tokens at the Credential/Token endpoint. If the DPoP proof is invalid, the Token endpoint returns an error response, according to Section 5.2 of [:rfc:`6749`] with ``invalid_dpop_proof`` as the value of the error parameter.
@@ -741,7 +741,7 @@ The Wallet Instance when requests the Digital Credential to the Credential endpo
 
 The Credential endpoint MUST accept and validate the *DPoP proof* sent in the DPoP HTTP Header parameter, according to the steps defined in (:rfc:`9449`) Section 4.3. The *DPoP proof* in addition to the values that are defined in the Token Endpoint section MUST contain the following claim:
 
-  - **ath**: hash value of the Access Token encoded in ASCII. The value MUST use the base64url encoding (as defined in Section 2 of :rfc:`7515`) with the SHA-256 algorithm.
+  - **ath**: hash value of the Access Token encoded in ASCII. The value MUST use the base64url encoding (as defined in Section 2 of (:rfc:`7515`) with the SHA-256 algorithm.
 
 .. warning::
   The Wallet Instance MUST create a **new DPoP proof** for the Credential request and MUST NOT use the previously created proof for the Token Endpoint.

docs/en/credential-issuance-high-level.rst

@@ -55,6 +55,7 @@ The :numref:`fig_High-Level-Flow-ITWallet-QEAA-Issuance` shows a general archite
 ..     (Q)EAA Issuance - General architecture and high level flow
 
 Similarly to the PID high-level flow, the above diagram depicts a (Q)EAA high-level flow starting from the User who wants to obtain a (Q)EAA (step 0). Below the description of the most relevant operations involved in the (Q)EAA issuance:
+
     1. **(Q)EAA Provider Discovery and Trust**: the Wallet Instance obtains the list of the trusted (Q)EAA Providers using the Digital Credential Catalogue and Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), then inspects the metadata looking for the Digital Credential capabilities of each (Q)EAA Provider.
     2. **(Q)EAA Request**: using the Authorization Code Flow, defined in [`OpenID4VCI`_], the Wallet Instance requests a (Q)EAA to the (Q)EAA Provider.
     3. **Wallet Provider Discovery and Trust**: the (Q)EAA Provider verifies the authenticity and validity of the Wallet Instance. During this step the (Q)EAA Provider establishes trust with the Wallet Provider and retrieves Wallet metadata containing the necessary parameters for interoperability, as defined by the Trust Model.