Some feedback from a first passthrough of the document.

Contradictions

1: Minor contradiction on self defined terminology

Description in 1.2

Federation Protocol Entity 

An Entity within the federation that fulfils a protocol role, such as an OpenID Provider, OpenID Connect Relying Party, OAuth 2.0 Authorization Server, OAuth 2.0 Client, or OAuth 2.0 Protected Resource. This is typically a Leaf Entity.

Contradicts the description of the same entity in 2.2.

This requirement implies that a Federation Protocol Entity is always a Leaf Entity and that its Entity Configuration MUST NOT include metadata of type federation_entity.

Clarifications

1: Missing reference or wrong sequence

Description in 2.2 is dependent on the readers understanding of 2.5, maybe add a reference and short description.

Most importantly, it may lead to conflicts between the contents of the metadata Claim and the metadata_policy Claim in subordinate Entity Statements.

2: Not enough information

Description in 4.1, what trust marks MAY the resolve include, is it only the trust marks defined by the given trust anchor or any trust mark?

A Federation Resolver MAY include Trust Marks that are not present in an Entity's Entity Configuration. It can do so by communicating directly with a Trust Mark Issuer. This functionality may be useful in cases when Trust Marks are being used a control mechanism within the federation and Entities within the federation are unaware of a particular Trust Mark type.

Additional notes

As is definition in 4.2.2 can lead to frustration when updating metadata. We should encourage metadata consumers to fetch metadata more often than exp in order to keep their understanding of the entity up to date. Otherwise if resolver exp is long, e.g. 7 days, it will take a whole week for metadata changes to propagate which will make key rotations painful. The federation operator should define what they recommend based on how long resolver responses are allowed to live for.

A cached response MAY be reused for subsequent requests for the same subject and trust context, that is, the same combination of subject Entity Identifier and Trust Anchor, provided the response has not yet expired. This reduces the frequency of calls to the Federation Resolver and improves overall federation performance.

The federation operator should recommend what a reasonable polling interval for metadata is which should be

exp > polling_rate > no cache

Some feedback from a first passthrough of the document.

Contradictions

1: Minor contradiction on self defined terminology

Description in 1.2

Federation Protocol Entity 

An Entity within the federation that fulfils a protocol role, such as an OpenID Provider, OpenID Connect Relying Party, OAuth 2.0 Authorization Server, OAuth 2.0 Client, or OAuth 2.0 Protected Resource. This is typically a Leaf Entity.

Contradicts the description of the same entity in 2.2.

This requirement implies that a Federation Protocol Entity is always a Leaf Entity and that its Entity Configuration MUST NOT include metadata of type federation_entity.

Is this really a contradiction? The definition says what a "Federation Protocol Entity" is, and in the requirements we state that such an entity MUST NOT take on the role of a Federation Service Entity. The definition can be used independently of the requirement.

In 4.1 Federation Resolver Requirements
...
"This functionality may be useful in cases when Trust Marks are being used a control mechanism"
...

Should be:
"This functionality may be useful in cases when Trust Marks are used as a control mechanism"
Or even the shorter:
"This functionality may be useful when Trust Marks are used as a control mechanism"

A very good first draft overall, here are my initial comments.

2.6 ”Instead, they SHOULD be chained to an Intermediate Entity (that is chained to the Trust Anchor). This requirement enables chaining a Federation Protocol Entity to other federation contexts, that is a chain ending at a different Trust Anchor, without the risk of metadata policy conflicts as described above.”

Clarification needed: Is the risk of metadata policy conflicts really completely gone with this approach, or is the risk minimized?

2.6.1 It is also RECOMMENDED that Federation Protocol Entities that need to be available under a common Trust Anchor chain to a common Intermediate Entity. This makes it easier for that Trust Anchor to create a chain to groups of Federation Protocol Entities by creating a single chain link to the common Intermediate Entity.

For discussion: Does this affect the recommended structure of IEs, i.e. which types of entities that should be registered under a particular IE?

2.6.2 ”deployments compliant with this profile SHOULD NOT allow Trust Anchors to also function as Trust Mark Issuers.”

I agree that the roles TA and TMI should be separate with two separate federation entitys.
But, I am not following why we have to restrict having a TMI under a TA.
Suppose an entity needs to check for existence of a certain trust mark for another entity, I should be able to trust that TMI directly by obtaining a trust chain for it, and make a separate call to that TMI.
Compare with [OpenID.Federation] 17.5: Validating a Specific Trust Mark, which states that:

”In order to validate a Trust Mark, the entity must find a Trust Chain for the Trust Mark Issuer to a Trust Anchor the Entity trusts. This has nothing to do with which federation that will later be used for the application protocol.”

And further

2.6.2 ”Attempting to resolve this by chaining directly to the Trust Mark Issuer is also problematic because such chaining implicitly creates an additional path through the other Trust Anchor, resulting in two possible trust paths, one of which may fail due to policy conflicts.”

