Ambiguity in `fetch` endpoint response when `iss` and `sub` are the same

[jcmelati]

Hello!

I believe I have identified an inconsistency in the OpenID Federation specification related to the /fetch endpoint, specifically when the iss and sub parameters are the same. In this case, the endpoint currently returns an entity configuration, in accordance with section 8.1.1 which states regarding the sub attribute that "if this parameter is omitted, it is considered to be the same as the issuer and indicates a request for a self-signed Entity Configuration".

The specification also states that "an Entity MUST publish Subordinate Statements about its Immediate Subordinates via its fetch endpoint" (source).

However, this is problematic because:

• The fetch endpoint is intended to retrieve Subordinate Statements.
• Although Entity Configuration Statement and Subordinate Statement have similar data structures, they are not exactly the same.
• An entity cannot logically be a subordinate of itself.

Proposal: To resolve this, the specification should be updated so that when iss and sub are the same in a /fetch request, the endpoint returns invalid_request (Bad Request 400). This will clarify that the fetch endpoint should only be used to retrieve Subordinate Statements, not Entity Configurations.

Supporting evidence: In the Italian federation, we've observed that the payloads from the /.well-known/openid-federation and /fetch endpoints differ significantly, specifically on the metadata part that is present on the Entity Configuration Statement, but not on the Subordinate Statement.

Suggested Action: Amend the spec to explicitly state that the fetch endpoint should return invalid_request (400 Bad Request error) if iss and sub are identical.

[selfissued]

We discussed this on the 7-Aug-2 Federation editor's call. We agree on returning invalid_request when they are equal as you suggest.

[selfissued]

I agree that the spec is currently self-contradictory. The fetch endpoint describes that it can be used to retrieve either ECs or SS. It's described in terms of Entity Statements - not SSs. But there's the statement you cited that says it's about SSs:

"an Entity MUST publish Subordinate Statements about its Immediate Subordinates via its fetch endpoint" (source).

I believe we need to further discuss whether to remove the ability for Fetch to return Entity Configurations or not.

[selfissued]

We discussed this on the 12-Aug-24 Connect WG call. We agreed to simplify Fetch by making it only for returning Subordinate Statements and removing the ability to obtain Entity Configurations with it.