Successfully run the Basic Certification Profile (ie. code-flow) on the OIDC certification suite. Also some selected tests for the hybrid profile were successful. In all test, the test suite RP was configured statically via following SAML metadata:

Handing off to Henri for more testing and review.

Possibly temporary workaround implemented to “hide” internal claims when JWTs are used. Nominally feature complete at this point.

The dev branch now also contains enhancements to the authorize flow so this is all nominally done for all grants, except for the TBD around sealing the special claims.

I’ve done real RP testing with the token endpoint changes and unit testing of the authorize endpoint.

Implementation is done consistent with the client_credentials grant’s handling of the resource parameter and controlling behavior via the OAUTH2.TokenAudience profile bean.

Encryption of the access token is disallowed at present if the openid scope is present, which is always true on the authorize endpoint but not a given on the token endpoint.

Once the authorize endpoint is fixed to handle non-OpenID requests, we should more or less have the 4 legged OAuth case handled.

Some POC work on dev branch. Something possibly close checked in that isn’t breaking tests too much, tried to rework the token flow around whether the access token is being issued for use with the OP only or if there’s an external resource server (which handles the original client_credentials case).

ID token steps moved to a separate conditional step that runs only with openid scope in play but this needs more study, as I assume the original code must have been tighter around e.g. not issuing it during a refresh grant but I didn’t notice that logic in place either. Probably just needs to be extended to check for both the scope and the code grant type.

Big TBD is handling the special operational claims that get embedded in the access token, which need to be separately sealed to protect them when a JWT is used, to hide them from the client and resource.