This reasoning is not obvious to the reader I think. Could it be clarified? Is this referring to chaining from a TA directly to a TMI (to trust it)? Which trust paths are referred to here?
Is it really necessary to create these chains, a TA is allowed to reference acknowledged TM/TMIs from other federation contexts (TAs) in Trust_mark_issuers anyway.

3.1 ”If the Federation Registration Entity includes metadata values in Subordinate Statements, these values SHOULD be limited to fixing descriptive Entity metadata that was controlled during registration”

Do we mean ”adds” or ”overrides” or something else? Just "include" could mean just including metadata from the entity’s metadata configuration, but I don't think this is what we mean here.

3.1 ”An Intermediate Entity acting as a Federation Registration Entity and compliant with this profile MUST expose a subordinate listing endpoint as defined in Section 8.2 of [OpenID.Federation]”

Is this not already a MUST in [OpenID.Federation] 8.2 or is it not clear enough in the standard?

2.3 It is RECOMMENDED that the resolver is provided as part of the Trust Anchor itself

Should we maybe also include recommendations about creating redundancy for critical federation services, such as the Resolver?

4.1 ”A Trust Anchor or an Intermediate Entity that provides a federation_resolve_endpoint is regarded to be a Federation Resolver.”

Think it should be ”to also be a Federation Resolver”. It does not change type, it adds the capability.

4.2.2 ”A consumer MUST NOT use a resolve response beyond its validity period as indicated by the exp Claim of the response JWT”

What about local policies to handle longer downtimes in federations services or networks? Make it a SHOULD to support that? 
Or maybe add ”...unless there is a local policy that states otherwise for emergency or other critical situations.”

Compare this to revocation check policies in PKI with CRLs, where it can be of high importance for the local organization to maintain functionality at all times If possible.

5.1 ”A Federation Operator SHOULD define a Trust Mark Policy for the federation. The Trust Mark Policy MUST define:”

Think it could be more consistent to use ”SHOULD” for both criteria, since it is only optional to define a policy in the first place.

5.1 ”The URL identifiers for Trust Mark types recognized within the federation.”

”The definition of these identifiers cannot be delegated to Trust Mark Issuers, since it is the responsibility of the Federation Operator to ensure that they are collision-resistant across multiple federations,”

I recommend to also have this general rule: ”The Trust Mark Policy SHOULD define rules how to ensure that identifiers for Trust Mark types are collision-resistant across multiple federations. It is RECOMMENDED to follow section 7.1 in [OpenID.Federation] for such rules.”

There is a recommendation in the standard for this:

[OpenID.Federation] 7.1 ”It is RECOMMENDED that the identifier value is built using a URL that uniquely identifies the federation or the trust framework within which it was issued.”

We could also choose to make this recommendation SHOULD.
Think this is good in the long run because synchronization between federation operators could be challenging otherwise.

5.2 ”A Federation Service Entity that exposes a Trust Mark endpoint as defined in Section 8.3.3 of [OpenID.Federation], is a Trust Mark Issuer”

Think this should be Section 8.6 and/or 7.

2.4.1 ”If Trust Marks with short validity periods are used, these may effectively limit the usable validity of an Entity Configuration”
5.2 ”Leaf Entities have to obtain new Trust Mark instances frequently and update and re-sign their Entity Configurations accordingly”

It seems to me like a bad design (in the standard?) to have this dependency in the first place. The problem also spills over to the Federation Resolvers as described in the profile.

The typical scenario where a RS, AS or OP needs to check for a valid TM of a certain type could be handled by a cached call to the TMI itself. In that way, verifying entity’s configuration and checking for TMs become loosely coupled, which is a good principle. It also decreases the burden on the Clients, also good. Also, if Entitys check directly with the TMI, the requirement ”A Trust Mark Issuer MUST expose a Trust Mark Status endpoint” would not be strictly necessary, also good.

I propose that we have a recommendation regarding this (without breaking something in the standard of course)

6. ”all compliant Entities MUST support for signature validation”: RS256, RS384, RS512, ES256, ES512”

What the underlying rationale to require all of these algorithms for OAuth2 Clients and RPs that may not have the need to validate trust chains or resolver responses? Federation services and Server entities - yes.

For discussion: What about future proofing for PQC algorithms? Can this profile pave a way to make that inevitable transition easier?

7.3 ”use distinct scope values”

Maybe use ”unique scope values within the federation, preferably URIs”

6. ”If a Federation Service Entity requires client authentication…”

I think we should consider require Client authentication at some critical federation endpoints, such as the resolve endpoints, to mitigate DoS attacks.
See [OpenID.Federation] Security Considerations18.1 :

”Client authentication is not required at the resolve endpoint, then incoming requests should not automatically trigger the collection (Federation Entity Discovery process) and assessment of Trust Chains.”

Further, maybe all responses from federation services including error messages SHOULD be signed? See [OpenID.Federation] Security Considerations 18.2