[Federation] Federation Entity Discovery definition

[Vladimir Dzhuvinov]

There are cases when one may want to do the discovery for Entities other than Leaf Entities.

Federation Entity Discovery

A process that starts with an Entity Identifier and collects a number of Entity Statements until the chosen Trust Anchor is reached. From the collected Entity Statements, a Trust Chain is constructed and verified. The result of the Federation Entity Discovery is that the Leaf Entity's metadata is constructed from the Trust Chain.

The “Leaf” in the last sentence should be removed.

[Giuseppe De Marco]

See https://bitbucket.org/openid/connect/pull-requests/671

[Michael Jones]

Removing Leaf is something that we will do when we address https://bitbucket.org/openid/connect/issues/2082/federation-remove-requirement-for-trust .

[Nat Sakimura]

It was asked on the Feb 27 call what is the motivating use cases.

It was pointed out that the definition of the leaf is wrong and changed to something like “no subordinates for the current transaction”.

[Vladimir Dzhuvinov]

In the current draft we actually have several of locations that use the term “Leaf Entity” in the context of a Trust Chain. A suitable and “more” correct way to say this is “the Entity that is the subject of the Trust Chain”, or simply “the Trust Chain subject”.

For example:

A max_path_length constraint of zero indicates that no Intermediates MAY appear between this Entity and the Leaf Entity

→

A max_path_length constraint of zero indicates that no Intermediates MAY appear between this Entity and the Entity that is the subject of the Trust Chain

‌

[Michael Jones]

We could choose to go this route, but if we do, we should still include language in the general descriptions saying that a Leaf Entity is typically the subject of the Trust Chain, in order to set people’s expectations appropriately.

Separately, what are the use cases for building a trust chain to an Intermediate Entity? Unless we have evidence that it’s useful and needed, the spec would be simpler if we don’t talk about the possibility. Without such evidence, I remain to be convinced of the need for a change.

[Vladimir Dzhuvinov]

There are two cases that argue for this:

1. The most common is likely to be orgs that are Intermediates choosing to run their OpenID provider (or servers in general) on their “main” domain. I believe this will become a common pattern, because of the obvious convenience to combine an OP + INT in the same server.
2. If you need to use the federation endpoint (say resolve endpoint) at some Intermediate Entity, and before you use it you want to check its trust_chain.

This change is going to be rather low impact. I checked the individual instances where this term comes up and we’ll need the edits in only 9 of these places.

[Michael Jones]

So 1 is about an Intermediate that also plays a non-Federation Entity role, such as being an OpenID OP or RP. I agree that that could occur.

And 2 is about deciding whether to trust a Federation service offered by an Intermediate node, correct?

If we’re going to add this to the spec, we should describe these possibilities motivate the possibility, rather than leaving people wondering “Why would I do that?”. ;-) It might even merit its own subsection titled something like “Trust Chains from non-Leaf Entities”.

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/729