add verification and processing rules

Author: c2bo

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

@@ -53,6 +53,12 @@ normative:
       org: "IANA"
     title: "OAuth Authorization Server Metadata"
     target: "https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata"
+  IANA.JOSE.ALGS:
+    author:
+      org: "IANA"
+    title: "JSON Web Signature and Encryption Algorithms"
+    target: "https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms"
+
 informative:
   RFC6749: RFC6749
   RFC9334: RFC9334
@@ -253,7 +259,7 @@ The following example is the decoded header and payload of a JWT meeting the pro
 }
 ~~~
 
-# Client Attestation using a Header based syntax
+# Client Attestation using a Header based syntax {#header-based}
 
 The following section defines how a Client Attestation can be provided in an HTTP request using HTTP headers.
 
@@ -310,8 +316,8 @@ It is RECOMMENDED that the authorization server validate the Client Attestation
 
 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).
+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).
 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}
@@ -420,8 +426,8 @@ SSWB7UhHfvLOVU_ZvAJfOWfO0MXyeunwzM3jGLB_TUkQ
 
 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.
 
 # Nonce Retrieval {#nonce-retrieval}
@@ -432,7 +438,7 @@ An Authorization Server compliant with this specification SHOULD signal via the
 
 A Request to an endpoint supporting the server-provided nonce MUST include the `attestation-nonce-request` field name with the value `true` and use the HTTP method of type OPTIONS (without payload) to actively request a nonce. The server answers with an HTTP Response with status code 200 without body, but sets the header field `attestation-nonce` to the nonce.
 
-The client MUST use this nonce in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt).
+The client MUST use this nonce in the OAuth-Attestation-PoP as defined in [](#client-attestation-pop-jwt).
 
 The following is a non-normative example of a request:
 
@@ -450,6 +456,25 @@ Host: as.example.com
 attestation-nonce: AYjcyMzY3ZDhiNmJkNTZ
 ~~~
 
+# Verification and Processing
+
+Upon receiving a Client Attestation, the receiving server MUST ensure the following:
+
+1. If the Client Attestation was received via Header based Syntax (as described in [](#header-based)):
+
+    * The HTTP request contains exactly one field `OAuth-Client-Attestation` and one field `OAuth-Client-Attestation-PoP`.
+    * Both fields contain exactly one well-formed JWT.
+
+2. The Client Attestation JWT contains all claims and header parameters as per [](#client-attestation-jwt).
+3. The Client Attestation PoP JWT contains all claims and header parameters as per [](#client-attestation-pop-jwt).
+4. The alg JOSE Header Parameter for both JWTs indicates a registered asymmetric digital signature algorithm {{IANA.JOSE.ALGS}}, is not none, is not MAC based, is supported by the application, and is acceptable per local policy.
+5. The signature of the Client Attestation JWT verifies with the public key of a known and trusted Attester.
+6. The key contained in the `cnf` claim of the Client Attestation JWT is not a private key.
+7. The signature of the Client Attestation PoP JWT verifies with the public key contained in the `cnf` claim of the Client Attestation JWT.
+8. If the server provided a challenge value to the client, the `challenge` claim is present in the Client Attestation PoP JWT and matches the server-provided challenge value.
+9. The creation time of the Client Attestation PoP JWT as determined by either the `iat` claim or a server managed timestamp via the challenge claim, is within an acceptable window.
+10. The audience claim in the Client Attestation PoP JWT is the issuer identifier URL of the authorization server as described in {{RFC8414}} .
+
 # Implementation Considerations
 
 ## Reuse of a Client Attestation JWT
@@ -542,6 +567,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
+* add verification and processing rules
 
 -04