[Openid-specs-fapi] Issue #475: certification: FAPI2-Baseline - is OpenID Connect support optional? (openid/fapi)

[josephheenan]

New issue 475: certification: FAPI2-Baseline - is OpenID Connect support optional?
https://bitbucket.org/openid/fapi/issues/475/certification-fapi2-baseline-is-openid

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\).