Should certain claims be banned from listing in metadata?

[MichaelFraser1999]

This is intended as more of a discussion starter than necessarily an actionable issue; however, I was reading through what metadata options are valid and got to section 5.1.2

Per this text, an openid_relying_party's entity metadata could list a value for client_secret. Now, a server absolutely shouldn't honour this if specified, as it is only defined as a response value in RFC 7591, but it opens the door to mistakes from incorrect implementations. Since there is no need for this metadata ever to be listed, should we explicitly ban it? There may well be other cases of this

[selfissued]

https://openid.net/specs/openid-connect-core-1_0.html#IDToken sets precedent for doing this:

ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk Header Parameter fields.

People are requested to identify specific claims that they believe should be banned in particular contexts by adding comments to this issue.

[MichaelFraser1999]

For openid_relying_party I'd propose:

• client_secret
• client_secret_expires_at
• registration_access_token

[selfissued]

@MichaelFraser1999 can you please create a PR?

[Razumain]

This again is an unlucky mix of purposes of the core specification.

As I see this. There are two very different ambitions with the core specification:

1. It is an independent specification that allows parties to exchange validated metadata and Trust Marks without interfering with how that metadata and those Trust Marks are being used in underlying protocols
2. It is a package where if you implement OpenID federation, you also have to accept the OpenID federation way of expressing metadata and to handle requests and client registration.

It feels like this specification was written with the ambition to do 2.
But I think we are slowly realizing that we really need 1.

Even if text was changed in client registration to make it optional, requirements are still there such as in 5.2. requiring certain metadata content related to client registration.

I fear that as long as we don't do 1) we will face pushbacks and make it harder to come up with gradual deployment paths where we transition services into OpenID federation in a gradual process.

[rohe]

Well, it definitely started with 1) in mind.

[selfissued]

Fixed by #285