From a6df619bcbc329efa7b862bf3dd16458e0fad7f2 Mon Sep 17 00:00:00 2001 From: Jacob Date: Mon, 13 Nov 2023 10:48:30 +0000 Subject: [PATCH 1/2] Add text on cnf key rotation --- draft-ietf-oauth-attestation-based-client-auth.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index f3e8030..94a1222 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -243,6 +243,10 @@ Implementers should be aware that the design of this authentication mechanism de Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 {{RFC6749}}. To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation" authentication method. The client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used for client authentication when the refresh token was issued. +## Rotation of confirmation key + +This specification does not provide a mechanism to rotate the confirmation key identified in the Client Attestation JWT. If the client instance needs to use a new confirmation key for any reason, then it MUST begin the OAuth 2.0 flow from scratch. + # Privacy Considerations ## Client Instance Tracking Across Authorization Servers From 4e783cc13e5929318a5915c67407e6d184c14aa0 Mon Sep 17 00:00:00 2001 From: Jacob Date: Tue, 14 Nov 2023 14:16:28 +0000 Subject: [PATCH 2/2] 'Client Instance Key' instead of 'confirmation key' Co-authored-by: Paul Bastian --- draft-ietf-oauth-attestation-based-client-auth.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 94a1222..51b2f30 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -243,9 +243,9 @@ Implementers should be aware that the design of this authentication mechanism de Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 {{RFC6749}}. To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation" authentication method. The client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used for client authentication when the refresh token was issued. -## Rotation of confirmation key +## Rotation of Client Instance Key -This specification does not provide a mechanism to rotate the confirmation key identified in the Client Attestation JWT. If the client instance needs to use a new confirmation key for any reason, then it MUST begin the OAuth 2.0 flow from scratch. +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. # Privacy Considerations