fix for issue 117

Author: tplooker

draft-ietf-oauth-attestation-based-client-auth.md

@@ -154,7 +154,7 @@ The Remote Attestation Procedures (RATS) architecture defined by {{RFC9334}} has
 
 # Client Attestation Format
 
-This draft introduces the concept of client attestations to the OAuth 2 protocol, using two JWTs: a Client Attestation and a Client Attestation Proof of Possession (PoP). The primary purpose of these JWTs is to authenticate the Client Instance. These JWTs can be transmitted via HTTP headers in an HTTP request (as described in [](#headers)) from a Client Instance to an Authorization Server or Resource Server, or via a concatenated serialization (as described in [](#alternative-representation)) to enable usage outside of the traditional OAuth2 ecosystem .
+This draft introduces the concept of client attestations to the OAuth 2 protocol, using two JWTs: a Client Attestation and a Client Attestation Proof of Possession (PoP). The primary purpose of these JWTs is to authenticate the Client Instance. These JWTs can be transmitted via HTTP headers in an HTTP request (as described in [](#headers)) from a Client Instance to an Authorization Server or Resource Server, or via a concatenated serialization (as described in [](#alternative-representation)) to enable usage outside of OAuth2 based interactions.
 
 ## Client Attestation JWT {#client-attestation-jwt}
 
@@ -542,6 +542,7 @@ This section requests registration of the following scheme in the "Hypertext Tra
 * improve introduction
 * rename client backend to client attester
 * fix missing typ header in examples
+* clarify usage of client attestation outside of oauth2 applications
 
 -04