Deploy to GitHub pages

vci-ref/en/_sources/pid-eaa-issuance.rst.txt

@@ -8,7 +8,7 @@ PID/(Q)EAA Issuance
 This section describes the PID and (Q)EAAs issuance flow with an high level of security.
 The relevant entities and interfaces involved in the issuance flow are:
 
-    - *Wallet Provider*: The entity responsible for releasing an EUDI Wallet Solution. The Wallet Provider issues the Wallet Instance Attestations to its Wallet Instances through an Attestation Service. The Wallet Attestation certifies the genuinity and authenticity of the Wallet Instance and its compliance the security and privacy requirements.
+    - *Wallet Provider*: The entity responsible for releasing an EUDI Wallet Solution. The Wallet Provider issues the Wallet Instance Attestations to its Wallet Instances through an Attestation Service. The Wallet Attestation certifies the genuinity and authenticity of the Wallet Instance and its compliance with the security and privacy requirements.
     - *Wallet Solution*: Entire product and service owned by a Wallet Provider, offered to all the Users and certified as EUDI-compliant by a Conformity Assessment Body (CAB).
     - *Wallet Instance*: Instance of a Wallet Solution, installed on the User device. The Wallet Instance provides graphical interfaces for User interaction with Relying Parties, PID, (Q)EAA Providers and the Wallet Provider.
     - *PID Provider*: The entity that issues the eIDAS Person Identification Data (PID). It is composed of:
@@ -19,7 +19,7 @@ The relevant entities and interfaces involved in the issuance flow are:
 
     - *(Q)EAA Provider*: It represents the Issuer of (Q)EAAs. It is composed of:
 
