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.