certification: FAPI2-Baseline - is OpenID Connect support optional?

[Joseph Heenan]

Currently the FAPI1 OP certification tests always require OIDC support (i.e. scope=openid is used and an id_token is returned from at least the token endpoint). [I think this likely isn’t technically correct, but it’s not something that’s seemed pressing to resolve as no one seems to really be deploying with only JARM so far.]

For FAPI2 Baseline I think the situation is much clearer that OpenID Connect support is optional.

The certification team would appreciate any feedback on the following questions:

1. Are we correct to assume that FAPI2 baseline certification should be possible for authorization servers that don’t support OpenID Connect?
2. Assuming yes, should the tests offer the option to test with OpenID Connect, at least to the extent it was tested in FAPI1 certification tests?
3. Assuming yes, should separate columns be used on the certification page to indicate if OpenID Connect was tested or not?

If this is correct, the suggest certification columns might be:

private_key_jwt
mtls client auth
mtls bound access tokens
dpop access tokens
openid connect support
unsigned/signed requests objects (early indications are that some ecosystems will require signed requests)

I think because of the number of options here we’d not propose to have separate columns for each combination of option.

There is an argument to be made that ‘3' is not necessary and authorization servers that intend to support OpenID Connect should certify for OpenID Connect. Unfortunately the OpenID Connect certification tests cannot be run against a FAPI2 compliant server for multiple reasons, an example being that OpenID Connect certification explicitly requires the AS to support client_secret_basic and non-PAR (this is mostly not a limitation of the source code for the tests, it’s a deliberate decision by the Connect working group).

[Daniel Fett]

My take:

1. That is correct, OIDC is meant to be optional.
2. yes
3. yes

‌

[Brian Campbell]

My take:

1. yes
2. why? is there sufficient demand for, or value in, offering some kind of FAPI 2.0 compliant OIDC? Would it be on top of advanced or baseline? And using private_key_jwt or mtls? And various combinations of other options. I dunno. Seems like if you start to pull on this thread…
3. somehow separate

‌

[Joseph Heenan]

It might help if I clarify what I meant by “to test with OpenID Connect, at least to the extent it was tested in FAPI1 certification tests?”.

The FAPI1 tests essentially test that specifying scope=openid results in an id_token being returned from the token endpoint, and that the id token is correctly signed and generally meets the rules in https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

Things they don’t test include the user info endpoint, nor various openid parameters, e.g. none of these request parameters are tested in FAPI1-Adv certification:

1. prompt=none or prompt=login
2. max_age
3. display
4. ui_locales
5. id_token_hint
6. login_hint
7. claims
8. scope=address etc

[Dave Tonge]

FAPI2 tests support testing with OIDC and without it.