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.