Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Federation: Validation of metadata in entity statement #28

Closed
malmgren01DF opened this issue Aug 2, 2024 · 7 comments · Fixed by #96
Closed

Federation: Validation of metadata in entity statement #28

malmgren01DF opened this issue Aug 2, 2024 · 7 comments · Fixed by #96
Assignees
@selfissued
Labels
question Further information is requested

Comments

@malmgren01DF
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Member

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
Copy link
Member

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
Copy link
Collaborator Author

@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
Copy link
Member

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.

@peppelinux peppelinux added the question Further information is requested label Aug 7, 2024
@selfissued
Copy link
Member

@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
Copy link
Member

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.

@selfissued selfissued self-assigned this Aug 24, 2024
@selfissued selfissued mentioned this issue Sep 22, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@selfissued selfissued

Labels
question Further information is requested
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Describe validation of resolved metadata selfissued/federation
4 participants
@peppelinux @selfissued @MichaelFraser1999 @malmgren01DF