OIDC dynamic registration policy ID

[Wessel, Keith]

Thanks, Scott. I'm starting with just a default policy, but I'll report back with suggestions or comments as I add some additional ones.

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

It'd definitely be nice if one of the parameters to the profile was a path to a policy document, yes. But the only options I see are overriding the lookup strategy to point it to a file or defining the metadata policy map as you described.

I'm still a little unclear: if I override the metadata policy lookup strategy, it has two constructor args: a location and an id. What's the significance of the id? Since this bean defines the default metadata policy file location, it obviously wouldn't have anything to do with the policy ID passed into the token request, or it wouldn't be a default. It looks like it perhaps defines a name for the cache that tht eIdP uses to store the policy's contents? The built-in default bean has:

        c:id="DefaultProfileMetadataPolicyCache"

Is that just referring to the cache where the policy is stored?

Keith

-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Wednesday, July 20, 2022 2:01 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: OIDC dynamic registration policy ID

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