.well-known/openid-federation - protected endpoint

[Andrii Deinega]

Let's say organization A, organization B, and organization C are members of federation F. Now, it’s desirable for me to hide the fact that all these organizations are affiliated/connected with each other. I do not want organization Z, and basically, any other actors in the wild to know about that.

Right now, it doesn’t seem to be possible because the federation metadata is publicly available, and of course, the metadata is unencrypted. I’m wondering if this scenario is something the specification would want to address + what are WG’s thoughts on this matter.

Mike Jones and I briefly discussed this scenario at IIW and he suggested filing an issue for it.

[Giuseppe De Marco]

In

https://openid.net/specs/openid-connect-federation-1_0.html#section-6

We read that the well-known openid-federation should be available

We can explain the rationale behind the optional decision to protect that endpoint, with the description you made, and leave this decision up to the implementation profiles.

By default It must be public, a federation implementation May protect this endpoint. The questions are:

• How? → Generic pointer to all the ways an endpoint could be protected
• Is this coherent with the scope of the well-known endpoint?

The discussion is open

‌

[David W Chadwick]

Now consider a federation that does not use the OIDC Federation specification, as is being experimented with in GAIN. Firstly any Federation that does not support GAIN or OIDC Federation will have its own proprietary mechanism for members to determine if other members are trusted. So we can say that these private federations can remain secretive if they want to. So Z can never learn that A, B and C are members of it (as it does not know the protocol).

Now consider one of these secretive private federations decides to migrate from their existing proprietary protocol to using the OIDC Federation protocol. Because they wish to remain private they agree amongst themselves not to use the well-known endpoints but to define their own secret ones. There is nothing to stop federations from doing this.

So I conclude that federations that wish to remain private should not use the standard OIDC Federation spec but should use their own proprietary mechanism in some way so as to remain private. This means that they can never join GAIN, but that is OK as GAIN is meant to be a global mechanism for determining trust (much like the global PKI system is meant to be for the web. Implementations today can define their own private PKI systems that are not visible to the global web PKI).

[Michael Jones]

Given that federation metadata is public, I don’t think that hiding an entity’s participation is possible.

[Michael Jones]

The Federation architecture requires that the metadata be publicly available. Your request to hide participation is not possible.