Possibly Ambiguous Metadata Policy

[SECtim]

As far as I can see, the following Federation hierarchy is allowed by the specification:

    TA_____
   /  \    \
 Im1  Im2  OP
   \  /
   Im3
    |
    RP

Furthermore, the specification seems to allow for Im1 and Im2 to define conflicting metadata policies for, say, the openid_relying_party entity type. For example, Im1 may require token_endpoint_auth_method to be private_key_jwt (i.e., using the value operator). Likewise, Im2 requires the token_endpoint_auth_method to be self_signed_tls_client_auth.

For example, how would RP register at OP in this case (Section 12.2)?

Side note: Whether or not RP accepts this registration (see Section 12.2.2.2 No. 4) now depends on which of the two possible Trust Chains RP uses when checking compliance of the registered metadata with the policy. Intuitively, the outcome of the compliance check should be deterministic (i.e., disregarding transient issues, an honest OP's registration should always be acceptable to an honest RP).

[selfissued]

Related to #7

[vdzhuvinov]

If the Im1 and Im2 impose conflicting policies, while being compliant with the TA's policy, the intuitive action for the RP is to raise an issue with its immediate Superiors. Or, if OpenID Connect Relying Party Metadata Choices 1.0 is supported, use the RP metadata parameter token_endpoint_auth_methods_supported.

{
  "token_endpoint_auth_methods_supported" : ["private_key_jwt", "self_signed_tls_client_auth"]
}

https://openid.net/specs/openid-connect-rp-metadata-choices-1_0-00.html

At today's call we found out that we'll need to update the section "Metadata Policy Principles" - the 6th principle of Determinism.

https://openid.net/specs/openid-federation-1_0.html#section-6.1.1-2.12

Currently it says:

The resolution and application of metadata policies in a Trust Chain is deterministic. Trust Anchors and Intermediate Entities are thus able to formulate policies that exhibit predictable and reproducible outcomes.

I have a proposal to edit it to say this instead:

The resolution and application of metadata policies in a given Trust Chain is deterministic. Trust Anchors and Intermediate Entities are able to formulate policies that exhibit predictable and reproducible outcomes for all Subordinate Entities for which a single Trust Chain can be built.

[SECtim]

If the Im1 and Im2 impose conflicting policies, while being compliant with the TA's policy, the intuitive action for the RP is to raise an issue with its immediate Superiors.

Maybe, but I think the Federation spec should either prevent or give guidance on this scenario: If the WG agrees that such a situation in an undesirable state, then the spec should say that such conflicting policies are not allowed and who is responsible for enforcing this rule (and how). If, on the other hand, such a situation is intended to be allowed, the spec should give clear guidance on what do to in such a situation (or at least explicitly mention that something like this might happen).

[zachmann]

Personally, I would say it's an undesirable state, but something that can (and will) happen; I don't think it's a realistic approach to forbid it, since federation topologies can get arbitrary complex.

I think guidance how to handle such situation is very much needed.

[vdzhuvinov]

the Federation spec should either prevent or give guidance on this scenario:

I'm okay for the spec to include some sort of guidance on this. But I don't want to think about the wording of this :)

There might be ways to prevent this, but it is going to complicate the protocol. This will require authorities to periodically crawl the federation and check the chains.

At first I thought federations will be something elegant and "ideal", but now I see it's going to be more like the Internet, which generally works, despite the occasional networking faults.