[API Design Guideline] Does an API not implementing OIDC Discovery make it non-CAMARA compliant

[rkandoi]

The current CAMARA guidelines make the use of three-legged auth flow mandatory. This is okay for B2C and B2B2C cases.

However, in the current versions of the API, Dedicated Networks will ONLY support the B2B case using Client Credentials and there is no real need to implement or design the three-legged flow in to the implementation or even in the info.description.

There does not seem to be a precedent for how to handle such a case in CAMARA. Creating this placeholder to discuss the topic.

Note that the r1.1 adopts CAMARA guidelines, but adopting the guideline is potentially misleading at this point.

[hdamker]

The current CAMARA guidelines make the use of three-legged auth flow mandatory.

No, that's not the intended interpretation of the mandatory text you have copied correctly in:

The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation.

In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design.

So only "In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out" the use of three-legged access tokens is mandatory.

BTW: in code/API_definitions/dedicated-network-accesses.yaml you have defined so that developers can use 3-legged tokens, which could be even beyond privacy a benefit, as they don't need to deal with device identifiers.

If you still have doubts, I recommend to open the issue/discussion in ICM ... it wouldn't be the first time there ;-)

[rkandoi]

Thanks for the clarification @hdamker. Based on your input I have updated the title to correctly reflect the new question.

[eric-murray]

Hi @rkandoi

OIDC discovery is indeed mandatory, but that does not mean one of the OIDC flows must be used. OIDC discovery can be used to "discover" that only client credentials are supported.

So the dedicated networks inclusion of a separate oAuth2 security scheme is entirely redundant, as the API consumer can learn all the information in that scheme from the discovery endpoint. The parameters that would indicate this are grant_types_supported (which would be client_credentials only), and token_endpoint (which would the URL you are trying to share in tokenUrl).

Another misconception is that API providers must provide a common OIDC discovery endpoint for all APIs. This would not work, the endpoint must be specific to each API, which is why each API can specify it's own discovery endpoint in openIdConnectUrl. There is no rule saying all APIs must have the same discovery URL.