remove iss from pop

Author: tplooker

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

@@ -182,7 +182,6 @@ The following content applies to the JWT Claims Set:
 * `exp`: REQUIRED. The `exp` (expiration time) claim MUST specify the time at which the Client Attestation is considered expired by its issuer. The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems.
 * `cnf`: REQUIRED. The `cnf` (confirmation) claim MUST specify a key conforming to {{RFC7800}} that is used by the Client Instance to generate the Client Attestation PoP JWT for client authentication with an authorization server. The key MUST be expressed using the "jwk" representation.
 * `iat`: OPTIONAL. The `iat` (issued at) claim MUST specify the time at which the Client Attestation was issued.
-* `nbf`: OPTIONAL. The `nbf` (not before) claim MUST specify the time before which the Client Attestation MUST NOT be accepted for processing.
 
 The following additional rules apply:
 
@@ -229,7 +228,6 @@ The following content applies to the JWT Header:
 
 The following content applies to the JWT Claims Set:
 
-* `iss`: REQUIRED. The `iss` (issuer) claim MUST specify client_id value of the OAuth Client.
 * `aud`: REQUIRED. The `aud` (audience) claim MUST specify a value that identifies the authorization server as an intended audience. The {{RFC8414}} issuer identifier URL of the authorization server MUST be used as a value for an "aud" element to identify the authorization server as the intended audience of the JWT.
 * `jti`: REQUIRED. The `jti` (JWT identifier) claim MUST specify a unique identifier for the Client Attestation PoP. The authorization server can utilize the `jti` value for replay attack detection, see [](#security-consideration-replay).
 * `iat`: REQUIRED. The `iat` (issued at) claim MUST specify the time at which the Client Attestation PoP was issued. Note that the authorization server may reject JWTs with an "iat" claim value that is unreasonably far in the past.
@@ -243,9 +241,8 @@ The following additional rules apply:
 
 3. The public key used to verify the JWT MUST be the key located in the "cnf" claim of the corresponding Client Attestation JWT.
 
-4. The value of the `iss` claim, representing the client_id MUST match the value of the `sub` claim in the corresponding Client Attestation JWT.
 
-5. The Authorization Server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" {{RFC7519}}.
+4. The Authorization Server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" {{RFC7519}}.
 
 The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.
 
@@ -256,7 +253,6 @@ The following example is the decoded header and payload of a JWT meeting the pro
 }
 .
 {
-  "iss": "https://client.example.com",
   "aud": "https://as.example.com",
   "iat": 1300814780,
   "jti": "d25d00ab-552b-46fc-ae19-98f440f25064",
@@ -340,7 +336,7 @@ While usage of the the client attestation mechanism defined by this draft can be
 
 The Authorization Server MUST perform all of the checks outlined in [](#checking-http-requests-with-client-attestations) for a received access token request which is making use of the client attestation mechanism as defined by this draft.
 
-If the token request contains a `client_id` parameter as per {{RFC6749}} the Authorization Server MUST verify that the value of this parameter is the same as the client_id value in the `sub` claim of the Client Attestation and `iss` claim of the Client Attestation PoP.
+If the token request contains a `client_id` parameter as per {{RFC6749}} the Authorization Server MUST verify that the value of this parameter is the same as the client_id value in the `sub` claim of the Client Attestation.
 
 If the Authorization Server supports it, a client MAY instead use the combined client attestation and DPoP mode described in [](#combined-dpop).
 
@@ -419,9 +415,7 @@ In order to detect whether this combined mode is being used, the following condi
 
 Provided the above conditions are meet the following additional rules apply:
 1. The public key located in the DPoP proof MUST match the public key located in the `cnf` claim of the Client Attestation JWT.
-2. Beyond what is defined in {{RFC9449}} the following additional claims in the DPoP proof apply.
-    * `iss`: REQUIRED. Value is the client_id (matching the `sub` of the Client Attestation JWT).
-3. As per {{RFC9449}} the DPoP proof `typ` header value MUST be `dpop+jwt`.
+2. As per {{RFC9449}} the DPoP proof `typ` header value MUST be `dpop+jwt`.
 
 // TODO error handling
 
@@ -453,7 +447,6 @@ Header:
 
 Payload:
 {
-  "iss": "https://client.example.com",
   "htm": "POST",
   "htu": "https://as.example.com/token",
   "iat": 1700000000,
@@ -584,7 +577,7 @@ Upon receiving a Client Attestation, the receiving server MUST ensure the follow
 10. The audience claim in the Client Attestation PoP JWT is the issuer identifier URL of the authorization server as described in {{RFC8414}}.
 11. The Client Attestation JWT is fresh enough for the policies of the authorization server by checking the `iat` or `exp` claims.
 12. Depending on the security requirements of the deployment, additional checks to guarantee replay protection for the Client Attestation PoP JWT might need to be applied (see [](#security-consideration-replay) for more details).
-13. If a `client_id` is provided in the request containing the Client Attestation, then this `client_id` matches the `sub` claim of the Client Attestation JWT and the `iss` claim of the Client Attestation PoP JWT.
+13. If a `client_id` is provided in the request containing the Client Attestation, then this `client_id` matches the `sub` claim of the Client Attestation JWT.
 
 # Implementation Considerations