Merge pull request #466 from italia/jws

fix: JWS -> signed JWT

docs/en/pid-eaa-data-model.rst

@@ -83,7 +83,7 @@ The JOSE header contains the following mandatory parameters:
     - OPTIONAL. JSON array containing the trust chain that proves the reliability of the issuer of the JWT. 
     - [`OID-FED`_] Section 3.2.1.
   * - **x5c**
-    - OPTIONAL. Contains the X.509 public key certificate or certificate chain [:rfc:`5280`] corresponding to the key used to digitally sign the JWS. 
+    - OPTIONAL. Contains the X.509 public key certificate or certificate chain [:rfc:`5280`] corresponding to the key used to digitally sign the JWT. 
     - :rfc:`7515` Section 4.1.8 and [`SD-JWT-VC`_] Section 3.5.
   * - **vctm**
     - OPTIONAL. JSON array of base64url-encoded Type Metadata JSON documents. In case of extended type metadata, this claim contains the entire chain of JSON documents. 

docs/en/pid-eaa-entity-configuration.rst

@@ -56,15 +56,15 @@ The *oauth_authorization_server* metadata MUST contain the following parameters.
   * - **response_modes_supported**
     - JSON array containing a list of the supported "response_mode" values, as specified in `OAuth 2.0 Multiple Response Type Encoding Practices <https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html>`_. The supported values MAY be *query* and *form_post.jwt* (see `[oauth-v2-jarm-03] <https://openid.net/specs/oauth-v2-jarm-03.html#name-response-mode-form_postjwt>`__).
   * - **authorization_signing_alg_values_supported**
-    - JSON array containing a list of the JWS :rfc:`7515` supported signing algorithms (*alg* values). The values MUST be set according to Section :ref:`Cryptographic algorithms`. See Section 4 of `[oauth-v2-jarm-03] <https://openid.net/specs/oauth-v2-jarm-03.html>`__.
+    - JSON array containing a list of the :rfc:`7515` supported signing algorithms (*alg* values). The values MUST be set according to Section :ref:`Cryptographic algorithms`. See Section 4 of `[oauth-v2-jarm-03] <https://openid.net/specs/oauth-v2-jarm-03.html>`__.
   * - **grant_types_supported**
     - JSON array containing a list of the supported grant type values. The authorization server MUST support *authorization_code*. 
   * - **token_endpoint_auth_methods_supported**
     - JSON array containing a list of supported client authentication methods. The Token Endpoint MUST support *attest_jwt_client_auth* as defined in `OAUTH-ATTESTATION-CLIENT-AUTH`_.
   * - **token_endpoint_auth_signing_alg_values_supported**
-    - JSON array containing a list of the JWS signing algorithms ("*alg*" values) supported by the token endpoint for the signature on the JWT used to authenticate the client at the Token Endpoint. See :rfc:`8414#section-2`.
+    - JSON array containing a list of the signing algorithms ("*alg*" values) supported by the token endpoint for the signature on the JWT used to authenticate the client at the Token Endpoint. See :rfc:`8414#section-2`.
   * - **request_object_signing_alg_values_supported**
-    - JSON array containing a list of the JWS signing algorithms ("*alg*" values) supported for Request Objects. See `[openid-connect-discovery-1_0] <https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata>`_.
+    - JSON array containing a list of the signing algorithms ("*alg*" values) supported for Request Objects. See `[openid-connect-discovery-1_0] <https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata>`_.
   * - **jwks**
     - JSON Web Key Set containing the cryptographic keys for the authorization server. See `OID-FED`_ Section 5.2.1 and `JWK`_.
 

docs/en/pid-eaa-issuance.rst

@@ -121,7 +121,7 @@ The PID/(Q)EAA Provider MUST use *OAuth 2.0 Authorization Server* based on :rfc:
 
 The PID/(Q)EAA Provider performs the following checks upon the receipt of the PAR request:
 
