Guidance / Strategie on how to deal with conflicting metadata due to trust chain selection

[zachmann]

This is a longer issue and touches / relates to several other ongoing
discussions (#7 #68 #86 #100 #138). This is (in some form) more general. The assumption in the
following is that there are multiple trust chains with different resulting
metadata, and depending on which trust chain is chosen communication can happen
or fail.

Two entities (RP and OP) want to talk to each other (I assume oidc auth code
flow with automatic registration, but this should be a general problem).

The RP would send a request, the OP processes it. To do so the RP must know its
own capabilities and the capabilities of the OP (By capabilities I also mean
supported parameter(s) and values, e.g. used authentication scheme, scopes).

In plain oidc the RP knows its own capabilities and obtains the OP's from it
openid-configuration. In oid-fed the RP still knows its own capabilities, but
these might be restricted by metadata policies, which the OP will evaluate
according to his rules (which TA and trust chain to choose).
The RP also can obtain the OP's metadata from the /.well-known/openid-federation which
then again might be restricted by metadata policies, here it is the RP to decide
which one to use (assuming there are multiple (different) options) before doing
the request.

When the OP obtains the request the RP has selected a trust chain and resulting
metadata for the OP, and from this has chosen certain values for the request.
Now the OP has to verify that the choosen values are fine with him and his
federation. Therefore it will choose a trust chain from the RP to one of his TAs.

Now it might be that the request does not comply with the metadata chosen by the
OP for the RP.

I think that this case can happen and that we should not restrict federations in
a way that it cannot happen. I also think that in practice it might not be too
much of a problem. Anyway, I believe that the specification should include
guidance for implementers how to deal with such conflicts (assuming that there
is a combination that works; if that's not the case of course it will always
fail in the end).

In my opinion the following should be considered.

• The OP should when handling the request and no trust chain is given in the
  request and multiple trust paths exist, try all of them. This means:

  • The OP needs to build all trust chains (eventually), not stopping at the
    first valid one that gives valid metadata
  • If one resolved metadata conflicts with the request, it will try the other
    options
  • If one works, good; it might be a good idea to cache this, but this is an
    implementation detail
  • If all resolved metadata conflicts the request, it must return an error

• The RP on the other side should before doing the request, resolve its own
  metadata as viewed by the OP.

  • Therefore, it requires the "viewpoint" of the OP, this could be obtained through
    the proposed ta_hints.
  • The RP would (potentially) need to resolve all trust chains from itself to
    OP's TAs and evaluate the metadata policies.
  • It needs to check if the resolved metadata conflicts with its intended
    request.
    • This also has to take into account the OP's metadata (where multiple chains->metadata can exist)
    • If no, it can do the request and should include the chosen trust chain in
      the request
    • if yes another trust chain's metadata must be checked.
  • If all resolved metadata conflict, they cannot communicate.

• In my view this would ensure that (if it is possible) RP and OP can
  communicate with each other, but it puts significant work especially on the RP. Using a
  resolver can help, but it would still be more complex than just firing the request.

• Therefore, the RP might just try it's luck without evaluating OP's view of RP.
  And only when the first request fails, do the full shebang.

This would require both, the OP and the RP to (potentially) evaluate not only a
single trust chain but multiple to a single or multiple trust anchors. IMO it is
very sensible to rely on a resolver for that. However, the resolver only returns
a single metadata / chain. So to enable this the resolver would need to be able
to return multiple results, not only a single one. This would probably require
an extension (something like a extended resolve endpoint).

It might also be possible to offload more work to the resolver by including
additional (yet to be defined) request parameters.

As an alternative approach it might be feasible to fall back to explicit
registration in such a case. I'm not too familiar with that, so I don't know if
similar problems could arise there too.

It is also very possible that I might miss certain aspects; anyway I wanted to
have (yet another issue to have) a discussion on this and hear others opinion on
this. And I'm sorry about the wall of text.

[Razumain]

Thank you for this elaborate showcase of possible interoperability issues that parties may have to deal with.

Let me argue why none of this is a problem that should be fixed in the OpenID federation specification.

A peer that wants to communicate with another peer (OP serving a request from an RP) should pick the TA they are configured to trust in the context they operate. If they operate in multiple contexts (multiple federations) they may try several TA:s. That is the choice of the validating party and nothing we should regulate.

If the OP in this case is not satisfied, for what ever reason it may have, it will reject the request, otherwise it will serve it.

Resolving a peer using a single TA should lead to compatible results. If this is not the case, then the federation setup should be fixed. It should not be fixed by the peers that validates metadata.

When peers fails to communicate, they will investigate why and fix it outside of the protocol. This could be:

• A fix by the RP by making sure it is resolvable by the TA required by the OP
• A fix by the RP by adapting its metadata
• A fix by the OP by adding another TA to its acceptable roots of trust
• A fix by a federation by extending its chaining and adapting its policies

These are proper strategies that fine tune federations so that they work the way they are intended.

The role of this specification is not to prevent bad federation setups, nor it is the role of this specification to fix it in the available protocols. Doing so will impose unrealistic complexity on chain validation algorithms. It is complex as it is.

I predict that the only entities that will actually do this kind och chain validation are the resolvers and not the peers.

[peppelinux]

See this proposal: #86

[selfissued]

This resonates with me:

The role of this specification is not to prevent bad federation setups, nor it is the role of this specification to fix it in the available protocols. Doing so will impose unrealistic complexity on chain validation algorithms.

I think the remaining question before us is whether to say anything in the spec as implementation guidance along the lines that @Razumain suggests. Thoughts?