search

camaraproject / IdentityAndConsentManagement

Repository to describe, develop, document and test the Identity And Consent Management for CAMARA APIs
Apache License 2.0
18 stars 30 forks source link

DPoP support in CAMARA OIDC Profile #125

Open gmuratk opened 4 months ago

gmuratk commented 4 months ago

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 commented 4 months ago

cc: @mengan

AxelNennker commented 4 months ago

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 commented 4 months ago

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.