You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: draft-ietf-oauth-attestation-based-client-auth.md
+4-3Lines changed: 4 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -189,7 +189,7 @@ The following additional rules apply:
189
189
190
190
1. The JWT MAY contain other claims. All claims that are not understood by implementations MUST be ignored.
191
191
192
-
2. The JWT MUST be digitally signed using an asymmetric cryptographic algorithm. The authorization server MUST reject the JWT if it is using a Message Authentication Code (MAC) based algorithm. The authorization server MUST reject JWTs with an invalid signature.
192
+
2. The JWT MUST be digitally signed or integrity protected with a Message Authentication Code (MAC). The authorization server MUST reject JWTs if signature or integrity protection validation fails.
193
193
194
194
3. The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" {{RFC7519}}.
195
195
@@ -240,7 +240,7 @@ The following additional rules apply:
240
240
241
241
1. The JWT MAY contain other claims. All claims that are not understood by implementations MUST be ignored.
242
242
243
-
2. The JWT MUST be digitally signed using an asymmetric cryptographic algorithm. The authorization server MUST reject the JWT if it is using a Message Authentication Code (MAC) based algorithm. The authorization server MUST reject JWTs with an invalid signature.
243
+
2. The JWT MUST be digitally signed using an asymmetric cryptographic algorithm. The authorization server MUST reject JWTs with an invalid signature.
244
244
245
245
3. The public key used to verify the JWT MUST be the key located in the "cnf" claim of the corresponding Client Attestation JWT.
246
246
@@ -513,7 +513,7 @@ Upon receiving a Client Attestation, the receiving server MUST ensure the follow
513
513
514
514
2. The Client Attestation JWT contains all claims and header parameters as per [](#client-attestation-jwt).
515
515
3. The Client Attestation PoP JWT contains all claims and header parameters as per [](#client-attestation-pop-jwt).
516
-
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.
516
+
4. The alg JOSE Header Parameter for both JWTs indicates a registered asymmetric digital signature algorithm {{IANA.JOSE.ALGS}}, is not none, is supported by the application, and is acceptable per local policy.
517
517
5. The signature of the Client Attestation JWT verifies with the public key of a known and trusted Attester.
518
518
6. The key contained in the `cnf` claim of the Client Attestation JWT is not a private key.
519
519
7. The signature of the Client Attestation PoP JWT verifies with the public key contained in the `cnf` claim of the Client Attestation JWT.
@@ -645,6 +645,7 @@ This section requests registration of the following scheme in the "Hypertext Tra
645
645
646
646
-07
647
647
648
+
* remove restrictions to not allow MAC-based algorithms
648
649
* require `iat` in Client Attestation PoP JWT
649
650
* clarify `use_attestation_challenge` and add `invalid_client_attestation`
0 commit comments