[Federation] Explicit client registration: The metadata.openid_relying_party ES claim to represent the registered RP metadata is sufficient

[Vladimir Dzhuvinov]

Since the introduction of metadata assertions in Entity Statements (ES) in a recent OIDC Federation 1.0 draft there is longer a need to rely on the metadata_policy claim to convey the registered metadata parameters back to the RP. Instead a straightforward metadata.openid_relying_party representation is sufficient.

Note that the metadata policies at the OP and the RP will still apply to the content of the returned metadata.openid_relying_party

[Michael Jones]

We discussed this on the 3-Feb-23 Federation Editors' call. It seems to me that this issue is describing an implementation strategy and is not requesting a specification change. Is that your intent, Vladimir?

Or perhaps do we want to add implementation guidance in some place to this effect?

[Vladimir Dzhuvinov]

This definitely isn’t an implementation detail.

Why:

• In the early specs the OP returned the RP metadata in the policy language format because there was no facility to return it as standard metadata JSON object.
• At some point Roland made it possible to assert standard metadata in entity statements - great we can now simplify the explicit registration response!
• The explicit section was then updated to enable the response to contain policy and metadata?
• So why continue insisting on using the policy language format to return RP metadata in registration responses?

This also leads to an internal contradiction within the spec - the RP is not a subordinate to the OP, so why would an OP return a policy for it:

5.1. Metadata Policy

An Entity MAY publish metadata policies pertaining to Subordinate Entities of a specific type. Entity Type identifiers specified in this document can be found in Section 4.

‌

The only reason an OP may want to return an RP metadata policy instead of std metadata is if it wants to allow the OP to say for instance - you (RP) can use both client_secret_basic and tls_client_auth. I think allowing this to happen is inviting potential trouble.

‌

[Michael Jones]

What specification change do you believe we should make, Vladimir? Thanks.

[Vladimir Dzhuvinov]

On the 10th Feb meeting I spent some time with Roland to find out what his explicit reg implementation does under the hood. This is what I found out, expressed as normative text:

1. The OP MUST NOT return the complete metadata to the RP for a successful client registration. Instead, the OP MUST return the minimum possible set of metadata policies and assertions to enable the RP to recreate the client metadata it was registered with by the OP.
2. If a submitted RP metadata parameter complies with the OP's own policy and metadata the OP MUST NOT return the value, neither as metadata policy nor as metadata assertion.
3. If a submitted RP metadata parameter doesn't comply with the OP's own policy and metadata the OP MUST create a value modify policy to make the parameter compliant. The OP MUST return all these metadata policies to the RP.
4. For every RP metadata parameter that the OP provisions, for example client_id and client_secret, the OP MUST create a metadata assertion. The OP MUST return all these metadata assertions to the RP.

‌

[Vladimir Dzhuvinov]

Addressed by https://bitbucket.org/openid/connect/pull-requests/609/federation-reworks-explicit-registration

[Michael Jones]

Addressed by merging PR #609