Allow metadata policy in Trust Anchor Entity Configuration

[Stefan Santesson]

I think I have found the best approach so far to allow federation interconnection without creating policy merge conflicts.

Figure 1 actually shows how to do it:

Trust Anchor B in this illustration chains to the RS under Trust Anchor A without having to include the policy of Trust Anchor A in its chain validation. This is done by bypassing the policy set by Trust Anchor A by a direct link from Trust Anchor B to the Intermediate under Trust Anchor A.

‌

Well, this could be done even on the TA level IF the TA would be allowed to specify metadata policy also in its Trust Anchor Entity Configuration.

The provided image illustrates that metadata policies expressed in the Entity Configuration of the TA will only be processed by those actually using TA A as its trust anchor. Anyone chaining to another Trust Anchor further up will not include the policy in the Entity Configuration.

This creates the same by-pass effect as in Figure 1, but instead of having to do this on all entities under TA 1, we can now do it for all entities under TA 1 in one go.

‌

I therefore propose that we can solve this long debated issue by simply allowing TA to set policy both in its Entity Configuration AND in individual Entity Statements for individual subordinates.

The difference is that policy in TA Entity Configuration will apply to all subordinates, but only when you chain to TA A as your trust anchor which terminates the chain in the Entity Configuration of the TA.

A policy in an individual Entity Statement on the other hand only applies to that subordinate entity and its subordinates. But this policy gets processed also when the chain terminates in another superior Trust Anchor (as illustrated).

[Stefan Santesson]

Suggested change in specification:

Replace last sentence in section 3 under “metadata_policy“

OLD:

Entity Configurations MUST NOT contain a metadata_policy claim

NEW:

A Trust Anchor MAY include this claim in its Entity Configuration statement to specify common metadata policy rules for all subordinate entities that gets processed in all chains that is terminated by this Trust Anchor Entity Configuration. This claim MUST NOT be present in an Entity Configuration for an Entity that is not a Trust Anchor.

‌

Possibly some further explanation of the rationale should go into the document.

[Giuseppe De Marco]

I got your point Stefan, I fully understand the value of a sort of policy manifest, subject agnostic.

the TA publishes the default policies for all its descentants, then subordinate statements can define more accurated and specialized policies for each subordinate.

I believe that we can work on this by outlining more some evidences. The first is the one below.

This claim MUST NOT be present in an Entity Configuration for an Entity that is not a Trust Anchor.

We understand that within different federations, a Trust Anchor (TA) can assume various roles, such as being a leaf in one federation and an intermediate in another. This variability makes it complex to definitively state what an entity can or cannot include in its entity configuration, acknowledging that entities have the autonomy to include any information they deem necessary, depending on the federation context they are resolved within.

If I've correctly grasped the core of your suggestion and the functionality you're aiming for, it appears you're proposing to incorporate metadata into the TA's Entity Configuration in a similar manner to how default constraints are handled.

However, the implications of integrating constraints and metadata policies seem to diverge significantly, given that metadata policies can be extensive in size and complexity, and vary across different types of entities.

I'm contemplating the feasibility of introducing a policy manifest through a designated federation policy endpoint or a similar mechanism. Although this approach presents challenges at the current stage of the specifications, it's worth discussing the advantages and disadvantages here before making any decisions.

[Roland Hedberg]

When an entity enters into a federation it must accept and abide by the rules that the federation has specified. At the same time the federation must behave in a predictable way and of course follow the federation rules and the behaviour specified in the OpenID federation document. It’s a mutual agreement.

One of the cornerstones of the OpenID federation document is that each entity's view matters. For instance an intermediate may want to further restrict the metadata of its subordinates compared to what its superiors defines and it must be allowed to do so.

What you want to do is take away this power from the intermediate. You want at your leisure, as a federation operator, to bypass what any intermediate in the federation wants. In my view it brakes one of the fundamental ideas of the document and I can therefore never accept such a change.

[Michael Jones]

This is very well stated, @rolandh . So well stated that I created issue #2123 saying that we should describe these principles in the Introduction, so that all clearly understand them.

[Stefan Santesson]

@Roland I do agree with almost everything you say. But bypassing node policies by routing is an integrated feature of the current design. And it is, according to yourself in our discussions, the preferred way to handle the situation when a policy would otherwise cause a merge conflict.

Figure 1 of the current document clearly shows how you can bypass a superior entity by issuing a statement directly to its subordinate entity. So bypassing nodes seems OK as long as it follows the contract of superior/subordinate chaining.

And I don’t think the proposal here violates that:

If a TA states in its Entity Configuration that it allows to be chained using a superior Entity (another TA in another federation), then it commits to issuing Entity Statements for subordinate entities that complies with the policy of the superior. This is not changed.

The only thing added here is that this TA also has the ability to specify some general metadata policy rules that applies when you are NOT using that other superior TA. This represents the local rules when you are just using this TA and no other superior entities. That should be as leal as the decision by the superior TA to chain directly to the subordinates of this TA.

Logically this fits right into the current model. And it is very useful.

[Stefan Santesson]

I’m trying to make a better illustration here:

Note: Circles named EC = Entity Configuration, Arrows named ES = Entity Statement issued to the indicated entity by its superior entity

‌

This illustrates 2 ways for Trust Anchor B (TA B) to bypass the policy of TA A when extending trust to Leaf Entity A (LE A). The first example to the left is not allowed by the standard, the one to the right is fully supported.

In the left “NOT OK” model, the policy being bypassed is expressed in the Entity Configuration of the TA A.

In the right “OK” model, the policy being bypassed is expressed in an Entity Statement issued by TA A.

Both models follow the logic of honouring the contract upwards and downwards with respect to the chains they participate in.

why is one allowed but not the other?

This seems like a big missed opportunity here.

[Michael Jones]

Thanks for writing, Stefan. My assessment of the arrangement you describe in your “OK” illustration isn’t that “TA A”'s policies are being bypassed. Rather, “TA A” isn’t being used in the trust chain to “TA B” at all. So “TA A” is irrelevant in that case.

As for the “NOT OK” illustration, that’s supported and “TA B” can augment or restrict whatever policies “TA A” has. That’s by design.

Maybe I’m missing something, but I don’t see a problem here. Everything is working as intended.

[Roland Hedberg]

In the illustration in the “NOT OK” model is TA B added as a superior to TA A ? If so that is perfectly OK.

You write about the “NOT OK” model that “the policy being bypassed is expressed in the Entity Configuration of the TA A.”. To this I would like to say that metadata policy can not appear in an Entity Configuration. It can only appear in a subordinate statement. So I’m not sure what you are referring to.

[Stefan Santesson]

@Roland I’m perfectly aware that a policy can’t appear in an Entity Configuration. That is exactly what I want to change.

That is what this whole issue is about.

IF I would be allowed to include a policy in the Entity Configuration of the TA, THEN it would be possible to do what is illustrated by the “NOT OK” illustration.

[Giuseppe De Marco]

During the editor’s call on 29 march 2024, we agreed that the specification works as we think it should and we decided to close this issue in a week since we don’t expect to create a PR for introducing metadata policies within the TA entity configuration.

[Michael Jones]

Closing, per the decision a week ago. No further comments have been added to the issue since then.