- edited description
[Federation][list endpoint] Listing by type
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.
Comments (12)
-
reporter -
reporter - edited description
-
@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.
-
reporter 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 -
reporter - changed status to resolved
Out of interest for the specs
-
reporter - changed status to open
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?
-
reporter - changed title to [Federation][list endpoint] Listing by type
- marked as proposal
-
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.
-
reporter Well, now I have guilt for that :'-)
-
reporter 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-policyand 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
-
reporter is_leaf removed in this PR
https://bitbucket.org/openid/connect/pull-requests/171/federation-added-trust_chain-in-resolve -
reporter - changed status to resolved
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
- Log in to comment