Document should be explicit in what is meant by equality

[MichaelFraser1999]

The document doesn't currently explicitly define what is expected from equality checks. This can be on Entity Identifier comparison between sub or iss claims, on entries in the authority_hints array, etc

The scenario I see playing out is as follows:

Two entities are registered in a federation with a functionally identical entity identifier (but one with a trailing slash and one without).
Example: https://foo.bar.com/ and https://foo.bar.com. This would be possible per the equality rules as defined in RFC8414

Any well-known resolution would of course still go to the same location as well-known URI construction mandates the trailing slash is removed if present

However, /fetch responses could return different metadata in this scenario, depending on whether a requester includes the slash. Some implementations may fail to differentiate between the different entities if they're stripping trailing slashes.

Ultimately, only one subordinate statement should be usable in a trust chain as the one that doesn't exactly match the iss claim in the resulting well-known document should be rejected.

To ensure the above cannot become an issue, the document should be explicit in what is meant by equal, whether trailing slashes are ignored or not, etc.

[selfissued]

I agree that we should talk about the fact that https://example.com/ and https://example.com are the same issuer.

[jcmelati]

The problem isn’t just the trailing slash, as https://foo.bar.com/ and https://FOO.bar.com for example are also the same issuer.

Should we refer to RFC 3986 - 6. Normalization and Comparison to help define how and when an implementer should normalize identifiers and how they should look like in statements? This would let us define equality based on a standardized identifier-sanitization process.

Do you think we could require normalization to happen before statements are issued, so as to remove as much burden as possible from verifiers?

[peppelinux]

I agree that we should talk about the fact that https://example.com/ and https://example.com are the same issuer.

in terms of discovery, the result doesn't change.

https://example.com/ or https://example.com the discovery will point to the same Entity Configuration and the iss/sub value found will be considered as absolute

RFC 3986 - 6. Normalization and Comparison makes a lot of sense using other endpoints like fetch, trust mark, resolve and any other

+1 @jcmelati

[jogu]

I don't think there should be any normalisation.

Normalisation adds implementation complexity and opens up the door to security issues.

I don't think there is any case where normalisation is needed? In all cases using the correct issuer value will work so people should just use the correct value and incorrect values won't work (e.g. "iss" in id_tokens is explicitly defined to be an "exact match" comparison, https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation )

Using the wrong issuer value will probably fail straight off when fetching discovery information as the issuer in the server metadata is also defined to be an exact match: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata

The document doesn't currently explicitly define what is expected from equality checks. This can be on Entity Identifier comparison between sub or iss claims, on entries in the authority_hints array, etc

I think we should just explicitly document that these are exact matches.