Federation: Validation of metadata in entity statement

[malmgren01DF]

This question should be read in the light of conformance testing of federation entities:

Let's say that we've got an entity statement that contains the following metadata:

{
  "federation_entity": {
    "federation_fetch_endpoint": "https://example.com/fetch",
    "federation_list_endpoint": "https://example.com/list"
  },
  "oauth_authorization_server": {},
  "openid_relying_party": {}
}

federation_entity is valid and included for illustrative purposes. But what about oauth_authorization_server and openid_relying_party?

On one hand, the spec says that

When an Entity participates in a federation or federations with one or more Entity Types, its Entity Configuration MUST contain a metadata claim with JSON object values for each of the corresponding Entity Type Identifiers, even if the values are the empty JSON object {}

but on the other hand, if we take openid_relying_party as an example, it says

All parameters defined in Section 2 of OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] and Section 5.2 are applicable, as well as additional parameters registered in the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters].

But what does “applicable” mean? Does it mean that all of the properties and their optionality (or lack thereof) as defined in the DCR spec apply, meaning that we should run the same set of verifications that we do for RP DCR client registration metadata, or does it mean that the properties in the DCR spec may occur inside this metadata section, but are not subject to any validation rules?

If you could please enlighten me a little bit in this matter, that would be helpful.

Edit: I left out the little detail that client_registration_types is required in the openid_relying_party metadata section, but I guess that isn’t really relevant to the question anyway and that the description above explains it sufficiently as it is.

[MichaelFraser1999]

In addition to the above scenario, for OAuth Authorization Server the text says:

The Entity Type Identifier is oauth_authorization_server.

All parameters defined in Section 2 of [[RFC8414](https://openid.net/specs/openid-federation-1_0.html#RFC8414)] and [Section 5.2](https://openid.net/specs/openid-federation-1_0.html#common_metadata) are applicable, as well as additional parameters registered in the IANA "OAuth Authorization Server Metadata" registry [[IANA.OAuth.Parameters](https://openid.net/specs/openid-federation-1_0.html#IANA.OAuth.Parameters)].

Which includes the issuer value defined as REQUIRED. Issuer itself wouldn't make a whole lot of sense to be mandated within a policy issued inside an entity statement or indeed inside an entity configuration for an openid_relying_party entity for example. Yet per the spec, a blank json object for oauth_authorization_server must be included as the federation includes both types of entities. Does this mean the optionality is ignored?

[selfissued]

Good catch! “Applicable” means something like “MAY be used”. And yes, they should be validated as per the referenced metadata spec, if used.

That said, we may need to add language saying that properties that are required in the underlying metadata spec are also required in the resolved entity metadata.

This is why I love that we're starting the certification work before the spec is done. I'm sure that this won't be the last catch!

[selfissued]

As discussed on the 5-Aug-24 working group call, validation should be done against the resolved metadata - not just the contents of the Entity Statement. Superiors may supply metadata values for the resolved metadata.

[malmgren01DF]

@selfissued In this case I was specifically speaking of the entries in the metadata entry of the Entity Statement. When you say "resolved metadata", which metadata are you referring to then?

[peppelinux]

Entity Statement is a broad term encompassing both Subordinate Statements and Entity Configuration, serving as a foundational or parent class.

Resolved metadata results from applying the metadata and metadata policies derived from Subordinate Statements to the metadata specified in the Entity Configuration, if present.

Metadata in Subordinate Statements arbitrarily extends or modifies parameters, whereas metadata policies are governed by a specific syntax.

Once applied, the final metadata represents the outcome of a valid trust chain.

[selfissued]

@malmgren01DF, an example of resolved metadata is at https://openid.net/specs/openid-federation-1_0-ID4.html#name-verified-metadata-for-https. Compare that to the metadata in the Entity Configuration at https://openid.net/specs/openid-federation-1_0-ID4.html#name-entity-configuration-for-ht, from which it was derived by including contributions from Superiors.

[selfissued]

I will propose language to add clarifying the topic of this discussion - that the resolved metadata is to include all the applicable metadata parameters for each Entity Type.