-      - OpenID4VCI Component: based on the "OpenID for Verifiable Credential Issuance" specification ` to release (Q)EAAs.
+      - OpenID4VCI Component: based on the "OpenID for Verifiable Credential Issuance" specification to release (Q)EAAs.
       - Relying Party: Component to authenticate the User with the PID. The (Q)EAA Provider acts as a Verifier by sending a presentation request to the Wallet Instance, according to [`OpenID4VP`_]. The Wallet Instance MUST have a valid PID, obtained in a previous time, to get authenticated with the (Q)EAA Provider.
 
 
@@ -38,7 +38,7 @@ The :numref:`fig_High-Level-Flow-ITWallet-PID-Issuance` shows a general architec
 Below the description of the steps represented in the previous picture:
 
     0. **Wallet Instance Setup**: the first time the Wallet Instance is started a preliminary setup phase is carried out. It consists of the release of the Wallet Instance Attestation issued by Wallet Attestation Service asserting the genuineness and the compliance of the Wallet Instance with the shared trust framework. The Wallet Instance Attestation binds the public key provided by the Wallet Instance, related to one of the private keys generated by the Wallet Instance.
-    1. **Digital Credential Issuers Discovery**: the Wallet Instance discovers the trusted Digital Credential Issuers using the Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), inspecting the Credential Issuer metadata and Trust Marks for filtering the PID Provider.
+    1. **PID/(Q)EAA Provider Issuers Discovery**: the Wallet Instance discovers the trusted Digital Credential Issuers using the Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), inspecting the Credential Issuer metadata and Trust Marks for filtering the PID Provider.
     2. **PID Provider Metadata**: the Wallet Instance establishes the trust to the PID Provider according to the Trust Model and obtains the Metadata that discloses the formats of the PID, the algorithms supported, and any other parameter required for interoperability needs.
     3. **PID Request**: using the Authorization Code Flow defined in `[OIDC4VCI. Draft 13] <https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html>`_ the Wallet Instance requests the PID to the PID Provider.
     4. **User Authentication**: the PID Provider authenticates the User with LoA High, acting as an Identity and Access Management Proxy to the National eID system.
@@ -63,7 +63,7 @@ The :numref:`fig_High-Level-Flow-ITWallet-QEAA-Issuance` shows a general archite
 
 Below the description of the most relevant operations involved in the (Q)EAA issuance:
 
-    1. **Discovery of the trusted (Q)EAA Issuer**: the Wallet Instance obtains the list of the trusted (Q)EAA Issuer using the Federaiton API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), then inspects the metadata and Trust Mark looking for the Digital Credential capabilities of each (Q)EAA Provider.
+    1. **Discovery of the trusted (Q)EAA Provider**: the Wallet Instance obtains the list of the trusted (Q)EAA Provider using the Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), then inspects the metadata and Trust Mark looking for the Digital Credential capabilities of each (Q)EAA Provider.
     2. **(Q)EAA Provider Metadata**: the Wallet Instance establishes the trust to the (Q)EAA Provider according to the Trust Model, obtaining the Metadata that discloses the formats of the (Q)EAA, the algorithms supported, and any other parameter required for interoperability needs.
     3. **(Q)EAA Request**: using the Authorization Code Flow , defined in `[OIDC4VCI. Draft 13] <https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html>`_, the Wallet Instance requests a (Q)EAA to the (Q)EAA Provider.
     4. **User Authentication**: the (Q)EAA Provider, acting as a Verifier (Relying Party), authenticates the User evaluating the presentation of the PID.
@@ -258,7 +258,8 @@ The PID/(Q)EAA Provider returns the issued ``request_uri`` to the Wallet Instanc
 
 **Steps 12-13 (DPoP Proof for Token Endpoint)**: The Wallet Instance MUST create a new key pair for the DPoP and a fresh DPoP Proof JWT following the instruction provided in Section 4 of (:rfc:`9449`) for the token request to the PID/(Q)EAA Provider. The DPoP Proof JWT is signed using the private key for DPoP created by Wallet Instance for this scope. DPoP binds the Access Token to a certain Wallet Instance (:rfc:`9449`) and mitigates the misuse of leaked or stolen Access Tokens at the Credential Endpoint.
 
-**Step 14 (Token Request):** The Wallet Instance sends a token request to the PID/(Q)EAA Provider Token Endpoint using the authorization ``code``, ``code_verifier`` and *DPoP Proof JWT*. The PID/(Q)EAA Provider performs the following checks:
+**Step 14 (Token Request):** The Wallet Instance sends a token request to the PID/(Q)EAA Provider Token Endpoint with a *DPoP Proof JWT*  and the parameters: ``code``, ``code_verifier``, and OAuth 2.0 Attestation based Client Authentication  (``client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation`` and ``client_assertion=WIA~WIA-PoP``). 
+The ``client_assertion`` is signed using the private key that is created during the setup phase to obtain the Wallet Instance Attestation. The related public key that is attested by the Wallet Provider is provided within the Wallet Instance Attestation (``cnf`` claim). The PID/(Q)EAA Provider performs the following checks on the Token Request:
 
    1. It MUST ensure that the Authorization ``code`` is issued to the authenticated Wallet Instance (:rfc:`6749`) and was not replied.
    2. It MUST ensure the Authorization ``code`` is valid and has not been previously used (:rfc:`6749`).
@@ -361,7 +362,7 @@ without encoding and signature. The JWS header:
 
   }
 
-And the The JWS payload:
+And the JWS payload:
 
 .. code-block:: JSON
 
@@ -381,7 +382,7 @@ And the The JWS payload:
     4. It MUST process and verify the PID in SD-JWT VC format (according to `SD.JWT#Verification <https://drafts.oauth.net/oauth-selective-disclosure-jwt/draft-ietf-oauth-selective-disclosure-jwt.html#name-verification-and-processing>`_ Section 6.) or MDOC CBOR format. 
     5. It MUST verify the Trust Chain in the header of SD-JWT VC to verify that the PID Provider is trusted.
 
-If the checks defined above are successful the Wallet Instance proceeds with the secure storage of the Digital Credential.
+If the checks defined above are successful the Wallet Instance proceeds with the secure storage of the PID/(Q)EAA.
 
 .. code-block:: http
 

vci-ref/en/pid-eaa-issuance.html

@@ -1038,7 +1038,7 @@ <h2 class='tooltip__title'>{{ item.title }}</h2>
 The relevant entities and interfaces involved in the issuance flow are:</p>
 <blockquote>
 <div><ul>
-<li><p><em>Wallet Provider</em>: The entity responsible for releasing an EUDI Wallet Solution. The Wallet Provider issues the Wallet Instance Attestations to its Wallet Instances through an Attestation Service. The Wallet Attestation certifies the genuinity and authenticity of the Wallet Instance and its compliance the security and privacy requirements.</p></li>
+<li><p><em>Wallet Provider</em>: The entity responsible for releasing an EUDI Wallet Solution. The Wallet Provider issues the Wallet Instance Attestations to its Wallet Instances through an Attestation Service. The Wallet Attestation certifies the genuinity and authenticity of the Wallet Instance and its compliance with the security and privacy requirements.</p></li>
 <li><p><em>Wallet Solution</em>: Entire product and service owned by a Wallet Provider, offered to all the Users and certified as EUDI-compliant by a Conformity Assessment Body (CAB).</p></li>
 <li><p><em>Wallet Instance</em>: Instance of a Wallet Solution, installed on the User device. The Wallet Instance provides graphical interfaces for User interaction with Relying Parties, PID, (Q)EAA Providers and the Wallet Provider.</p></li>
 <li><p><em>PID Provider</em>: The entity that issues the eIDAS Person Identification Data (PID). It is composed of:</p>
