Clarifications on using sender-constraint tokens DPoP

[AxelNennker]

What type of PR is this?

Add one of the following kinds:

• enhancement/feature

What this PR does / why we need it:

This PR recommends to implement sender-constraint tokens by using DPoP

Which issue(s) this PR fixes:

Fixes #125

Special notes for reviewers:

DPoP has implications on API consumers.
The API consumer can indicate in its metadata if it always uses DPoP for token request.

Client Metadata Name:
dpop_bound_access_tokens
Client Metadata Description:
Boolean value specifying whether the client always uses DPoP for token requests

[jpengar]

Telefónica is not in favour of implementing DPoP in CAMARA.

Implementing Demonstrating Proof of Possession (DPoP) comes at a high cost with limited additional security benefits, given that other robust OIDC measures defined by the CAMARA profile are already in place. Here are the main reasons why we do NOT recommend implementing DPoP:

• High complexity, low benefit: DPoP adds significant implementation and maintenance costs, requiring cryptographic key management and specific header validation for each request, without providing a proportionate security gain over existing OIDC protocols.

• Asymmetric burden with limited client adoption: If DPoP is only recommended by CAMARA, API providers will bear the implementation costs without any guarantee that clients will adopt it, diluting its security impact.

• Performance and flow complexity: DPoP introduces additional cryptographic steps that slow response times and complicate authentication flows, placing unnecessary burden on both developers and end users. One of the biggest challenges that was continuously raised for the 3-legged authentication flows in CAMARA was the complexity, so we have to take it into account.

From Telefónica's perspective, the existing OIDC measures are sufficient. The cost and complexity of DPoP outweigh its benefits and it is not advisable to add it to our standards at this time. We have already accepted the recommendations (e.g. signed request) which we all agree have little impact on implementation given the use of private_key_jwt. But the DPop impact is much higher.

[eric-murray]

I share the concerns of @jpengar that this proposal effectively mandates all API providers support DPoP. The cost/benefit analysis does not support this, so it will not happen. Techniques such as mTLS are more likely.

For inter-operability, there is no reason to "recommend" (i.e. mandate) that API providers support DPoP, because the DPoP protocol itself allows the API provider to ignore the DPoP header and proceed with a Bearer token. So any API consumer requesting a DPoP token should expect this possibility. Whether they then proceed is up to them.

I anyway understood from #125 that the underlying issue was that some API providers require the API consumer to support DPoP. But for API providers that do not have this requirement, it is trivial to ignore the DPoP header (most likely, this would be automatic).

So the recommendation should be that API consumers support DPoP.

[AxelNennker]

The Financial API 2 Baseline Profile requires sender-constrained access tokens.
2.2.1. Requirements for Authorization Servers

Authorization servers ... shall only issue sender-constrained access tokens...

That is a baseline requirement for authorisation servers with customers from the banking industry who adaped FAPI.
Requirements like that have the tendency to be considered in audits after a breach of security and in compliance reviews (e.g. NIST Cybersecurity Framework (CSF)).

I assume that API Consumers with high security demands are going to demand support for sender-constraint access tokens.

If an API Consumer needs EIDAS LOA high, then they probably cannot use CAMARA APIs if our APIs are not implement security baseline requirements.

Rates for insurances are going to be higher if baseline security requirements are not met.

[AxelNennker]

Requirements could also be on the API Consumer.
There might be clients where we agree that they MUST send DPoP authentication requests.
Usually those agreements are done at onboarding time of the API consumer.

If we know at onboarding time that the API providers the API consumer is interested in - because they cover 90% of the API consumer's market - support sender-constraint tokens, then we can agree that they MUST use DPoP and that those API providers support DPoP.
Obviously if one ore more API providers do not support sender-constraint tokens then we cannot support those API consumers in their high security demand.

But business considerations are somewhat out-of-scope for ICM, right?!
I think ICM should enable the above while not forcing all API providers into having to implement DPoP if they don't see value in supporting higher security use cases, or if they think the security is good enough.

[jpengar]

In addition to the points raised in our previous comments, we respectfully disagree with the content of this PR regarding DPoP usage in CAMARA. The proposed recommendation does not assist with interoperability and does not fully address potential security concerns, as operators are free to implement and support DPoP according to their own criteria.

Furthermore, including this type of definition as a recommendation (in this case for the API consumer) effectively encourages API consumers to implement both flow variations, with and without DPoP. At the very least, some "IF" logic should be introduced to control API providers who do not implement DPoP, in the event that an API consumer always requests DPoP by default.

