Merge pull request #128 from oauth-wg/tl/issue_117

Editorial nit about usage of client attestation outside of OAuth

Author: tplooker

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

@@ -159,7 +159,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}
 
@@ -597,6 +597,7 @@ This section requests registration of the following scheme in the "Hypertext Tra
 
 -06
 
+* clarify usage of client attestation outside of oauth2 applications
 * add oauth error response values `invalid_client_attestation` and `use_attestation_challenge`
 * revert the HTTP OPTIONS mechanism to fetch nonces and add a dedicated challenge endpoint
 * rename nonce to challenge