[Openid-specs-ab] Issue #2103: Ambiguities in the definition of constraints in Entity Statements (openid/connect)

[Stefan Santesson]

New issue 2103: Ambiguities in the definition of constraints in Entity Statements
https://bitbucket.org/openid/connect/issues/2103/ambiguities-in-the-definition-of

Stefan Santesson:

The definition of constraints is ambiguous and should be clarified to avoid interop problems.

**Naming constraints**

This is said to mimic RFC 5280, but that seems highly unlikely. RFC 5280 is quite complex and does not fit the examples in the draft. For example an RFC 5280 constraint on an URI only include the host part of the UIR \(e.g. “.example.com” that may be extended with subdomains and  “[host.example.com](http://host.example.com)” which cannot.

I doubt that this was the intention of the specification. If it was, then I think it must be clarified in the text \(rather than a reference to RFC 5280\). I’m trying to figure out what was meant by looking at the examples, and I feel deeply unsure.

* Was it intended as a list of EntityIdentifiers \(Exact match\)?
* Was it intended as a base URL that can be extended by sub paths \(URL prefix\)?
* Or was it intended to contain a host name as defined in RFC 5280?

‌

**allowed\_leaf\_entity\_types**

Here I think the text needs clarification on how to treat presence of metadata for federation entities.

The only way to check this constraints is to compare it with present Entity Type identifiers in the metadata declaration of the leaf entity. But since any entity type may provide common metadata in the federation endpoint entity type metadata, this becomes a bit tricky.

How do you determine that an entity that declares federation endpoint metadata does not use this to act as an Intermediate Entity?

When trying to codify, this appears to be a non trivial check.

I would suggest \(as I have before\) that all normal federation services declare ALL their metadata under the Entity Type identifier that belongs to their role. That is an RP declare all its metadata under `openid_relying_party`. And OP declare all its metadata under `openid_provider`. Consequently the `federation_entity` entity type identifier is exclusively used to support federation infrastructure roles \(Trust Anchor, Intermediates, Resolvers, Trust Mark Issuers\) and is never used for regular federation service roles \(RP, OP, OAuthClient, AS, Resource servers\). This would solve several issues:

* This constraint would be a whole lot clearer and logical
* This would solve the ambiguity in the resolve request that includes a typ identifier which can’t handle metadata for several entity types. This does not work if the OP metadata is divided over several entity type metadata.

If not fixed this way, some clarifications and implementation guidance is needed.

‌