@@ -1052,7 +1052,7 @@ <h2 class='tooltip__title'>{{ item.title }}</h2>
 </li>
 <li><p><em>(Q)EAA Provider</em>: It represents the Issuer of (Q)EAAs. It is composed of:</p>
 <ul class="simple">
-<li><p>OpenID4VCI Component: based on the &quot;OpenID for Verifiable Credential Issuance&quot; specification ` to release (Q)EAAs.</p></li>
+<li><p>OpenID4VCI Component: based on the &quot;OpenID for Verifiable Credential Issuance&quot; specification to release (Q)EAAs.</p></li>
 <li><p>Relying Party: Component to authenticate the User with the PID. The (Q)EAA Provider acts as a Verifier by sending a presentation request to the Wallet Instance, according to [<a class="reference external" href="https://openid.net/specs/openid-4-verifiable-presentations-1_0.html">OpenID4VP</a>]. The Wallet Instance MUST have a valid PID, obtained in a previous time, to get authenticated with the (Q)EAA Provider.</p></li>
 </ul>
 </li>
@@ -1070,7 +1070,7 @@ <h2>High-Level PID flow<a class="headerlink" href="#high-level-pid-flow" title="
 <blockquote>
 <div><ol class="arabic simple" start="0">
 <li><p><strong>Wallet Instance Setup</strong>: the first time the Wallet Instance is started a preliminary setup phase is carried out. It consists of the release of the Wallet Instance Attestation issued by Wallet Attestation Service asserting the genuineness and the compliance of the Wallet Instance with the shared trust framework. The Wallet Instance Attestation binds the public key provided by the Wallet Instance, related to one of the private keys generated by the Wallet Instance.</p></li>
-<li><p><strong>Digital Credential Issuers Discovery</strong>: the Wallet Instance discovers the trusted Digital Credential Issuers using the Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), inspecting the Credential Issuer metadata and Trust Marks for filtering the PID Provider.</p></li>
+<li><p><strong>PID/(Q)EAA Provider Issuers Discovery</strong>: the Wallet Instance discovers the trusted Digital Credential Issuers using the Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), inspecting the Credential Issuer metadata and Trust Marks for filtering the PID Provider.</p></li>
 <li><p><strong>PID Provider Metadata</strong>: the Wallet Instance establishes the trust to the PID Provider according to the Trust Model and obtains the Metadata that discloses the formats of the PID, the algorithms supported, and any other parameter required for interoperability needs.</p></li>
 <li><p><strong>PID Request</strong>: using the Authorization Code Flow defined in <a class="reference external" href="https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html">[OIDC4VCI. Draft 13]</a> the Wallet Instance requests the PID to the PID Provider.</p></li>
 <li><p><strong>User Authentication</strong>: the PID Provider authenticates the User with LoA High, acting as an Identity and Access Management Proxy to the National eID system.</p></li>
@@ -1096,7 +1096,7 @@ <h2>High-Level (Q)EAA flow<a class="headerlink" href="#high-level-q-eaa-flow" ti
 <p>Below the description of the most relevant operations involved in the (Q)EAA issuance:</p>
 <blockquote>
 <div><ol class="arabic simple">
-<li><p><strong>Discovery of the trusted (Q)EAA Issuer</strong>: the Wallet Instance obtains the list of the trusted (Q)EAA Issuer using the Federaiton API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), then inspects the metadata and Trust Mark looking for the Digital Credential capabilities of each (Q)EAA Provider.</p></li>
+<li><p><strong>Discovery of the trusted (Q)EAA Provider</strong>: the Wallet Instance obtains the list of the trusted (Q)EAA Provider using the Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), then inspects the metadata and Trust Mark looking for the Digital Credential capabilities of each (Q)EAA Provider.</p></li>
 <li><p><strong>(Q)EAA Provider Metadata</strong>: the Wallet Instance establishes the trust to the (Q)EAA Provider according to the Trust Model, obtaining the Metadata that discloses the formats of the (Q)EAA, the algorithms supported, and any other parameter required for interoperability needs.</p></li>
 <li><p><strong>(Q)EAA Request</strong>: using the Authorization Code Flow , defined in <a class="reference external" href="https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html">[OIDC4VCI. Draft 13]</a>, the Wallet Instance requests a (Q)EAA to the (Q)EAA Provider.</p></li>
 <li><p><strong>User Authentication</strong>: the (Q)EAA Provider, acting as a Verifier (Relying Party), authenticates the User evaluating the presentation of the PID.</p></li>
@@ -1278,7 +1278,8 @@ <h2>Detailed Flow<a class="headerlink" href="#detailed-flow" title="Permalink to
 </pre></div>
 </div>
 <p><strong>Steps 12-13 (DPoP Proof for Token Endpoint)</strong>: The Wallet Instance MUST create a new key pair for the DPoP and a fresh DPoP Proof JWT following the instruction provided in Section 4 of (<span class="target" id="index-24"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc9449.html"><strong>RFC 9449</strong></a>) for the token request to the PID/(Q)EAA Provider. The DPoP Proof JWT is signed using the private key for DPoP created by Wallet Instance for this scope. DPoP binds the Access Token to a certain Wallet Instance (<span class="target" id="index-25"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc9449.html"><strong>RFC 9449</strong></a>) and mitigates the misuse of leaked or stolen Access Tokens at the Credential Endpoint.</p>
-<p><strong>Step 14 (Token Request):</strong> The Wallet Instance sends a token request to the PID/(Q)EAA Provider Token Endpoint using the authorization <code class="docutils literal notranslate"><span class="pre">code</span></code>, <code class="docutils literal notranslate"><span class="pre">code_verifier</span></code> and <em>DPoP Proof JWT</em>. The PID/(Q)EAA Provider performs the following checks:</p>
+<p><strong>Step 14 (Token Request):</strong> The Wallet Instance sends a token request to the PID/(Q)EAA Provider Token Endpoint with a <em>DPoP Proof JWT</em>  and the parameters: <code class="docutils literal notranslate"><span class="pre">code</span></code>, <code class="docutils literal notranslate"><span class="pre">code_verifier</span></code>, and OAuth 2.0 Attestation based Client Authentication  (<code class="docutils literal notranslate"><span class="pre">client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation</span></code> and <code class="docutils literal notranslate"><span class="pre">client_assertion=WIA~WIA-PoP</span></code>).
+The <code class="docutils literal notranslate"><span class="pre">client_assertion</span></code> is signed using the private key that is created during the setup phase to obtain the Wallet Instance Attestation. The related public key that is attested by the Wallet Provider is provided within the Wallet Instance Attestation (<code class="docutils literal notranslate"><span class="pre">cnf</span></code> claim). The PID/(Q)EAA Provider performs the following checks on the Token Request:</p>
 <blockquote>
 <div><ol class="arabic simple">
 <li><p>It MUST ensure that the Authorization <code class="docutils literal notranslate"><span class="pre">code</span></code> is issued to the authenticated Wallet Instance (<span class="target" id="index-26"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc6749.html"><strong>RFC 6749</strong></a>) and was not replied.</p></li>
@@ -1372,7 +1373,7 @@ <h2>Detailed Flow<a class="headerlink" href="#detailed-flow" title="Permalink to
 <span class="p">}</span>
 </pre></div>
 </div>
-<p>And the The JWS payload:</p>
+<p>And the JWS payload:</p>
 <div class="highlight-JSON notranslate"><div class="highlight"><pre><span></span><span class="p">{</span>
 <span class="w">    </span><span class="nt">&quot;iss&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;0b434530-e151-4c40-98b7-74c75a5ef760&quot;</span><span class="p">,</span>
 <span class="w">    </span><span class="nt">&quot;aud&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;https://pid-provider.example.org&quot;</span><span class="p">,</span>
@@ -1391,7 +1392,7 @@ <h2>Detailed Flow<a class="headerlink" href="#detailed-flow" title="Permalink to
 <li><p>It MUST verify the Trust Chain in the header of SD-JWT VC to verify that the PID Provider is trusted.</p></li>
 </ol>
 </div></blockquote>
-<p>If the checks defined above are successful the Wallet Instance proceeds with the secure storage of the Digital Credential.</p>
+<p>If the checks defined above are successful the Wallet Instance proceeds with the secure storage of the PID/(Q)EAA.</p>
 <div class="highlight-http notranslate"><div class="highlight"><pre><span></span><span class="kr">HTTP</span><span class="o">/</span><span class="m">1.1</span> <span class="m">200</span> <span class="ne">OK</span>
 <span class="na">Content-Type</span><span class="o">:</span> <span class="l">application/json</span>
 <span class="na">Cache-Control</span><span class="o">:</span> <span class="l">no-store</span>