[Federation] What a trust chain contains.

[Roland Hedberg]

When a trust chain is collected a well defined pattern is used.

1. collect leaf Entity Configuration
2. for each entity_id in authority_hints collect the superiors Entity Configuration
3. Fetch the Entity Statement from the superior about the subordinate
4. Repeat from 2

This will result in collecting something like this

1. Leaf Entity Configuration
2. Intermediate (A) Entity Configuration
3. Intermediate (A) Entity Statement about Leaf
4. Intermediate (B) Entity Configuration
5. Intermediate (B) Entity Statement about Intermediate (B)
6. Trust Anchor’s Entity Configuration
7. Trust Anchor’s Entity Statement about Intermediate (B)

Alternative Entity Configurations and Entity Statements.

The trust chain is presently defined to contain the element 1, 3, 5 and 7

Given that the entity that collects the trust chain has the key of the Trust Anchor the trust chain can be verified and the metadata can be constructed.

Now, it is assumed that the Trust Anchor rotates its signing keys. The new keys can be distributed to the federation entities in some out-of-bands way or possibly by adding the Trust Anchor’s Entity Configuration to the trust chain.

Adding the Trust Anchor’s Entity Configuration should be optional and if done should be added as the last element in the trust chain.

[Michael Jones]

Should we revert the example in https://openid.net/specs/openid-connect-federation-1_0-22.html#name-trust-chain to the text in https://openid.net/specs/openid-connect-federation-1_0-21.html#name-trust-chain ?

[Roland Hedberg]

I think we should make clearer in the text the difference between what needs to be collected and what needs to be in the trust chain.

[Roland Hedberg]

The reason for putting the TA’s EC at the end of the trust chain is that the necessary components of the trust chain (Leaf EC + possible intermediates ESs + Trust Anchor ES) should form a continues ordered sequence irrespective of whether the TA EC is part of the trust chain or not. Adding the TA EC to the end makes it easy to first detect if it’s there or not and then remove it before the chain is verified and the metadata computed.

[Michael Jones]

I agree with Roland’s “continuous ordered sequence” observation.

[Giuseppe De Marco]

I agree too, I also think that including the TA’s EC in the trust_chain parameter, as used in the authz request or in the client registration request, would hint a trust verifier if the TA’s EC has been updated in the meantime

[Giuseppe De Marco]

@Roland Hedberg considering the importance of the difference between what’s collected (metadata discovery) and what’s it’s included to be evaluated (trust chain) I’d suggest to add Metadata Discovery in the defined terms and have a small editorial review where the term metadata discovery has been used.

‌

[Giuseppe De Marco]

Two PRs for the resolution of this issue:
- https://bitbucket.org/openid/connect/pull-requests/302
- https://bitbucket.org/openid/connect/pull-requests/303/fix-federation-metadata-discovery-in-the

[Vladimir Dzhuvinov]

including the TA’s EC in the trust_chain parameter, as used in the authz request or in the client registration request, would hint a trust verifier if the TA’s EC has been updated in the meantime

I suppose by a TA EC update here you mean the addition of a new signing key?

If the TA has immediately switched to the new signing key the hinted entity has no way to proceed if its key update involves a manual (out of band) intervention by an admin. The signature validation will fail and the admin will need to intervene to verify and update its record of the TA’s signing key. In such a scenario there is not much value in having a TA EC in the trust_chain.

If the TA adds a new signing key but doesn’t switch to it immediately, the hinted entity will have a mean to detect that without an outbound HTTP call to the TA, and either alert the administrator (given some sensible reaction time) or update its TA keys automatically (by directly adopting the new key from the TA EC jwks, by doing a fetch, or a mix of both). Is this what you had in mind? For planned key rollovers this can definitely work. In a case when all TA keys get revoked and need to be replaced at once, an outbound HTTP call to the TA cannot be prevented.

[Giuseppe De Marco]

The rollover strategy is something covered in our implementations and led to how the good TA should behave.
When a key is rolled out, then the new one will be used when times will permits and the old one will be pruned, otherwise the jwks list in a EC may increase during the years.
That’s why I want to prune the deprecated keys from the EC and have a new endpoint for the TA where it publishes the registry of the hystorical jwks.

The reasons why we should have also the EC in the TC is explained here: https://bitbucket.org/openid/connect/pull-requests/302#comment-331647190

[Giuseppe De Marco]

Closed by https://bitbucket.org/openid/connect/pull-requests/302