cc: @mengan

some carrier(s) MAY require some extensions like DPOP.

Some API providers requiring DPoP might lead to problems for Clients if one API provider requires it but another does not support DPoP.

In DT's original proposal I wrote that AZ MUST support DPoP and that Clients MAY use it.

If in one market e.g. US all API providers support sender-constraint assertions and they are implemented using DPoP, then I think we could require that the AZ MUST implement DPoP. It is also a business decision whether or not requiring DPoP support by Clients.

Currently not enough AZ implementations in the Camara ecosystem implement DPoP and not enough API providers as well.

I would be happy to require DPoP support by AZ. That is the first step that needs to be done, if we want better security by sender-constraint assertions implemented by DPoP.

It depends on the range of use cases / clients that you need to support.

If sender constrained tokes are mandatory (just like in FAPI 2), then you have 2 implementation options MTLS or DPoP. You can either mandate both options to the Authorization Servers or one of them. If you allow both MTLS and DPoP than clients would choose which one to use.

It depends on the range of use cases / clients that you need to support.

If sender constrained tokes are mandatory (just like in FAPI 2), then you have 2 implementation options MTLS or DPoP. You can either mandate both options to the Authorization Servers or one of them. If you allow both MTLS and DPoP than clients would choose which one to use.

Choice is good for the API consumer. Although I am not 100% sure about that. API consumers are probably looking for guidance from the API provider and research what other (big) clients are using. If we recommend DPoP and more parties support DPoP then open source solutions emerge or mistakes in existing open source implementations are ironed out.

Similar reasoning applies to API providers. One way of implementing sender-constrained tokens allows others to learn from the forerunners. Even if the API provider chose a off-the-shelf solution that supports DPoP, like Keycloak and Kong, there is usually a learning curve, which costs money - but if the security requirements demand sender-constrained tokens then choosing one protocols is probably cheaper for everyone.

So, yes this depends on the use cases / clients what the servers support, but, I think, one way of implementing sender-constrained tokens is probably easier and cheaper for everybody.

We can’t expect a wide adoption of DPoP soon, but some Operators and API consumers MAY require DPoP proof as a critical business requirement. It is important for the standards organizations to support these requirements and allow coexistence. The below table is a simplified version of all possible combination of provider-consumer behavior and expectations. Hopefully address some concerns.

| API Consumer. | API Provider. |Proof | Behavior
| | |Presented? |
| Supports DPoP | Supports DPoP | Yes | API Provider MUST process the proof
| Supports DPoP | Supports DPoP | No | Provider will just use the bearer token
| Supports DPoP | Requires DPoP | Yes | MUST process it
| Supports DPoP | Requires DPoP. | No | MUST return an appropriate HTTP error (ex: 400 Bad Request) with details in the custom message text
| Supports DPoP | No DPoP Support | Yes | MUST drop the HTTP parameter
| Supports DPoP | No DPoP Support | No | Provider will simply use the bearer token and allow the API
| Requires DPoP | Supports DPoP | Yes | MUST process it
| Requires DPoP | Requires DPoP | Yes | MUST process it
| Requires DPoP | No DPoP Support | Yes | MUST drop the unrecognized HTTP header
| No DPoP Support| Supports DPoP | No | Provider will simply use the bearer token and allow the API
| No DPoP Support| Requires DPoP | No | MUST return an appropriate HTTP error (ex: 400 Bad Request) with details in the custom message text
| No DPoP Support| No DPoP Support | No | Provider will simply use the bearer token and allow the API