Deploy to GitHub pages

tc-offline.html

@@ -2038,14 +2038,14 @@ <h3 id="name-wallet-establishing-trust-i">
       <h2 id="name-implementation-consideratio">
 <a href="#section-10" class="section-number selfRef">10. </a><a href="#name-implementation-consideratio" class="section-name selfRef">Implementation Considerations for Offline Flows</a>
       </h2>
-<p id="section-10-1">The static Trust Chain parameter within the JWT headers, as defined in <span>[<a href="#OpenID.Federation" class="cite xref">OpenID.Federation</a>]</span> Section 4.3, is used to hint to the entity involved in a transaction to have a common Trust Anchor. This facilitate the trust evaluation without the need for real-time Federation Entity Discovery using the Federation API endpoints.<a href="#section-10-1" class="pilcrow">¶</a></p>
-<p id="section-10-2">Entity that issues a signed data object, including the <code>trust_chain</code> parameter, might be:<a href="#section-10-2" class="pilcrow">¶</a></p>
+<p id="section-10-1">The static Trust Chain parameter within the JWT headers, as defined in Section 4.3 of <span>[<a href="#OpenID.Federation" class="cite xref">OpenID.Federation</a>]</span>, is used as a hint to the Entity involved in a transaction to have a common Trust Anchor. This facilitates the trust evaluation without the need for real-time Federation Entity Discovery using the Federation API endpoints.<a href="#section-10-1" class="pilcrow">¶</a></p>
+<p id="section-10-2">The Entity that issues a signed data object, including the <code>trust_chain</code> parameter, might be:<a href="#section-10-2" class="pilcrow">¶</a></p>
 <ul class="compact">
 <li class="compact" id="section-10-3.1">Wallet Providers in signed Wallet Attestations. The Wallet Instance obtains one or more Wallet Attestations from its Wallet Provider, each of them including a Trust Chain related to each Trust Anchor the Wallet Provider trusts;<a href="#section-10-3.1" class="pilcrow">¶</a>
 </li>
-        <li class="compact" id="section-10-3.2">Credential Verifiers in signed request objects. The Wallet Instance obtains a presentation request which includes a Trust Chain using a Trust Anchor that the Credential Verifier has in common with the Wallet Provider, according to the <code>wallet_metadata</code> parameter provided by the Wallet in the Request URI POST;<a href="#section-10-3.2" class="pilcrow">¶</a>
+        <li class="compact" id="section-10-3.2">Credential Verifiers in signed request objects. The Wallet Instance obtains a presentation request that includes a Trust Chain using a Trust Anchor that the Credential Verifier has in common with the Wallet Provider, according to the <code>wallet_metadata</code> parameter provided by the Wallet in the Request URI POST;<a href="#section-10-3.2" class="pilcrow">¶</a>
 </li>
-        <li class="compact" id="section-10-3.3">Credential Issuers in signed Digital Credential. The Wallet Instance obtains a Digital Credential from its Credential Issuer, which includes the Trust Chain using a Trust Anchor that the Credential Verifier has in common with the Wallet Provider, according to the Wallet Attestation used during the Issuance.<a href="#section-10-3.3" class="pilcrow">¶</a>
+        <li class="compact" id="section-10-3.3">A Credential Issuer in a signed Digital Credential. The Wallet Instance obtains a Digital Credential from its Credential Issuer, which includes the Trust Chain using a Trust Anchor that the Credential Verifier has in common with the Wallet Provider, according to the Wallet Attestation used during the Issuance.<a href="#section-10-3.3" class="pilcrow">¶</a>
 </li>
       </ul>
 <p id="section-10-4">The Entity that receives the data object including the JWT <code>trust_chain</code>, such as the Wallet Instance obtaining a signed request object, verifies the Trust Chain using the Trust Anchor's public keys and applies any metadata policies, without needing to have a working internet connection for reaching the Federation API.<a href="#section-10-4" class="pilcrow">¶</a></p>