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.

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.

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.

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

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

@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.”
}

@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?

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

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?

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.