First cut at docs are done, and we just need testing at this point, which will mostly have to come from early adopters.

Think this is done apart from adding a bit of attribute filtering enhancement to the IdP and documenting it.

Committed changes required to allow unverified clients for this grant type with some tests. There would be more work required to generalize this to the code grant, principally enforcing the response_type values similar to the changes required for grant_type.

TBD is revisiting the introspection/revocation flows. I think we can allow for unverified usage there since authenticating the client should be sufficient to provide a control point and I doubt there’s much use of metadata on those flows as it is.

Committed a first redesign that implements the concept of a second relying party representing the resource server/audience living under the outbound message context and adjusted flow wiring and some beans to handle the change. Control point for allowing unregistered audiences is working, but unregistered clients are TBD because the original OIDC actions don’t allow for it yet.

For the moment attribute filtering requester ID is wired up as the resource server but still debating that.

Some of the design was adjusted to think ahead to what will happen when a 4 legged flow is involved, so I abandoned the idea of replacing the original client RelyingPartyContext in favor of adding one for the resource server so both are available. Probably need to think through that more fully in deciding how the attribute resolution/filtering contexts are handled so it works for the code grant use case later.

A complication is that using the attribute resolver to derive the final Scope/Audience claims creates a problem if you want to rely on knowing the Audience early enough to sensibly drive resolution/filtering. I’m rethinking that decision in light of these ideas.