The introduction of DPop to the CAMARA flows would introduce additional complexity, both in terms of implementation costs (implementation is not trivial) and the onboarding process. It will also be necessary as well for API consumers to discover whether an API provider supports DPoP in order to utilise it, as the proposed text mandates to use DPoP when supported by the API Provider. There is a potential impact on performance due to cryptographic operations, not only in the Token request but also in the API calls for the DPoP proof validation (API response time is a key consideration).

In terms of interoperability, this recommendation does not address the fact that if an application demands DPoP and only accepts sender-constrained tokens, the functionality provided by that application will work or not depending on the API provider the app user belongs to. While there is (I think) a consensus that ICM should be as agnostic as possible to business considerations, it is important to remember that ICM is designed to address real-world CAMARA scenarios and requirements. It would be helpful to understand whether there is a mandatory requirement for CAMARA to provide support for DPop that justifies the associated cost and concerns raised above. If so, it would be useful to know where this requirement originates. If there is a genuine need for CAMARA to use DPoP at some point in the future, then the solution would be to mandate the support of DPoP. However, including now the definitions outlined in this PR is not a complete solution to the security concerns or interoperability issues.

[RamTMO]

@jpengar I clearly understand your concern. I try my best to build a simple table to discuss the interoperability. Hopefully it explains the various combination involved and the expected behavior. IF the Consumer expects the proof and the Provider does not support it then the Consumer has a choice to work with a Provider who is offering those features. The Provider MUST drop the proof as an unrecognized header. IF the Provider expects the proof and the Consumer does not provide it, then it is a error condition.

API Consumer	API Provider	Proof Presented?	Provider Behavior
Supports DPoP	Supports DPoP	Yes	MUST process the proof
Supports DPoP	Supports DPoP	No	MUST just use 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 simply use the bearer token and allow the API
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 simply use the bearer token and allow the API
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 simply use the bearer token and allow the API

[eric-murray]

@RamTMO
Thanks for this useful table, which explains well what I would expect to be the "de facto" behaviour for any API consumer or provider that supports DPoP.

One comment though - if the API consumer supports (or requires) DPoP and presents the DPoP header, but the API provider does not, the "default" behaviour should be for the API provider to return a bearer token (this is supported by the DPoP standard). Whether the API consumer uses this is up to them, but the API consumer cannot know if the API consumer requires a DPoP token, or would use the bearer token.

@jpengar
I think the proposed text makes two important statements about DPoP support:

• How does the API provider indicate that they support DPoP? (From the existence of the dpop_signing_alg_values_supported metadata); and
• How should an API provider that does not support DPoP respond to an API consumer using the DPoP header? (respond with a bearer token and NOT an error)

This is useful clarification, and does not mandate that any API provider needs to support DPoP.

I agree that full inter-operability requires either both sides to support (if it is mandatory for one or both), or for DPoP not to be allowed at all (meaning it cannot be a mandatory requirement). Pragmatically, I doubt we would get agreement on either of these options at this stage, but clarifying the preferred (and likely de facto) behaviour when one or both support it useful for now.

@AxelNennker
I disagree that, if an API provider supports DPoP, then the API consumer MUST use it. I think API providers should be allowed to return an error if they require it and a normal bearer token is requested. But equally API providers who support but do not require it should be allowed to accept requests for bearer tokens.

This will allow API providers to implement DPoP without requiring that ALL their API consumers support it first. We can look to tighten up rules in future if and when DPoP gets more traction.

[RamTMO]

@eric-murray Thanks for your comments ... I agree with you

One comment though - if the API consumer supports (or requires) DPoP and presents the DPoP header, but the API >>provider does not, the "default" behaviour should be for the API provider to return a bearer token (this is supported by >>the DPoP standard). Whether the API consumer uses this is up to them, but the API consumer cannot know if the API >>consumer requires a DPoP token, or would use the bearer token.

Overall,
IF the Provider does not support DPoP – No specific action is required on their part. They simply ignore the header, and the default behavior for the Provider is to respond with the bearer token as you have outlined (this is a standard behavior). It is NOT an error condition.

