diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md
index 1b9c92c..4c0e248 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 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:
+
+- 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 before the user is redirected to the Authorization Endpoint (for example by using PAR, {{RFC9126}}), and proving binding of the authorization_code to the Client Instance involves using the client attestation mechanism to authenticate at the token endpoint when performing the 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.