[Federation] Implementations SHALL process all metadata and policies that are applicable to entity types that they include

[Vladimir Dzhuvinov]

A Trust Chain may include metadata and / or policies for more than one Entity Type. An Entity processing a Trust Chain may safely skip "5.1.4. Combining Policies" and "5.1.5. Applying Policies" for any Entity Types it is not interested in. For example an RP (openid_relying_party) processing the Trust Chain for an OP (openid_provider) may ignore any metadata and policies under oauth_authorization_server, oauth_resource, etc. This is chiefly intended as an optimisation, to save resources when dealing with Trust Chains.

Q: Specify as “MAY ignore” or “SHOULD ignore”?

[Giuseppe De Marco]

it makes sense, even if there may be some cases where a trust chain and its derived final metadata are stored to be reused later on for other purposes, since the lookup parameter is the sane entity id for different metadata

I would handle this within the scope of implementation considerations if we agree

[Giuseppe De Marco]

Then “MAY”

[Michael Jones]

We briefly discussed this on the 18-Sep-23 working group call. I believe this is ready for a pull request.

[Tom Jones]

I am not used to seeing policy that can be ignored. I guess this means some sort of suggestion? If the policy is IAL2 is required, can that be ignored?

[Vladimir Dzhuvinov]

Hi Tom,

I suppose this proposal looks strange and rang alarm bells :)

But it actually makes a lot of sense given the nature of OIDC Federation and its adoption of a concept called Entity Typing, which then results in Entity Typed policies.

An Entity in a federation can have multiple roles. For example it could be both an OP and RP. When such an entity enrolls with a federation authority, the authority will then issue statements for it that may include policies for both roles- the OP role and the RP role.

If I’m a RP that wants to talk to that entity’s OP I will only be interested in the OP metadata and policies in the Trust Chain. I would not be interested in the RP aspect, so I can skip processing that aspect of the Trust Chain.

‌

‌

[Tom Jones]

sounds like entity typing was a mistake. I still don’t understand the point of a policy that i can ignore. That defies all concept of what a policy is.

[Giuseppe De Marco]

@Tom Jones you are right! However those who implement an RP want to interact with an OP and not with another RP

if the other party is both an RP and an OP and an RS and more, the only thing that matters is getting the final metadata of the OP and for the scope of the user authentication.

Think of the trust chain as an OOP class, with attributes and methods, where the method get_final_metadata(entity_type :str) applies policies to the metadata for the requested type.

If the final metadata serves a purpose and for a single entity it is useless to calculate all the final metadata of the useless roles (AS, RP, Client, Wallet Provider, Credential Issuer …). Does it come back to you?

[Tom Jones]

optional policy will not survive an audit

[Giuseppe De Marco]

Well I would say that we may come to the conclusion that we have discussed an implementation choice that could be included in a section dedicated for the implementation consideration but it would be dangerous for the readers that may misinterpret it

I would add to the discussion that we use to say that the final metadata is derived from the trust chain, while we’re asserting that several final metadata may be derived from a single trust chain, where “THE” final metadata is the one intended for the scope of a particular transaction. This would make the resolution of this issue without relaxing the security requirements of the policies

[Tom Jones]

The very idea of implementers ignoring polices should scare the crap out of the ciso.

[Michael Jones]

I think the idea here is that we could add implementation guidance that deployments need not process metadata for entity types that they’re not going to use, because they’re going to ignore it in the end anyway.

[Tom Jones]

The language used in the title of this issue should cause it to be rejected out-of-hand. Then if someone wants to create a issue that is framed in positive terms that could probably be more acceptable. “consumers may ignore… policies” is just a red flag. Say something like: Implementations SHALL process all metadata and policies that are applicable to entity types that they include.

[Giuseppe De Marco]

Thanks Tom, your proposal makes sense. Title changed, then we look forward for a PR that resolves this issues and give more guidance to the implementers

[Michael Jones]

https://openid.net/specs/openid-federation-1_0-31.html#name-applying-policies already says:

For every Entity Type metadata parameter for which a policy entry is present, the policy operators MUST be applied in accordance to their definitions in Section 5.1.1 and in a sequence as follows:

Therefore, I believe the specification already is clear on the topic of this issue. That said, when the application context makes it clear that metadata is needed only for a particular Entity Type and that for the other Entity Types will be unused, it’s fine as an optimization to produce only the metadata that will actually be used, as an optimization.

We discussed this on the 1-Dec-23 Federation editors' call. We believe this issue should be closed on that basis.

[Vladimir Dzhuvinov]

Closing on the basis of https://bitbucket.org/openid/connect/issues/2063/federation-implementations-shall-process#comment-66221219