Bean examples at https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3947823106/OPCustomRedirectUriValidation

Included BiPredicate<URI,ProfileRequestContext> customRedirectUriValidationStrategy to OIDCSSOProfileConfiguration. Implemented in AbstractOIDCSSOConfiguration and thus inherits by OIDC.SSO, OAuth2.Token and OAuth2.PAR profiles.

I’ll see how convenient utility beans I can get produced to OP and keep that ValidationContext idea in mind.

I think that this case is more complicated: the deployers shouldn’t ever use always true predicate.

I’m thinking of something like BiPredicate<URI,ProfileRequestContext> where the URI is the already parsed redirection URI from the request.

I agree that PRC input is may be quite inconvenient, but I can try to “hide” it in the utility beans meant for this purpose. I feel that the metadata policy might fit those utility beans quite well: one could wire the JSON-policy to a bean that would be used for validating the URI against a list of static values or a regex for instance.

Notably we have the somewhat similar skipEndpointValidationWhenSigned option for SAML which just bypasses it. I don’t know if that’s warranted here or not (plus obviously a predicate hook is much more flexible anyway since an “always true” condition would be the equivalent to the skip option.

The major issue with a predicate like this is how to structure it for convenience. A PRC input like most of our conditions works but means a lot of digging into the tree to get information out if it’s needed for the condition.

I’ve not done it elsewhere but I wonder if creating some kind of “ValidationContext” under the PRC holding some of the basic inputs to the decision that would just get created and then removed around calling the condition might be a good idea.