[Federation][list endpoint] Listing by type

[Giuseppe De Marco]

Working on the concrete implementation of OIDC Federation I realized that it would be useful for a Relying Party to use the List response to get the list of OPs for which build the trust chain and also the discovery page, where the user selects where to authenticate.

For this reason I propose to add the following to the List endpoint request parameters:

type

OPTIONAL. A specific entity type to filter. If no value is given then all the entities types are expected to be returned.

[Michael Jones]

@Roland Hedberg wrote this to me about this issue:

Through out my discussion with Giuseppe I’ve maintained that a superior MUST know two things about a subordinate: the entity ID and the public part of the entity statement signing key. Nothing more.

If we want 'list by type’ we have to mandate that a superior must gather more information about its subordinates.

If we started doing that where would we draw the line ?

I agree with him that this would complicate the job of superiors. Therefore, I believe we should not do this.

[Giuseppe De Marco]

In my implementations we adopt this additional parameter to let RP filter all the OPs to include in a discovery page.
Roland told me about his reluctance to adopt this parameter and there’s no problem by my side, I just wanted to share my use case in a real implementation

[Giuseppe De Marco]

Out of interest for the specs

[Giuseppe De Marco]

I thought about this issue, and wondered about the meaning of the is_leaf (bool) parameter.

The answer is : "by the metadata of the descendant". On the base of this, why a superior can't knows if the descendant is a oauth_rs, a RP or a OP?

[Michael Jones]

In discussions with Roland and I, Andreas Solberg suggested removing is_leaf, as it’s unnecessary. Then we would consistently be doing no entity filtering.

[Giuseppe De Marco]

Well, now I have guilt for that :'-)

[Giuseppe De Marco]

Anyway, this issue (that personally support) suggests that a superior MAY know the entities of the descendants
https://bitbucket.org/openid/connect/issues/1493/federation-devise-mechanism-for-policy

and this a may appear to contradict the principle that a superior should not know or may not know anything about the types of descending entities

[Giuseppe De Marco]

is_leaf removed in this PR
https://bitbucket.org/openid/connect/pull-requests/171/federation-added-trust_chain-in-resolve

[Giuseppe De Marco]

Decided to remove the need for a superior to know everything about its descendant.

Anyway, I feel like this issue will come back in the future but it's not something for today