Remove whitespaces that broke the build (#29)

* Remove whitespaces that broke the build

Removing extra whitespaces.

* Removed additional whitespace

draft-saxe-wimse-token-exchange-and-translation.md

@@ -98,7 +98,7 @@ The server issuing access tokens to the client after successfully authenticating
 
 * workload [[draft-ietf-wimse-arch](https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch)]
 
-A workload is a running instance of software executing for a specific purpose. Workload typically interacts with other parts of a larger system. A workload may exist for a very short durations of time (fraction of a second) and run for a specific purpose such as to provide a response to an API request. Other kinds of workloads may execute for a very long duration, such as months or years. Examples include database services and machine learning training jobs. 
+A workload is a running instance of software executing for a specific purpose. Workload typically interacts with other parts of a larger system. A workload may exist for a very short durations of time (fraction of a second) and run for a specific purpose such as to provide a response to an API request. Other kinds of workloads may execute for a very long duration, such as months or years. Examples include database services and machine learning training jobs.
 
 * token
 
@@ -133,11 +133,11 @@ TODO - Define a new translation endpoint.
 
 TODO - this draft does not define normative specs for translating from arbitrary format to another arbitrary format.  Profiles describing specific token translations must be developed and their names (possibly?) registered with IANA.  Profiles will define any losses that may occur during translation and the risks associated with the loss of context.  Not all token pairs can be translated, some may only be translatable in one direction.
 
-## X.509 Certificate to Access Token Profile 
+## X.509 Certificate to Access Token Profile
 
 In [[draft-ietf-wimse-arch](https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch)], Workloads may be issued Identity Credentials in the form of X.509 Certificates [[RFC5280](https://datatracker.ietf.org/doc/html/rfc5280)], for Workload-to-Workload communication over mututal TLS (mTLS). Workload Agents must request the X.509 Certificate Credentials by undergoing Attestation against both the local Host Operating System and Hardware, and a remote Server with access to a Certificate Authority (CA). If the Server confirms sufficient evidence has been presented for Attestation, the Workload is issued X.509 Certificates identifying it. The identity is conveyed in a URI Subject Aleternative Name (SAN) within the X.509 Certificate.
 
-Authorization servers issue OAuth 2.0 Access Tokens to client applications.  If the resource owner has granted sufficient privileges to a protected resource, the issued access token can be used to access protected resources on resource servers. 
+Authorization servers issue OAuth 2.0 Access Tokens to client applications.  If the resource owner has granted sufficient privileges to a protected resource, the issued access token can be used to access protected resources on resource servers.
 
 The Workloads possessing X.509 Certificate Identity Credentials may operate in an environment that is isolated from the security domain of a protected resource. In the case where the protected resource is protected by an external OAuth 2.0 Authorization Server, X.509 Certificate-to-Access Token exchange may be configured. The Trust across the isolated security domains must first be established. Relying parties must describe, via secure configurations, a mapping that crosses the security domains from the X.509 certificate authority(ies) to the OAuth 2.0 authorization server. The specification for authenticating the relying party and for the format of the configurations are out of scope of this specification. The following configurations MAY be registered by a relying party at the OAuth 2.0 authorization server:
 
@@ -182,7 +182,7 @@ The response document contains the following properties (per [[RFC8693](https://
 
 The X.509 Certificate-to-Access Token Exchange Profile MUST NOT relax the validity constraint of the input security context. The returned Access Token MUST NOT have a not before claim that preceeds the `notBefore` constraint of the X.509 Certificate used. The returned Access Token MUST NOT have an expiration time claim that exceeds the `notAfter` constraint of the X.509 Certificate used.
 
-To mitigate the impact of Access Token theft, it is RECOMMENDED that the returned Access Token be sender-constrained. The Authorization Server MAY bind the Access Token to the X.509 Certificate that was used to obtain it, in the manner described in [Section 3](https://datatracker.ietf.org/doc/html/rfc8705#name-mutual-tls-client-certifica) of [[RFC8705](https://datatracker.ietf.org/doc/html/rfc8705)]. Based on authentication policy, Resource Servers MAY enforce that an Access Token bound to an X.509 Certificate CAN NOT be used to access any protected resources, unless the same X.509 Certificate was used during the mTLS handshake to the Resource Server. 
+To mitigate the impact of Access Token theft, it is RECOMMENDED that the returned Access Token be sender-constrained. The Authorization Server MAY bind the Access Token to the X.509 Certificate that was used to obtain it, in the manner described in [Section 3](https://datatracker.ietf.org/doc/html/rfc8705#name-mutual-tls-client-certifica) of [[RFC8705](https://datatracker.ietf.org/doc/html/rfc8705)]. Based on authentication policy, Resource Servers MAY enforce that an Access Token bound to an X.509 Certificate CAN NOT be used to access any protected resources, unless the same X.509 Certificate was used during the mTLS handshake to the Resource Server.
 
 # Conventions and Definitions