Clarifications on using sender-constraint tokens DPoP

documentation/CAMARA-Security-Interoperability.md

@@ -7,6 +7,7 @@
    * [Conventions](#conventions)
    * [General Considerations](#general-considerations)
       + [Transport Security](#transport-security)
+      + [Sender-Constrained Tokens](sender-constrained-tokens)
    * [OIDC Authorization Code Flow](#oidc-authorization-code-flow)
       + [Cross-Site Request Forgery Protection](#cross-site-request-forgery-protection)
    * [Client-Initiated Backchannel Authentication Flow](#client-initiated-backchannel-authentication-flow)
@@ -62,6 +63,35 @@ Unless otherwise noted, all the protocol parameter names and values are case sen
 ### Transport Security
 All network connections MUST use TLS 1.2 or better.
 
+### Sender-Constrained Tokens
+
+[OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.2.1) and the [FAPI 2.0 Baseline Profile](https://openid.net/specs/fapi-2_0-baseline-01.html) both RECOMMEND that authorization and resource servers use mechanisms for sender-constraining access tokens. 
+
+This document states that Demonstrating Proof of Possession (DPoP) [RFC9449](https://datatracker.ietf.org/doc/html/rfc9449) MAY be used by API Consumers, to prevent misuse of stolen and leaked access tokens. 
+
+CAMARA authorization servers MUST NOT respond with an error if they do not support DPoP. DPoP allows authorization servers to issue tokens that are not sender-constrained even if a valid DPoP header is present in the authorization request. It is up to the API consumer to decide whether none-sender-constrained tokens meet their security requirements.
+
+If the API Provider supports DPoP, support for it MAY be expressed by the server metadata field `dpop_signing_alg_values_supported` or alternate API documentation.
+
+API consumers with high security demands that e.g. want to achieve EIDAS LOA high can be set to be required to always send DPoP requests. This requirement is expressed by the API consumer's metadata in the field `dpop_bound_access_tokens`. This requirement on the API consumer is determined at onboarding time.
+
+The following table illustrated the expected behaviour of the API Provider at the API endpoint.
+
+| API Consumer   | API Provider    |Proof Presented?     | Provider Behavior          |
+| -------------- | --------------  |----------| -------------------------------------------------------------------------------------|                                                                               
+| Supports DPoP  | Supports DPoP   | Yes      | MUST process the proof                                                      |
+| Supports DPoP  | Supports DPoP   | No       | MUST validate the bearer token                                              |
+| Supports DPoP  | Requires DPoP   | Yes      | MUST process the proof                                                      |                                                                                       
+| Supports DPoP  | Requires DPoP   | No       | MUST return an appropriate HTTP error with details in the custom message text        |
+| Supports DPoP  | No DPoP Support | Yes      | MUST drop the HTTP parameter                                                         |
+| Supports DPoP  | No DPoP Support | No       | MUST validate the bearer token                          |
+| Requires DPoP  | Supports DPoP   | Yes      | MUST process the Proof                                                      |
+| Requires DPoP  | Requires DPoP   | Yes      | MUST process the Proof                                                      |
+| Requires DPoP  | No DPoP Support | Yes      | MUST drop the unrecognized HTTP header                                      |
+| No DPoP Support| Supports DPoP   | No       | MUST validate the bearer token                          |
+| No DPoP Support| Requires DPoP   | No       | MUST return an appropriate HTTP error with details in the custom message text        |
+| No DPoP Support| No DPoP Support | No       | MUST validate the bearer token                        |
+
 ## OIDC Authorization Code Flow
 
 The OIDC Authorization Code Flow is defined in [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html)