IF the Provider does support DPoP and REQUIRES DPoP, then it comes with some responsibility. The API provider MUST (or SHOULD) advertise their support or requirement for DPoP through several communication channels. Some are: Websites/Portal, SDKs, OAuth Discovery document, and /or onboarding flow.
Sample oAuth Discovery Document
{
"issuer": "https://example.com",
"authorization_endpoint": "https://example.com/oauth2/auth",
"token_endpoint": "https://example.com/oauth2/token",
"token_endpoint_auth_methods_supported": ["dpop", "client_secret_basic"],
"dpop_signing_alg_values_supported": ["RS256", "ES256"]
}

In this case, if the Consumer of the API did not provide the proof, then the Provider should return an error because the provider REQUIRES the proof. On the other hand, if the Provider just supports DPoP and does not mandate it, I agree, Provider can simply respond it with bearer token. It does not seem to be an error condition. That makes the interoperability situation little easier.

Sample CAMARA error message:

{
status: 400
code: BAD REQUEST
message: “DPoP proof is required but missing.”
}

[jpengar]

@eric-murray @RamTMO @AxelNennker

One comment though - if the API consumer supports (or requires) DPoP and presents the DPoP header, but the API provider does not, the "default" behaviour should be for the API provider to return a bearer token (this is supported by the DPoP standard). Whether the API consumer uses this is up to them, but the API consumer cannot know if the API consumer requires a DPoP token, or would use the bearer token.

+1 👍

I agree that full inter-operability requires either both sides to support (if it is mandatory for one or both), or for DPoP not to be allowed at all (meaning it cannot be a mandatory requirement). Pragmatically, I doubt we would get agreement on either of these options at this stage, but clarifying the preferred (and likely de facto) behaviour when one or both support it useful for now.

@eric-murray Yes, I'm afraid you're probably right. I really doubt it too 😅. So let's try to agree on a text that clarifies the expected behaviour 👍

@AxelNennker
I disagree that, if an API provider supports DPoP, then the API consumer MUST use it. I think API providers should be allowed to return an error if they require it and a normal bearer token is requested. But equally API providers who support but do not require it should be allowed to accept requests for bearer tokens.

This will allow API providers to implement DPoP without requiring that ALL their API consumers support it first. We can look to tighten up rules in future if and when DPoP gets more traction.

+1, I disagree with that as well. I suggest that this part be removed from the PR text proposal.

On the other hand, should we consider the table above to be part of the profile?

[AxelNennker]

I added Ram's table, put a sentence on top and reworded "simply"

[jpengar]

Sample CAMARA error message:

{
status: 400
code: BAD REQUEST
message: “DPoP proof is required but missing.”
}

Should we specify the error to be thrown if the API provider supports DPoP and REQUIRES DPoP and the API consumer does not provide the proof? Should this be part of #220?

[eric-murray]

Should we specify the error to be thrown if the API provider supports DPoP and REQUIRES DPoP and the API consumer does not provide the proof? Should this be part of #220?

RFC 9449 defines invalid_dpop_proof as the /token endpoint error to be returned when the DPoP proof is invalid, and I think a missing DPoP header would be considered "invalid" if it was required. The error description can explain that DPoP is required, but I don't think CAMARA need to specify the exact wording for that.

However, the standard RFC 6749 error invalid_request could also be used to indicate it is a missing (rather than invalid) DPoP header that is the problem.

If an API Provider requires DPoP access tokens, then they shouldn't be issuing Bearer tokens, so we shouldn't have the situation where an API Provider requires DPoP but is presented with a Bearer token for the API call itself.

[eric-murray]

The API Consumer either presents the DPoP proof to the API Provider, or they do not. Whether they "require" the API Provider to support DPoP or not does not affect API Provider behaviour. So the table can be greatly simplified.

Suggested change

	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 |
	The following table defines the REQUIRED behaviour of the API Provider for the `/token` endpoint, dependent on whether a DPoP proof is provided, and the API Provider's own level of DPoP support.
	| DPoP Proof Provided | API Provider DPoP Support | Token Type Issued |
	|:-----------------------:|:-------------------------------:|:-------------------:|
	| Yes | No DPoP Support | Bearer token |
	| Yes | Supports DPoP | DPoP token |
	| Yes | Requires DPoP | DPoP token |
	| No | No DPoP Support | Bearer token |
	| No | Supports DPoP | Bearer token |
	| No | Requires DPoP | HTTP 400 `invalid_dpop_proof`<br>(see RFC [9449](https://www.rfc-editor.org/rfc/rfc9449.html#name-oauth-extensions-error-regi)) |