- changed component to Federation
Not listing federation_entity metadata in metadata.
None of the claims in federation_entity metadata is required. This means that an entity may have a federation_entity metadata specification that is an empty object. Like this:
“metadata”: {
“federation_entity”: {},
“openid_provider”: { … }
}
In OIDC Core it is stated that claims with no value should not be include in messages. If {} is regarded as no value the above should be possible to rewrite as:
“metadata”: {
“openid_provider: { … }
}
Following this process all the way might cause a problem if the entity is only of the entity type federation_entity since then one should be able to removed the metadata claim completely which goes contrary to what’s specified in section 3.1: “If the Entity Statement is an Entity Configuration, then the Entity Statement MUST contain a metadata
claim.”.
Comments (9)
-
-
We discussed this on the 16-Dec-22 Federation Editors' call. In practice, we believe that every current federation_entity declaration will include parameters. That said, there may be future entity types where this is not true. So we may or may not need to say anything about this in the spec. Let’s discuss further.
-
IMO the OIDC Federation 1.0 should not specify what qualifies as legal metadata content, meaning empty JSON object
{}
should not be prohibited. It just happens that OIDC has required metadata parameters, but other protocols that build upon OIDC Federation may not. Or they may simply want to identify the entity type, without further details. -
reporter i agree with Vladimir.
-
Another scenario that comes to mind and speaks for not prohibiting empty metadata:
- RP superior asserts params like redirect_uris and jwks
- Grant types, algorithms and other general RP params formed by means of metadata_policy
- This leaves RP leaf with empty {} metadata
-
IMO we can close this ticket without further action.
Section 4 currently says:
https://openid.net/specs/openid-connect-federation-1_0.html#name-metadata
The metadata document MUST be a JSON object. Beyond that, there is no restriction.
Meaning, should someone what to have empty JSON objects, this doesn’t violate the current spec language.
-
Fair enough @vlad, I agree with you
-
reporter Me too
-
- changed status to resolved
- Log in to comment