-    1. It MUST validate the signature of the Request Object using the algorithm specified in the ``alg`` header parameter (:rfc:`9126`, :rfc:`9101`) and the public key retrieved from the Wallet Attestation (``cnf.jwk``) referenced in the Request Object, using the ``kid`` JWS header parameter.
+    1. It MUST validate the signature of the Request Object using the algorithm specified in the ``alg`` header parameter (:rfc:`9126`, :rfc:`9101`) and the public key retrieved from the Wallet Attestation (``cnf.jwk``) referenced in the Request Object, using the ``kid`` JWT header parameter.
     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`).
@@ -318,7 +318,7 @@ A non-normative example of the Credential Request is provided below.
 
 
 Where a non-normative example of the decoded content of the ``jwt`` parameter is represented below,
-without encoding and signature. The JWS header:
+without encoding and signature. The JWT header:
 
 .. literalinclude:: ../../examples/credential-jwt-proof-header.json
   :language: JSON  
@@ -721,7 +721,7 @@ All the parameters listed below are REQUIRED:
       - `Proof Key for Code Exchange by OAuth Public Clients <https://datatracker.ietf.org/doc/html/rfc7636>`_.
 
 
-A **DPoP Proof JWT** is included in the HTTP request using the ``DPoP`` header parameter containing a DPoP JWS.
+A **DPoP Proof JWT** is included in the HTTP request using the ``DPoP`` header parameter containing a DPoP JWT.
 
 The JOSE header of a **DPoP JWT** MUST contain at least the following parameters:
 

docs/en/relying-party-entity-configuration.rst

@@ -39,7 +39,7 @@ The *wallet_relying_party* metadata MUST contain the following parameters.
   * - **response_uris_supported**
     - JSON Array of response URI strings to which the Wallet Instance MUST send the Authorization Response using an HTTP POST request as defined by the Response Mode ``direct_post`` and ``direct_post.jwt`` (see `OpenID4VP`_ Draft 20 Sections 6.2 and 6.3).
   * - **authorization_signed_response_alg**
-    - String representing the JWS [:rfc:`7515`] *alg* algorithm that MUST be used for signing authorization responses. The algorithm *none* MUST NOT be used. See `[oauth-v2-jarm-03] <https://openid.net/specs/oauth-v2-jarm-03.html>`_ Section 3.
+    - String representing the signing [:rfc:`7515`] *alg* algorithm that MUST be used for signing authorization responses. The algorithm *none* MUST NOT be used. See `[oauth-v2-jarm-03] <https://openid.net/specs/oauth-v2-jarm-03.html>`_ Section 3.
   * - **vp_formats**
     - JSON object defining the formats and proof types of Verifiable Presentations and Verifiable Credentials the RP supports. It consists of a list of name/value pairs, where each name uniquely identifies a supported type. The RP MUST support at least "*vc+sd-jwt*" according to `OPENID4VC-HAIP`_ Draft 00 Section 7.2.7. The value associated with each name/value pair MUST be a JSON object "**sd-jwt_alg_values**" that MUST contain a JSON array containing identifiers of cryptographic algorithms the RP supports for protection of a SD-JWT. The *alg* JOSE header (as defined in :rfc:`7515`) of the presented SD-JWT MUST match one of the array values. See also `OpenID4VP`_ Draft 20 Section 9.1.
   * - **presentation_definitions_supported**

docs/en/remote-flow.rst

@@ -62,7 +62,7 @@ The details of each step shown in the previous picture are described in the tabl
   * - **14**
     - The RP issues the Request Object signin it using one of its cryptographic private keys, where their public parts have been published within its Entity Configuration (`metadata.wallet_relying_party.jwks`). The Wallet Instance obtains the signed Request Object.
   * - **15**, **16**, **17**
-    - The Request Object JWS is verified by the Wallet Instance. The Wallet Instance processes the Relying Party metadata and applies the policies related to the Relying Party, attesting whose Digital Credentials and User data the Relying Party is granted to request.
+    - The Request Object, in the form of signed JWT, is verified by the Wallet Instance. The Wallet Instance processes the Relying Party metadata and applies the policies related to the Relying Party, attesting whose Digital Credentials and User data the Relying Party is granted to request.
   * - **18**, **19**
     - The Wallet Instance requests the User's consent for the release of the Credentials by showing the Relying Party's identity and the requested attributes. The User authorizes and consents the presentation of the Credentials by selecting/deselecting the personal data to release.
   * - **20**
@@ -264,7 +264,7 @@ where a non-normative example in the form of decoded header and payload is shown
     "request_uri_method": "post"
   }
 
