OIDC dynamic registration policy ID

[Wessel, Keith]

Reviving this old thread for a follow-up question.

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.

It could alternatively have a metadataPolicy parameter pointing to a map of keys and values that, I think, define the metadata policy using a <map> element instead of an external JSON file.

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?

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. Any chance that would work? If not, what's the significance of the id one defines in the metadata policy lookup strategy?

Thanks,
Keith

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

On 4/26/22, 6:37 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    The policyId parameter of the OIDC dynamic registration endpoint in 4.2 says it's value: "Identifies a
> metadata policy by means of an identifier that maps back to a matching/named RelyingParty override."

It should really say "matching", not "named". It's referring to the "id" attribute in the override. People often don't set them, but all of them can have a unique id.

> That partly makes sense: I can configure a different policy file for the OIDC registration profile in that relying
> party override.

It's a policy by reference where you authorize somebody to "connect" their registration request to that bean but you get to control the policy it uses, change it without re-issuing tokens, etc.

-- Scott