Issue when building an entity chain from entity to trust anchor when entity is trusted by multiple intermediates

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2144

Original Reporter: MichaelFraser99

In the below example, we have a set of entities that are both trusted and can have entities issued for by the Banking Authority and the Insurance Authority. In this scenario, the banking authority will issue a metadata policy dictating what is allowed/needed to act as a bank and the insurance provider will do the same providing what's required to act as an insurance provider.

The concern arises when an entity wishes to produce a statement when its acting as both. Currently, the spec requires two chains to be built either manually or through the use of the resolve endpoint and then manually combined to produce the final entity statement.

How should this be best addressed/communicated?

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: mbj

There’s nothing preventing implementations from building multiple trust chains in parallel, potentially ending at multiple mutually trusted trust anchors. At most, we might want to relax the language about choices made while following authority hints to explicitly say that multiple options can be explored if desired.

Would that do the job?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: rolandh

I think the key point in your description is “acting as both”.

It’s easy to verify that an entity is both a bank and an insurance provider but that is not the same as proving that it is acting as both.

Right ?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: MichaelFraser99

Yes the key point as as you say, when an entity is acting as both. As you both pointed out above we can have the two chains built and then combined after the fact if a desired “insurance AND banking” statement is to be produced. Though todo this the chains must be constructed manually.

Another point though and I’m not sure if it fully qualifies as a hole, but, in the above scenario, if an entity were to use a resolve endpoint to construct a chain between any of the entities and the trust anchor, there isn’t a way in the resolve endpoint to specify which path the chain would be produced for? I.e. one implementation may go via the banking authority intermediate and another would go via the insurance authority intermediate - both would produce different entity statements as a result

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: RaidiamRalph

All, please note that there are very large banking groups that do a lot of international settlements that are looking at exactly this challenge. Cross border open banking. There are also ecosystems domestically with multiple federations / regulators where attributes (scopes, claims etc) are authorised and granted by different federation controllers to the same relying party. Solving this problem or somehow indicating that the trust chains / anchors need to be completely resolved along all trees is a requirement that we have now so i’m keen to see this problem resolved within this WG rather than having ecosystems come up with fragmented profiles of federation to meet this need.

[TomCJones]

It is the responsibility of the leaf node to create the chain so it is up to it to create the chain it wants. It may be that for different tasks the leaf would create different chains, and that is fine. For example at work and at home.
It's possible that a note should be included in the spec for clarity.

[Razumain]

My point on this is that entities should not be enrolled under multiple Intermediate entities that chain to the same trust anchor. For me that is a federation management issue and nothing that the standard must sort out.

From the perspective of the Resolver, it has no possibility to determine what path to use.

In our implementation of the Resolver, we build a cache of all paths to each resolvable entity, in order to speed up the resolve process. This we do by traversing the tree top down using the listings endpoints. If we encounter a path for an entity that already has an existing path, we simply pick the latest and discard the other. Whatever path we find is considered valid and we have no reason to pick any particular over another.

There can be no expectancy for a requester to a resolve endpoint to expect a particular path. The result is that what path you get will not necessarily the same you would get from another resolver, or from doing path building yourself bottom up.

I think it would be OK for the standard to explain the consequence of providing multiple paths to the same trust anchor, in the worst case it could mean difference in metadata if metadata policy of the paths differs. But I think it is the responsibility of the federation entities to collaborate in order to avoid ambiguities.

[selfissued]

@rohe and @MichaelFraser1999 , do you agree with adding Implementation Considerations text along the lines that @Razumain suggests above?

[peppelinux]

I agree with @TomCJones

during the past days I have proposed this PR to hint the TA above a subject: #138

this approach could be expanded, using an hint that brings the entire path to to a specific TA

given example below (edited 20 nov 2024):

trust_path_hints: {
  "https://ta1.example.org": ["https://int-direct-descendant-of-the-ta.example.org", "https://int-direct-descendant-of-the-int.example.it"],
  "https://ta2.example.net": ["https://int-direct-descendant-of-the-ta.example.net", "https://int-direct-descendant-of-the-int.example.net"],
  "https://ta3.example.net": [] // in this case the ta3 is the immediate superior of the leaf
}

1. it would be only an hint, since it's up to who evaluates the trust to decide the path it wants to use.
2. there must not exist multiple path to the same trust anchor
3. the json object members names (trust anchor identifiers) are not sorted
4. it may be published in each Entity Configuration (optional claim, it's only an hint)
5. the leaf's entity id must not be included within each array, since every hinted path is about the entity configuration subject

The value proposal about this parameter is that who evaluates the trust might follow the trust path hint and therefore not worrying about the infinite number of authority hints that there might be in each entity configuration, because the path helps who evaluates the trust with a hinted path. This reduces the computational costs of inspecting several paths for each authority, and only focusing on the hinted path.

[peppelinux]

See this proposal: #86

[Razumain]

I don't feel comfortable with this proposal.

I see that we are trying to solve some kind of perceived problem here. But I'm not convinced that the problem is real or should be mitigated by the standard, and I see potential problems.

By all means it will be possible to build bad federations. That does not mean that we should assume that people will, and if they do, that we need to fix it for them. If you build a federation with incompatible paths, shit will happen, regardless of whether this information is there or not. The proper solution is to fix your federation.

Secondly, I don't think that it is role of the claiming party to tell the verifying party how to verify. That is fundamentally wrong as the claiming party, until proven otherwise is a potential attacker. If the potential attacker has exploited a part of the system, it makes the attack much more effective if you can "hint" the verifier to use the part of the system you have broken.

Finally, a federation is (or may be) a constantly changing infrastructure (plasticity). That is a good thing. When we change things, add a new IE, or make new connections, things should not break.

This is a typical thing that could potentially break things. If you enter a path hint today, it may not be valid tomorrow. Advertising path hints carries the risk to solidify federation topologies out of fear of breaking leaf entities that made these statements.

I think a TA hint could be useful, but not as a hint to validate self, but as a hint about what self is preferring when validating others. That is, a TA hint is a statement that when I validate others, these are the TA:s I will use. This way you can let others decide what path about themselves they should send to you, or evaluate if you are likely to be able to validate them, and if so, what metadata about them you are likely to see.

[selfissued]

This resonates with me:

By all means it will be possible to build bad federations. That does not mean that we should assume that people will, and if they do, that we need to fix it for them. If you build a federation with incompatible paths, shit will happen, regardless of whether this information is there or not. The proper solution is to fix your federation.