-The JWS header parameters are described below:
+The JWT header parameters are described below:
 
 .. list-table::
   :widths: 25 50
@@ -277,12 +277,12 @@ The JWS header parameters are described below:
   * - **typ**
     - Media Type of the JWT, as defined in [:rfc:`7519`] and [:rfc:`9101`]. It SHOULD be set to the value ``oauth-authz-req+jwt``.
   * - **kid**
-    - Key ID of the public key needed to verify the JWS signature, as defined in [:rfc:`7517`]. REQUIRED when ``trust_chain`` is used.
+    - Key ID of the public key needed to verify the JWT signature, as defined in [:rfc:`7517`]. REQUIRED when ``trust_chain`` is used.
   * - **trust_chain**
     - Sequence of Entity Statements that composes the Trust Chain related to the Relying Party, as defined in `OID-FED`_ Section *3.2.1. Trust Chain Header Parameter*.
 
 
-The JWS payload parameters are described herein:
+The JWT payload parameters are described herein:
 
 .. list-table::
   :widths: 25 50
@@ -462,7 +462,7 @@ To validate the signature on the Key Binding JWT, the Verifier MUST use the key
 The Key Binding JWT (KB-JWT) signature validation MUST use the public key included in the SD-JWT,
 using the ``cnf`` parameter contained in the Issuer-Signed-JWT.
 
-When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in the JWS header:
+When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in the JWT header:
 
 .. list-table::
   :widths: 25 50
@@ -477,7 +477,7 @@ When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in
 
 
 When an SD-JWT is presented, the KB-JWT signature MUST be verified by the same public key included in the SD-JWT within the `cnf` parameter. 
-The KB-JWT MUST contain the following parameters in the JWS payload:
+The KB-JWT MUST contain the following parameters in the JWT payload:
 
 .. list-table::
   :widths: 25 50

docs/en/trust.rst

@@ -205,7 +205,7 @@ All the endpoints listed below are defined in the `OID-FED`_ specs.
      - Trust Anchor, Intermediate
    * - fetch endpoint
      - **GET** /fetch?sub=https://rp.example.org
-     - Returns a signed document (JWS) about a specific subject, its Subordinate. It's called Entity Statement.
+     - Returns a signed JWT about a specific subject, its Subordinate. It's called Subordinate Statement.
      - Trust Anchor, Intermediate
    * - trust mark status
      - **POST** /status?sub=...&trust_mark_id=...
@@ -217,7 +217,7 @@ All the endpoints listed below are defined in the `OID-FED`_ specs.
      - Trust Anchor, Intermediate
 
 
-All the responses of the federation endpoints are in the form of JWS, with the exception of the **Subordinate Listing endpoint** and the **Trust Mark Status endpoint** that are served as plain JSON by default.
+All the responses of the federation endpoints are in the form of signed JWT, with the exception of the **Subordinate Listing endpoint** and the **Trust Mark Status endpoint** that are served as plain JSON by default.
 
 
 Configuration of the Federation
@@ -679,7 +679,7 @@ Below is an abstract representation of a Trust Chain.
         "EntityStatement-as-SignedJWT-issued-byTrustAnchor"
     ]
 
-Below is a non-normative example of a Trust Chain in its original format (JSON Array containing JWS as strings) with an Intermediate involved.
+Below is a non-normative example of a Trust Chain, composed by a JSON Array containing JWTs, with an Intermediate involved.
 
 .. code-block:: python
 
@@ -713,7 +713,7 @@ Offline Relying Party Metadata
 
 Since the Federation Entity Discovery is only applicable in online scenarios, it is possible to include the Trust Chain in the presentation requests that the Relying Party may issue for a Wallet Instance.
 
-The Relying Party MUST sign the presentation request, the request SHOULD include the `trust_chain` claim in its JWS header parameters, containing the Federation Trust Chain related to itself.
+The Relying Party MUST sign the presentation request, the request SHOULD include the `trust_chain` claim in its JWT header parameters, containing the Federation Trust Chain related to itself.
 
 The Wallet Instance that verifies the request issued by the Relying Party MUST use the Trust Anchor's public keys to validate the entire Trust Chain related to the Relying Party before attesting its reliability.
 
