Merge pull request #100 from oauth-wg/pb/introduction2

improve introduction, rename client backend to client attester

Author: c2bo

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

@@ -65,19 +65,25 @@ This specification defines an extension to the OAuth 2 protocol as defined in {{
 
 # Introduction
 
+Traditional OAuth security concepts perform client authentication through a backend channel. In ecosystems such as the Issuer-Holder-Verifier model used in {{SD-JWT}}, this model raises privacy concerns, as it would enable the backend to recognize which Holder (i.e. client) interacts with which Issuer (i.e. Authorization Server) and potentially furthermore see the credentials being issued. This specification establishes a mechanism for a backend-attested client authentication through a frontend channel to address these issues.
+
+Additionally, this approach acknowledges the evolving landscape of OAuth 2 deployments, where the ability for public clients to authenticate securely and reliably has become increasingly important. Leveraging platform mechanisms to validate a client instance, e.g. for mobile native apps, enables secure authentication that would otherwise be difficult with traditional OAuth client authentication methods. Transforming these platform-specific mechanisms into a common format as described in this specification abstracts this complexity to minimize the efforts for the Authorization Server.
+
+This primary purpose of this specification is the authentication of a client instance enabled through the client backend attesting to it. The client backend may also attest further technical properties about the hardware and software of the client instance.
+
 The following diagram depicts the overall architecture and protocol flow.
 
 ~~~ ascii-art
                     (3)
                  +-------+
                  |       |
                  |      \ /
-             +---------------+
-             |               |
-             |    Client     |
-             |    Backend    |
-             |               |
-             +---------------+
+             +--------------------+
+             |                    |
+             |    Client Attester |
+             |      (backend)     |
+             |                    |
+             +--------------------+
                 / \      |
             (2)  |       |  (4)
                  |      \ /
@@ -96,21 +102,19 @@ The following diagram depicts the overall architecture and protocol flow.
 
 The following steps describe this OAuth flow:
 
-(1) The Client Instance generates a key (Client Instance Key) and optional further attestations (that are out of scope) to prove its authenticity to the Client Backend.
+(1) The Client Instance generates a key (Client Instance Key) and optional further attestations (that are out of scope) to prove its authenticity to the Client Attester.
 
-(2) The Client Instance sends this data to the Client Backend in request for a Client Attestation JWT.
+(2) The Client Instance sends this data to the Client Attester in request for a Client Attestation JWT.
 
-(3) The Client Backend validates the Client Instance Key and optional further data. It generates a signed Client Attestation JWT that is cryptographically bound to the Client Instance Key generated by the Client. Therefore, the attestation is bound to this particular Client Instance.
+(3) The Client Attester validates the Client Instance Key and optional further data. It generates a signed Client Attestation JWT that is cryptographically bound to the Client Instance Key generated by the Client. Therefore, the attestation is bound to this particular Client Instance.
 
-(4) The Client Backend responds to the Client Instance by sending the Client Attestation JWT.
+(4) The Client Attester responds to the Client Instance by sending the Client Attestation JWT.
 
 (5) The Client Instance generates a Proof of Possession (PoP) with the Client Instance Key.
 
 (6) The Client Instance sends both the Client Attestation JWT and the Client Attestation PoP JWT to the authorization server, e.g. within a token request. The authorization server validates the Client Attestation and thus authenticates the Client Instance.
 
-Please note that the protocol details for steps (2) and (4), particularly how the Client Instance authenticates to the client Backend, are beyond the scope of this specification. Furthermore, this specification is designed to be flexible and can be implemented even in scenarios where the client does not have a backend server. In such cases, each Client Instance is responsible for performing the functions typically handled by the backend on its own.
-
-This approach acknowledges the evolving landscape of OAuth 2 deployments, where the ability for public clients to authenticate securely and reliably has become increasingly important.
+Please note that the protocol details for steps (2) and (4), particularly how the Client Instance authenticates to the Client Attester, are beyond the scope of this specification. Furthermore, this specification is designed to be flexible and can be implemented even in scenarios where the client does not have a backend serving as a Client Attester. In such cases, each Client Instance is responsible for performing the functions typically handled by the Client Attester on its own.
 
 # Conventions and Definitions
 
@@ -119,7 +123,7 @@ This approach acknowledges the evolving landscape of OAuth 2 deployments, where
 # Terminology
 
 Client Attestation JWT:
-:  A JSON Web Token (JWT) generated by the client backend which is bound to a key managed by a Client Instance which can then be used by the instance for client authentication.
+:  A JSON Web Token (JWT) generated by the Client Attester which is bound to a key managed by a Client Instance which can then be used by the instance for client authentication.
 
 Client Attestation Proof of Possession (PoP) JWT:
 :  A Proof of Possession generated by the Client Instance using the key that the Client Attestation JWT is bound to.
@@ -128,15 +132,18 @@ Client Instance:
 : A deployed instance of a piece of client software.
 
 Client Instance Key:
-:  A cryptographic asymmetric key pair that is generated by the Client Instance where the public key of the key pair is provided to the client backend. This public key is then encapsulated within the Client Attestation JWT and is utilized to sign the Client Attestation Proof of Possession.
+:  A cryptographic asymmetric key pair that is generated by the Client Instance where the public key of the key pair is provided to the Client Attester. This public key is then encapsulated within the Client Attestation JWT and is utilized to sign the Client Attestation Proof of Possession.
+
+Client Attester:
+: An entity that authenticates a Client Instance and attests it by issuing a Client Attestation JWT.
 
 # Relation to RATS
 
 The Remote Attestation Procedures (RATS) architecture defined by {{RFC9334}} has some commonalities to this document. The flow specified in this specification relates to the "Passport Model" in RATS. However, while the RATS ecosystem gives explicit methods and values how the RATS Attester proves itself to the Verifier, this is deliberately out of scope for Attestation-Based Client Authentication. Additionally, the terminology between RATS and OAuth is different:
 
 - a RATS "Attester" relates to an OAuth "Client"
 - a RATS "Relying Party" relates to an OAuth "Authorization Server or Resource Server"
-- a RATS "Verifier" relates to the "Client Backend" defined in this specification
+- a RATS "Verifier" relates to the "Client Attester" defined in this specification
 - a RATS "Attestion Result" relates to the "Client Attestation JWT" defined by this specification
 - a RATS "Endorser", "Reference Value Provider", "Endorsement", "Evidence" and "Policies and Reference Values" are out of scope for this specification
 
@@ -427,7 +434,7 @@ Authorization servers issuing a refresh token in response to a token request usi
 Because the Client Attestation and Client Attestation PoP are communicated using HTTP headers, implementers should consider that web servers may have a default maximum HTTP header size configured which could be too low to allow conveying a Client Attestation and or Client Attestation PoP in an HTTP request. It should be noted, that this limit is not given by the HTTP {{RFC9112}}, but instead web server implementations commonly set a default maximum size for HTTP headers. As of 2024, typical limits for modern web servers configure maximum HTTP headers as 8 kB or more as a default.
 ## Rotation of Client Instance Key
 
-This specification does not provide a mechanism to rotate the Client Instance Key in the Client Attestation JWT's "cnf" claim. If the Client Instance needs to use a new Client Instance Key for any reason, then it MUST request a new Client Attestation JWT from its Client Backend.
+This specification does not provide a mechanism to rotate the Client Instance Key in the Client Attestation JWT's "cnf" claim. If the Client Instance needs to use a new Client Instance Key for any reason, then it MUST request a new Client Attestation JWT from its Client Attester.
 
 # Privacy Considerations
 
@@ -478,6 +485,8 @@ This section requests registration of the following scheme in the "Hypertext Tra
 
 -05
 
+* improve introduction
+* rename client backend to client attester
 * fix missing typ header in examples
 
 -04