From 12d5819d6762d2e1834a8f54a97b09b36830fea5 Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Tue, 9 Sep 2025 12:03:50 +1200 Subject: [PATCH 1/5] artefact binding --- draft-ietf-oauth-attestation-based-client-auth.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 1b9c92c..d69765a 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -69,6 +69,9 @@ informative: ARF: title: "The European Digital Identity Wallet Architecture and Reference Framework" SD-JWT: I-D.ietf-oauth-selective-disclosure-jwt + CIBA: + title: OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 + target: https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html --- abstract @@ -533,6 +536,15 @@ 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 client attestation mechanism as defined by this draft MUST bind the refresh token to the Client Instance and its associated public key, and NOT just the client as specified in section 6 {{RFC6749}}. To prove this binding, the Client Instance MUST use the client attestation mechanism when refreshing an access token. The client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used when the refresh token was issued. +## Binding of OAuth protocol artefacts + +Authorization servers where possible are RECOMMENDED to bind relevant protocol artefacts to the Client Instance and its associated public key, and NOT just the client as specified in section 6 {{RFC6749}}. Examples of these artefacts include but are not limited to: + +- The authorization_code as specified in section 4.1 {{RFC6749}}. +- The auth_req_id as specified in section 7.3 {{CIBA}}. + +How this binding is established and then proven is specific to the protocol artifact. For example establishing binding to an authorization_code involves the client instance using client attestation in the authorization request, and proving binding of the authorization_code to the Client Instance involves using the client attestation mechanism to authenticate at the token endpoint using an authorization code grant. + ## Web Server Default Maximum HTTP Header Sizes Because the Client Attestation and Client Attestation PoP are communicated using HTTP headers, implementers should consider that web servers may have a default maximum HTTP header size configured which could be too low to allow conveying a Client Attestation and or Client Attestation PoP in an HTTP request. It should be noted, that this limit is not given by the HTTP {{RFC9112}}, but instead web server implementations commonly set a default maximum size for HTTP headers. As of 2024, typical limits for modern web servers configure maximum HTTP headers as 8 kB or more as a default. From 3992d291ea56575807a646bfe965686bf6dc4cc9 Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Tue, 9 Sep 2025 18:36:54 +1200 Subject: [PATCH 2/5] Update draft-ietf-oauth-attestation-based-client-auth.md --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index d69765a..c81b825 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -543,7 +543,7 @@ Authorization servers where possible are RECOMMENDED to bind relevant protocol a - The authorization_code as specified in section 4.1 {{RFC6749}}. - The auth_req_id as specified in section 7.3 {{CIBA}}. -How this binding is established and then proven is specific to the protocol artifact. For example establishing binding to an authorization_code involves the client instance using client attestation in the authorization request, and proving binding of the authorization_code to the Client Instance involves using the client attestation mechanism to authenticate at the token endpoint using an authorization code grant. +How this binding is established and then proven is specific to the protocol artefact. For example establishing binding to an authorization_code involves the client instance using client attestation in the authorization request, and proving binding of the authorization_code to the Client Instance involves using the client attestation mechanism to authenticate at the token endpoint using an authorization code grant. ## Web Server Default Maximum HTTP Header Sizes From 4f5b0c454350296acc6b09bbe45aa5cf330dfc2b Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Mon, 15 Sep 2025 19:28:32 +1200 Subject: [PATCH 3/5] Update draft-ietf-oauth-attestation-based-client-auth.md Co-authored-by: Paul Bastian --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index c81b825..c2bf84d 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -538,7 +538,7 @@ Authorization servers issuing a refresh token in response to a token request usi ## Binding of OAuth protocol artefacts -Authorization servers where possible are RECOMMENDED to bind relevant protocol artefacts to the Client Instance and its associated public key, and NOT just the client as specified in section 6 {{RFC6749}}. Examples of these artefacts include but are not limited to: +Authorization servers using Attestation-Based Client Authentication are RECOMMENDED to bind relevant protocol artifacts to the Client Instance and its associated public key where possible, and NOT just the client as specified in section 6 {{RFC6749}}. Examples of these artifacts include but are not limited to: - The authorization_code as specified in section 4.1 {{RFC6749}}. - The auth_req_id as specified in section 7.3 {{CIBA}}. From 28b451b4ae68fe38abd5a933a8e4a155e246ab8a Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Mon, 15 Sep 2025 19:28:49 +1200 Subject: [PATCH 4/5] Update draft-ietf-oauth-attestation-based-client-auth.md --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index c2bf84d..1a7e9f5 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -536,7 +536,7 @@ 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 client attestation mechanism as defined by this draft MUST bind the refresh token to the Client Instance and its associated public key, and NOT just the client as specified in section 6 {{RFC6749}}. To prove this binding, the Client Instance MUST use the client attestation mechanism when refreshing an access token. The client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used when the refresh token was issued. -## Binding of OAuth protocol artefacts +## Binding of OAuth protocol artifacts Authorization servers using Attestation-Based Client Authentication are RECOMMENDED to bind relevant protocol artifacts to the Client Instance and its associated public key where possible, and NOT just the client as specified in section 6 {{RFC6749}}. Examples of these artifacts include but are not limited to: From f083dbf012ca364f01dc1f9e051b36b79a3613b3 Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Mon, 15 Sep 2025 19:29:04 +1200 Subject: [PATCH 5/5] Update draft-ietf-oauth-attestation-based-client-auth.md Co-authored-by: Paul Bastian --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 1a7e9f5..32e7111 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -543,7 +543,7 @@ Authorization servers using Attestation-Based Client Authentication are RECOMMEN - The authorization_code as specified in section 4.1 {{RFC6749}}. - The auth_req_id as specified in section 7.3 {{CIBA}}. -How this binding is established and then proven is specific to the protocol artefact. For example establishing binding to an authorization_code involves the client instance using client attestation in the authorization request, and proving binding of the authorization_code to the Client Instance involves using the client attestation mechanism to authenticate at the token endpoint using an authorization code grant. +How this binding is established and then proven is specific to the protocol artifact. For example establishing binding to an authorization_code involves the client instance using client attestation in the authorization request, and proving binding of the authorization_code to the Client Instance involves using the client attestation mechanism to authenticate at the token endpoint using an authorization code grant. ## Web Server Default Maximum HTTP Header Sizes