RECOMMEND 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.