[Federation] Trust Chains can start with an Entity Configuration of a Leaf or an Intermediate Entity

[Vladimir Dzhuvinov]

Section 3.3 Trust Chain states that

A Trust Chain begins with a Leaf Entity Configuration

https://openid.bitbucket.io/connect/openid-federation-1_0.html#section-3.2

There can be instances when a Trust Chain is assembled for an Entity that is not a Leaf, for instance this could be an Entity that issues resolve responses and as such it may be an Intermediate:

https://openid.bitbucket.io/connect/openid-federation-1_0.html#section-7.2.2

‌

[Giuseppe De Marco]

this is an important detail.
Another, more tactical, is the following.

Imagine to have TA and INT, where INT has >1k of leafs.
OP builds the trust chain for INT and it keeps it apart, periodically it renews this trust chain.

LEAF has in its authority_hints that INT.
Eveytime a LEAF establishes a connection to OP, OP doesn’t discover LEAF’s trust chain but only LEAF’s EC and INT’s ES regarding LEAF, the remaining part is simply reused.

[Vladimir Dzhuvinov]

This can be a significant optimisation for high traffic entities. Recently we got a ticket and implemented Trust Chain resolution support with “custom” HTTP clients so that responses can be cached and reused. But what you propose can be put to work in an even smarter caching. I just created a feature ticket for this. Thank you

[Michael Jones]

We can do that, but let’s merge https://bitbucket.org/openid/connect/pull-requests/655 first. Otherwise everything we write will be a merge conflict.

[Michael Jones]

And let’s also merge https://bitbucket.org/openid/connect/pull-requests/662 . It contains overlapping content about the content of Trust Chains, which we should resolve. Currently both Section 3.2 (Trust Chain) and Section 8.2 (Validating a Trust Chain) assume that Trust Chains start with a Leaf. We’d have to update the content in both places or harmonize these sections to say it all in one place.

[Giuseppe De Marco]

Here the PR https://bitbucket.org/openid/connect/pull-requests/671

[Stefan Santesson]

I would like you to consider that not all leaf entities will have the capability to publish Entity Configuration on a .well-known location.

My experience with government authority services, managed by sub-contractors is that such requirement will be hard to enforce. That is why we want to avoid this as a hard requirement if their superior entity is capable of compensate for this by punishing their metadata directly in the Entity Statement for that entity.

But more importantly is that entities such as OAuth clients not be placed in servers that are publicly available for direct remote access.

What are your thoughts on this?

I think it is important to allow the case where there is no stable URL for the Entity Configuration and allow the chain to be built from the superior Entity Statement. This can be challenging for discovery, but I have ideas on how to solve that through a resolve endpoint if this is the reality for a federation.

[Giuseppe De Marco]

@Stefan

The current text satisfies the requirements, as mentioned in the following answer

https://bitbucket.org/openid/connect/pull-requests/671#comment-444286796

We have two landmarks:

Entity configuration and trust anchor. If we remove the First we then Need to know a priori which intermediate/ta to query

For your requirements there May be two patterns:

Static trust chains in the authz requests. The jwt issuer would put in the trust chain related to itself its entity configuration without exposing the well known openid-federation endpoint. This disables both the federation entity discovery and the periodical updates of the expired trust chains (since there wouldnt be any possible direct refresh of the leaf’s EC)

Another pattern would be starting the Discovery from the ta, collecting all the subordinates untill an INT or the same TA would provide the ES with the subject of interest (and the metadata in It)

These two options reduce the federation infrastructure and should be considered narrow federation implementations, however they seems to work for you.

Before taking a decision, take your time looking for pro and cons of this decision. A wellknow endpoint is a static file to be periodically updated with a cronjob. Probably a narrow impl costs more when federations like your and mine look to be merged under the same superior TA, this could be messy due to the interop issues caused by these impl choices.

Publishing an openid federation endpoint costs definitively less for the implementers

‌

[Stefan Santesson]

See my reply to the linked PR.

I think a misstake we often do when writing standards is to think that a task that takes many CPU cycles is harder than an inconvenient requirement on the end user. So many times it is the opposite. What I lack in your description is the power of using resolvers.

The resolver is more than capable to use the CPU cycles necessary to traverse the federation and map where every entity is. I even think it is trivial even for a fairly small server. If there is a duplicate registration this could be flagged and resolved manually. This is normal stuff.

Yes. I also prefer if Entities publish their Entity Statement. It makes it faster to absorb any changes. But again, metadata are fairly stable and the speed of update has never been a critical factor in our experience.

Again. It is important that the federation can choose the policy that suits them.

[Stefan Santesson]

I would like to express here that after careful consideration. I think I was wrong here.

Allowing a chain to start with an Entity Statement and not and Entity Configuration has severe consequences for the logic of this standard.

Attempting to fix those problems demands to much complex changes.

I realise that there are better ways to handle entities that don’t have the capability to publish an Entity Configuration. I also stated this in the PR.

‌

I support that all chains MUST start with an Entity Configuration.

‌

[Vladimir Dzhuvinov]

Stefan,

Do you reckon some text in the spec needs to be edited or rewritten to help other readers? We’re currently going through an extensive editing to be more explicit and clear about the choices made in the OpenID federation spec and its security properties. Occasionally I try to read the spec as if I’m encountering it for the first time, but that’s not the real experience of course.

[Stefan Santesson]

For me, the most important thing is to clarify where the use of a resolver is a legitimate alternative to chain validation. Chain validation must always be possible, but should not be necessary if there is a suitable resolver that can do that job for you.

I would be happy to offer a helping hand.

[Michael Jones]

We discussed this on Feb 1, 2024. This is too disruptive a change to make before the pending Implementer's Draft.

[Stefan Santesson]

I agree. We can close this. This can be handled by using a specific federation key for subject signing that could be outsourced to the IE.

[Michael Jones]

As a clarification, we're not proposing that Subordinate Statements ever start Trust Chains. Only Entity Configurations that are Leaves in the context of the Trust Chain creation begin them.

[Vladimir Dzhuvinov]

Renamed title for clarity

[Michael Jones]

To be fixed by https://bitbucket.org/openid/connect/pull-requests/729

[Michael Jones]

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