@@ -736,7 +736,7 @@ The Trust Anchor and its Intermediate MUST expose the Federation Historical Keys
 
 The details of this endpoint are defined in the `OID-FED`_ Section 7.6.
 
-Each JWS containing a Trust Chain in the form of a JWS header parameter can be verified over time, since the entire Trust Chain is verifiable using the Trust Anchor's public key.
+Each JWT containing a Trust Chain in the JWT headers can be verified over time, since the entire Trust Chain is verifiable using the Trust Anchor's public key.
 
 Even if the Trust Anchor has changed its cryptographic keys for digital signature, the Federation Historical Keys endpoint always makes the keys no longer used available for historical signature verifications.
 
@@ -756,7 +756,7 @@ Considerations about Decentralization
 
 - There may be more than a single Trust Anchor.
 - In some cases, a trust verifier may trust an Intermediate, especially when the Intermediate acts as a Trust Anchor within a specific perimeter, such as cases where the Leafs are both in the same perimeter like a Member State jurisdiction (eg: an Italian Relying Party with an Italian Wallet Instance may consider the Italian Intermediate as a Trust Anchor for the scopes of their interactions).
-- Trust attestations (Trust Chain) should be included in the JWS issued by Credential Issuers, and the Presentation Requests of RPs should contain the Trust Chain related to them (issuers of the presentation requests).
+- Trust attestations (Trust Chain) should be included in the JWT issued by Credential Issuers, and the Presentation Requests of RPs should contain the Trust Chain related to them (issuers of the presentation requests).
 - Since the credential presentation must be signed, storing the signed presentation requests and responses, which include the Trust Chain, the Wallet Instance may have the snapshot of the federation configuration (Trust Anchor Entity Configuration in the Trust Chain) and the verifiable reliability of the Relying Party it has interacted with. 
 - Each signed attestation is long-lived since it can be cryptographically validated even when the federation configuration changes or the keys of its issuers are renewed.
 - Each participant should be able to update its Entity Configuration without notifying the changes to any third party. The metadata policy contained within a Trust Chain must be applied to overload any information related to protocol specific metadata.

docs/en/wallet-attestation.rst

@@ -467,7 +467,7 @@ The body of the Wallet Attestation Request JWT MUST contain:
       - JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports.
       - :rfc:`8414`
     * - **request_object_signing_alg_values_supported**
-      - JSON array containing a list of the JWS signing algorithms (alg values) supported.
+      - JSON array containing a list of the signing algorithms (alg values) supported.
       -
     * - **presentation_definition_uri_supported**
       - Boolean value specifying whether the Wallet Instance supports the transfer of presentation_definition by reference. MUST be set to false.
@@ -540,7 +540,7 @@ The body of the Wallet Attestation JWT MUST contain:
       - JSON object with name/value pairs, identifying a Credential format supported by the Wallet.
       -
     * - **request_object_signing_alg_values_supported**
-      - JSON array containing a list of the JWS signing algorithms (alg values) supported.
+      - JSON array containing a list of the signing algorithms (alg values) supported.
       -
     * - **presentation_definition_uri_supported**
       - Boolean value specifying whether the Wallet Instance supports the transfer of presentation_definition by reference. MUST be set to false.

docs/en/wallet-solution.rst

@@ -87,7 +87,7 @@ Wallet Provider Metadata
 ~~~~~~~~~~~~~~~~~~~~~~~~
 An HTTP GET request to the **/.well-known/openid-federation** endpoint allows the retrieval of the Wallet Provider Entity Configuration.
 
-The Wallet Provider Entity Configuration is a JWS containing the public keys and supported algorithms of the Wallet Provider metadata definition. It is structured in accordance with the `OpenID Connect Federation <https://openid.net/specs/openid-connect-federation-1_0.html>`_ and the Trust Model section outlined in this specification.
+The Wallet Provider Entity Configuration is a signed JWT containing the public keys and supported algorithms of the Wallet Provider metadata definition. It is structured in accordance with the `OpenID Connect Federation <https://openid.net/specs/openid-connect-federation-1_0.html>`_ and the Trust Model section outlined in this specification.
 
 The returning Entity Configuration of the Wallet Provider MUST contain the attributes listed below: