Skip to content

Commit

Permalink
Issuance: c_nonce and jwt proof clarification (#208)
Browse files Browse the repository at this point in the history
* chore: editorial c_nonce and jwt proof clarification

* Update docs/en/pid-eaa-issuance.rst

Co-authored-by: Giuseppe De Marco <[email protected]>

* Update docs/en/pid-eaa-issuance.rst

Co-authored-by: Giuseppe De Marco <[email protected]>

---------

Co-authored-by: Giuseppe De Marco <[email protected]>
  • Loading branch information
fmarino-ipzs and peppelinux authored Feb 15, 2024
1 parent c351028 commit 1a9b433
Showing 1 changed file with 13 additions and 3 deletions.
16 changes: 13 additions & 3 deletions docs/en/pid-eaa-issuance.rst
Original file line number Diff line number Diff line change
Expand Up @@ -282,9 +282,9 @@ The ``client_assertion`` is signed using the private key that is created during
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation
&client_assertion=$WIA~WIA-PoP
**Step 15 (Token Response):** The PID/(Q)EAA Provider validates the request, if successful an *Access Token* (bound to the DPoP key) and a fresh ``c_nonce`` is provided to the Wallet Instance.
**Step 15 (Token Response):** The PID/(Q)EAA Provider validates the request, if successful an *Access Token* (bound to the DPoP key) and a fresh `c_nonce` are provided by the Issuer to the Wallet Instance. The parameter `c_nonce` is a string value, which MUST be unpredictable and is used later by the Wallet Instance in Step 18 to create the proof of possession of the key (*proof* claim) and it is the primary countermeasure against key proof replay attack. Note that, the received `c_nonce` value can be used to create the proof as long as the Issuer provides the Wallet Instance with a new `c_nonce` value.

.. code-block:: http
.. code-block::
HTTP/1.1 200 OK
Content-Type: application/json
Expand All @@ -308,7 +308,15 @@ The ``client_assertion`` is signed using the private key that is created during
**Steps 16-17 (DPoP Proof for Credential Endpoint):** The Wallet Instance for requesting the Digital Credential creates a proof of possession with ``c_nonce`` obtained in **Step 15** and using the private key used for the DPoP, signing a DPoP Proof JWT according to (:rfc:`9449`) Section 4. The ``jwk`` value in the ``proof`` parameter MUST be equal to the public key referenced in the DPoP.

**Step 18 (Credential Request):** The Wallet Instance requests the Digital Credential to the PID/(Q)EAA Credential endpoint. The request MUST contain the *Access Token*, the *DPoP Proof JWT*, the *credential type*, the ``proof`` (proof of possession of the key) and the ``format`` parameters.
**Step 18 (Credential Request):** The Wallet Instance sends a request for the Digital Credential to the PID/(Q)EAA Credential endpoint. This request MUST include the Access Token, DPoP Proof JWT, credential type, proof (which demonstrates possession of the key), and format parameters. The proof parameter MUST be an object that contains evidence of possession of the cryptographic key material to which the issued PID/(Q)EAA Digital Credential will be bound. To verify the proof, the PID/(Q)EAA Provider conducts the following checks at the Credential endpoint:

1. the JWT proof MUST include all required claims as specified in the table of Section :ref:`Token Request <sec_token_request>`;
2. The key proof MUST be explicitly typed using header parameters as defined for the respective proof type;
3. The header parameter alg MUST indicate a registered asymmetric digital signature algorithm, and MUST NOT be set to `none`;
4. The signature on the key proof MUST be verified using the public key specified in the header parameter.
5. The header parameter MUST NOT contain a private key.
6. If a `c_nonce` value was previously provided by the server, the nonce claim in the JWT MUST match this `c_nonce` value. Furthermore, the creation time of the JWT, as indicated by the `iat` claim or a server-managed timestamp via the nonce claim, MUST be within an acceptable window of time as determined by the server.


.. note::

Expand Down Expand Up @@ -635,6 +643,8 @@ Token endpoint
The token endpoint is used by the Wallet Instance to obtain an Access Token by presenting an authorization grant, as
defined in :rfc:`6749`. The Token Endpoint is a protected endpoint with a client authentication based on the model defined in OAuth 2.0 Attestation-based Client Authentication [`oauth-attestation-draft <https://vcstuff.github.io/draft-ietf-oauth-attestation-based-client-auth/draft-ietf-oauth-attestation-based-client-auth.html>`_].

.. _sec_token_request:

Token Request
^^^^^^^^^^^^^^^

Expand Down

0 comments on commit 1a9b433

Please sign in to comment.