new preview build

fsc-core/certificate-renewal/index.html

@@ -1006,7 +1006,7 @@ <h2>
 <p>In this scenario the Peer has to create a new accept signature using the new certificate and resend it to the other Peers on the Contract.<br>Without a valid certificate, Peers cannot verify the signature, rendering the Contract invalid.</p>
 </section><section id="a-contract-contains-a-serviceconnectiongrant-s-with-a-thumbprint-of-a-public-key-used-by-a-certificate-that-expires-before-the-contract-expires"><div class="header-wrapper"><h5 id="x3-2-6-2-a-contract-contains-a-serviceconnectiongrant-s-with-a-thumbprint-of-a-public-key-used-by-a-certificate-that-expires-before-the-contract-expires"><bdi class="secno">3.2.6.2 </bdi>A Contract contains a ServiceConnectionGrant(s) with a thumbprint of a public key used by a certificate that expires before the Contract expires.</h5><a class="self-link" href="#a-contract-contains-a-serviceconnectiongrant-s-with-a-thumbprint-of-a-public-key-used-by-a-certificate-that-expires-before-the-contract-expires" aria-label="Permalink for Section 3.2.6.2"></a></div>
 <p>In this scenario, the Peer can renew the certificate without rotating the keypair, ensuring that the public key thumbprint remains unchanged. As a result, the Contract remains unaffected. 
-However, if the keypair is rotated, the public key thumbprint will change, and the Outway can no longer use the ServiceConnectionGrant to connect to the Service. As a result, a new Contract will need to be created containing a ServiceConnectionGrant with the new public key thumbprint.</p>
+However, if the keypair is rotated, the public key thumbprint will change and the Outway can no longer use the ServiceConnectionGrant to connect to the Service. As a result, a new Contract will need to be created containing a ServiceConnectionGrant with the new public key thumbprint.</p>
 </section></section></section><section id="access-token"><div class="header-wrapper"><h3 id="access_token"><bdi class="secno">3.3 </bdi>Access token</h3><a class="self-link" href="#access_token" aria-label="Permalink for Section 3.3"></a></div><p>The access token is a JSON Web Token (JWT) as specified in [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc7519" title="JSON Web Token (JWT)">RFC7519</a></cite>]</p>
 <p>The JWT <strong><em class="rfc2119">MUST</em></strong> specify the thumbprint of the X.509 certificate used to sign the JWT using the <code>x5t#S256</code> <a href="https://www.rfc-editor.org/rfc/rfc7515#section-4.1.8">section 4.1.8</a> of [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc7515" title="JSON Web Signature (JWS)">RFC7515</a></cite>] field of the <code>JOSE Header</code>  <a href="https://www.rfc-editor.org/rfc/rfc7515#section-4">section 4</a> of [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc7515" title="JSON Web Signature (JWS)">RFC7515</a></cite>].</p>
 <p>The JWT <strong><em class="rfc2119">MUST</em></strong> be created using one of the following digital signature algorithms:</p>