DPoP support in CAMARA OIDC Profile

[gmuratk]

Problem description

Based on the December 20, 2023 presentation by OIDF, FAPI 2.0 is identified to be a good starting point for CAMARA OIDC profile. FAPI 2.0 lists a general requirement that states "Authorization servers shall use only issue sender-constrained access token" and further defines two methods as options to choose from including DPoP [RFC9449].

Currently there DPoP is not listed in the feature list for the CAMARA OIDC profile(s) proposed by #113 or #121.

Possible evolution

Add statements to the CAMARA OIDC profile that states "some carrier(s) MAY require some extensions like DPOP."
Normative examples should be included both a DPoP on the token request and a cnf binding to a key in the access_token issued.

Alternative solution

Additional context

As this is an important feature, it should be addressed in the next version of the OIDC profile and I&CM release, prior to a CAMARA wide release.

[gmuratk]

cc: @mengan

[AxelNennker]

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.

[dpostnikov]

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.

[AxelNennker]

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.

[murthygorty]

[like] Gorty, Murthy reacted to your message:

…

________________________________ From: Axel Nennker ***@***.***> Sent: Thursday, November 28, 2024 8:01:05 AM To: camaraproject/IdentityAndConsentManagement ***@***.***> Cc: Gorty, Murthy ***@***.***>; Manual ***@***.***> Subject: Re: [camaraproject/IdentityAndConsentManagement] DPoP support in CAMARA OIDC Profile (Issue #125) [External] 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<https://tech.aufomm.com/how-to-use-demonstrating-proof-of-possession-dpop-token-with-kong-and-keycloak/>, 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. — Reply to this email directly, view it on GitHub<#125 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEVULZ7L7ZNKKAQJLFIXX3D2C3EUDAVCNFSM6AAAAABDPQC3D6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBVGQ3TKOBQGM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[RamTMO]

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