Merge branch 'main' into pb/typ_values

Author: paulbastian

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

@@ -41,6 +41,7 @@ normative:
     target: "https://www.iana.org/assignments/http-fields/http-fields.xhtml"
 informative:
   RFC6749: RFC6749
+  RFC9334: RFC9334
   RFC7523: RFC7523
   ARF:
   	title: "The European Digital Identity Wallet Architecture and Reference Framework"
@@ -120,6 +121,56 @@ Client Instance:
 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.
 
+# 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 "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
+
+# Client Attestation
+
+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). These JWTs are transmitted via HTTP headers in an HTTP request from a Client Instance to an Authorization Server or Resource Server. The primary purpose of these headers is to authenticate the Client Instance.
+
+## Client Attestation HTTP Headers {#headers}
+
+A Client Attestation JWT and Client Attestation PoP JWT is included in an HTTP request using the following request header fields.
+
+OAuth-Client-Attestation:
+: A JWT that conforms to the structure and syntax as defined in [](#client-attestation-jwt)
+
+OAuth-Client-Attestation-PoP:
+: A JWT that adheres to the structure and syntax as defined in [](#client-attestation-pop-jwt)
+
+The following is an example of the OAuth-Client-Attestation header.
+
+~~~
+OAuth-Client-Attestation: eyJhbGciOiAiRVMyNTYiLCJraWQiOiAiMTEifQ.eyJ\
+pc3MiOiJodHRwczovL2NsaWVudC5leGFtcGxlLmNvbSIsInN1YiI6Imh0dHBzOi8vY2x\
+pZW50LmV4YW1wbGUuY29tIiwibmJmIjoxMzAwODE1NzgwLCJleHAiOjEzMDA4MTkzODA\
+sImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJ1c2UiOiJzaWciLCJjcnYiOiJQLTI1NiI\
+sIngiOiIxOHdITGVJZ1c5d1ZONlZEMVR4Z3BxeTJMc3pZa01mNko4bmpWQWlidmhNIiw\
+ieSI6Ii1WNGRTNFVhTE1nUF80Zlk0ajhpcjdjbDFUWGxGZEFnY3g1NW83VGtjU0EifX1\
+9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+~~~
+
+The following is an example of the OAuth-Client-Attestation-PoP header.
+
+~~~
+OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiJ9.ewogICJpc3MiOiAia\
+HR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20iLAogICJhdWQiOiAi\aHR0cHM6Ly9hcy5l\
+eGFtcGxlLmNvbSIsCiAgIm5iZiI6MTMwMDgxNTc4MCwKICAiZXhwIjoxMzAwODE5Mzgw\
+LAogICJqdGkiOiAiZDI1ZDAwYWItNTUyYi00NmZjLWFlMTktOThmNDQwZjI1MDY0IiwK\
+ICAibm9uY2UiIDogIjVjMWE5ZTEwLTI5ZmYtNGMyYi1hZTczLTU3YzA5NTdjMDljNCIK\
+fQ.coB_mtdXwvi9RxSMzbIey8GVVQLv9qQrBUqmc1qj9Bs
+~~~
+
+Note that per {{RFC9110}} header field names are case-insensitive; so OAUTH-CLIENT-ATTESTATION, oauth-client-attestation, etc., are all valid and equivalent
+header field names. Case is significant in the header field value, however.
+
 # 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 .
@@ -223,7 +274,7 @@ The following example is the decoded header and payload of a JWT meeting the pro
 
 # Client Attestation using a Header based syntax
 
-The default way to present a Client Attestation is by using the header-based syntax that can be used at different endpoints.
+The following section defines how a Client Attestation can be provided in an HTTP request using HTTP headers.
 
 ## Client Attestation HTTP Headers {#headers}
 
@@ -272,12 +323,12 @@ token68                        = 1*( ALPHA / DIGIT / "-" / "." /
 
 It is RECOMMENDED that the authorization server validate the Client Attestation JWT prior to validating the Client Attestation PoP.
 
-## Checking HTTP requests feature client attestations {#checking-http-requests-with-client-attestations}
+## Validating HTTP requests feature client attestations {#checking-http-requests-with-client-attestations}
 
 To validate an HTTP request which contains the client attestation headers, the receiving server MUST ensure the following with regard to a received HTTP request:
 
 1. There is precisely one OAuth-Client-Attestation HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in []{client-attestation-jwt}.
-2. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in []{client-attestation-pop-jwt}.
+2. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in [](client-attestation-pop-jwt).
 3. The signature of the Client Attestation PoP JWT obtained from the OAuth-Client-Attestation-PoP HTTP header verifies with the Client Instance Key contained in the `cnf` claim of the Client Attestation JWT obtained from the OAuth-Client-Attestation HTTP header.
 
 ## Client Attestation at the Token Endpoint {#token-endpoint}
@@ -344,7 +395,7 @@ response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3
 
 # Concatenated Serialization for Client Attestations {#alternative-representation}
 
-A Client Attestation according to this specification MAY be presented using an alternative representation for cases where the header-based mechanism (as introduced in introduced in []{#headers}) does not fit the underlying protocols, e.g., for direct calls to Browser APIs.
+A Client Attestation according to this specification MAY be presented using an alternative representation for cases where the header-based mechanism (as introduced in introduced in [](#headers) does not fit the underlying protocols, e.g., for direct calls to Browser APIs.
 In those cases, a concatenated serialization of the Client Attestation and Client Attestation PoP can can be used.
 
 ## Concatenated Serialization Format {#format-alternative}
@@ -380,8 +431,8 @@ wvi9RxSMzbIey8GVVQLv9qQrBUqmc1qj9Bs
 
 To validate a client attestation using the concatenated serialization form, the receiving server MUST ensure the following:
 
-1. Before the '~' character, there exists precisely a single well-formed JWT conforming to the syntax outlined in []{client-attestation-jwt}.
-2. After the '~' character, there exists precisely a single well-formed JWT conforming to the syntax outlined in []{client-attestation-pop-jwt}.
+1. Before the '~' character, there exists precisely a single well-formed JWT conforming to the syntax outlined in [](client-attestation-jwt).
+2. After the '~' character, there exists precisely a single well-formed JWT conforming to the syntax outlined in [](client-attestation-pop-jwt).
 3. The signature of the Client Attestation PoP JWT obtained after the '~' character verifies with the Client Instance Key contained in the `cnf` claim of the Client Attestation JWT obtained before the '~' character.
 
 # Implementation Considerations
@@ -485,6 +536,7 @@ This non-normative example shows a client attestations used as an wallet instanc
 
 * restructured JWT Claims for better readability
 * added JOSE typ values for Client Attestation and Client Attestation PoP
+* add RATS relation
 * add concatenated representation without headers
 * add PAR endpoint example
 * fix PoP examples to include jti and nonce