OIDC dynamic registration policy ID

[Cantor, Scott]

On 7/20/22, 2:03 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    You explained that the policy ID passed into the dynamic registration token issuance endpoint
> needs to map to a relying party override with the ame value as its id attribute in relying-paty.xml.
> It looks like that relying party override could then have a custom metadataPolicyLookupStrategy
> pointing to a JSON policy file defining that policy.

I think/assume it can just be handed a policy document to use, but maybe it's only done with a lookup function, I don't recall. But yes, that's how it works.

>    If I'm not mistaken, the constructor args passed into a custom metadata policy lookup strategy
> bean are an id and a location. What's the significance of that ID? Any chance that could also be
> matched against the policy ID passed in with the token request?

I believe the map keys are the JSON claim names the policy applies to. The actual MetadataPolicy object itself is a constraint on the values of the claim matching the map key. The MetadataPolicy doesn't appear to represent the name of the claim it applies to.

In this policy:

{
"id_token_signed_response_alg": {
        "one_of": ["RS256", "RS384", "RS512"]
    }
}

I believe id_token_signed_response_alg is the map key and the JSON value is the MetadataPolicy.

I might not have modeled it like that, but there could be reasons of terminology in the spec that it works like that.

> Here's where I'm going. It feels like it'd be a whole lot cleaner if my default profile configuration's
> OIDC registration bean could define a custom metadata policy lookup strategy that, instead of
> defining a single id and location, contains a map of id values to location values. That would avoid
> a bunch of overrides.

You would have to test it, but I believe this all works anyway because all we do is treat the policyId thing as a relying party ID in the flow, just like we do with other protocols. That doesn't mean you have to have an override, it just means it's a "verified" identity, and it should either find a matching override or fallback to the default RelyingPartyConfiguration. It shouldn't just fail because it doesn't match.

That's what the code seems like it's doing, and what I would expect. In which case, you can inject a map into your lookup function based on that relying party ID yourself.

When I said "it matches a relying party ID", that's probably not exactly true. It acts as a relying party ID, that's a better way of saying it.

If it doesn’t, there might be a reason for it, but we'd have to look into that.

-- Scott