Request to use standard OpenID Connect Discovery (Section 4.3)
Issue #1658
open
As far as I understand the text, the assumption is the RP will use the metadata obtained through OIDC federation, i.e. special logic (section 4.3. could benefit from a reference to section 10.4).
Is it possible/envisioned to just assert the issuer URL in an OP entity statement? I’m asking since that would allow RP’s to use the standard OIDC discovery and ID Token signature validation process (just bootstrapped from an entity id). I think adoption would be fostered if the standard process would be supported as well (as this is what existing implementations do).
Comments (13)
-
-
reporter
What's the benefit we may have from this?
Ordinary OpenID Connect RPs (like in our network) can utilize IDPs in other networks in the GAIN context without changes.
-
I tried to solve the problem of using multiple jwks claim here
https://bitbucket.org/peppelinux/connect-2/commits/476a2864d980a5cf79e62af72559cd2d65efbbbe
-
As discussed on the 6-Oct-22 working group call, once RPs know the issuer URL, they could then use the standard .well-known/openid-configuration mechanism.
-
This breaks the metadata policies and the proof that a participant Is still in the federation (It wasn't excluded)
The behaviour proposed in this issue seems to break all the requirements related to the trust chain freshness, the participants would build the trust chain on the registration phase, una tantum, and then we'll use only openid-configuration (that lacks of several metadata extensions defined in the Federation specs).
Are we sure to enable this design in the federation specs?
-
- changed status to open
@Roland Hedberg - it would be great if you could think about this one.
-
Just so I understand your issue.
Is it about replacing using the OIDC fed discovery with using OIDC core discovery ?
Or are you proposing that a RP would first use OIDC fed discovery and then pick up metadata using OIDC core discovery to replace whatever it got in the OP’s entity configuration ?
Or have I completely missed the point ?
-
reporter
I’m looking for a way to enable access to OPs via Federation for existing OpenID Connect RPs with minimal code changes.
-
@Torsten
How do your RP behave when an authz request would be requested for a unknown OP, does your RP request a dynamic client registration to that OP?You’re looking for an implementation strategy. OIDC Federation defines how the trust must be established/evaluated. We can say that a narrow implementation of Federation may use the Federation stack only for the registration phase but that’s wouldn’t be something needed in the Federation specs.
The answer to my first question may open a discussion on how an implementation can fit some well known requirements and constraints we face in the legacy infrastructures, interesting indeed but not for the specs
-
The key issue seems to be establishing that the RP is a member of the federation. If that’s possible for standard Connect RPs (possibly with some additions), then great, there’s something to consider. If that’s not possible, it doesn’t meet one of the core design goals for federations.
-
- changed title to Request to use standard OpenID Connect Discovery (Section 4.3)
-
-
assigned issue to
Vladimir Dzhuvinov
-
assigned issue to
-
-
assigned issue to
Michael Jones
This is related to the request to be able to secure metadata using TLS certificates rather than signed entity statements.
-
assigned issue to
- Log in to comment
This would represent a non conventional way to evaluate/build the trust.
Federation works with the trust chain where the First element of the chain Is the leaf's entity configuration and the final metadata Is the result of the policies collected along the chain.
What you suggest Is interesting, however It represents a narrowed implementation of Federation that assumes that:
What's the benefit we may have from this?