OpenID Connect Federation 1.0: Adds trust mark validation to the TrustChainResolver

[Yavor Vasilev]

Clarify acceptable strategies for the TM validation with the WG:

• Request to the TM validation endpoint
• Verify as JWT using the TA’s keys (if TA is TM issuer)
• Other?

‌

[Simone Avogadro]

So far (spec v26) both JWT and TM validation endpoint seem viable alternatives.
Unless the WG decides to ditch one of the two options (thus unding the underlaying work) both should be viable for library users, thus some kind of preference/validation should exist.
Althou very very old style we’d prefer a system property approach rather then forcing the use of flags on all the API calls.

BTW this doubt is very similar to the duality between using the TA’s resolve endpoint and the full chain validation

[Yavor Vasilev]

@Simone Avogadro Thanks for the feedback!

In your case, who is going to be issuing the trust marks?

We think that, if the trust anchor is going to be issuing them (and not some other entity), then to save the look up via HTTP a validation using the anchor’s keys will be way more efficient. Because the anchor’s keys will be readily available.

Regarding sys props, the library has a contract not to use such, and have everything done via its APIs.

[Simone Avogadro]

In our scenario both the TA and some other entities will be issuing TMs. Moreover we’d go for the validation endpoint since the TMs might be long-lasting and might have been revoked (thus the signature is still valid but the TM is not).

As for the properties I get the point and we can surely adapt to that.

[Yavor Vasilev]

Good to know this. The signature check was so appealing

BTW, when you receive TMs, how will you determine which TM to verify and which not?

Are you going to be trusting the trust_marks_issuers from the trust anchor statement?

[Simone Avogadro]

Our policy basically is:

• TA can issue whatever TM he sees fit
• intermediates can only issue TMs according to trust_marks_issuers claim

p.s.: the duality between signatue check and introspection endpoints is spreading in the OIDC landscape but it’s always been there and we’ll probably have to deal with that as long as large corporates keep fighting over it. IMHO signed statements are a way to rebuild in OIDC what we already had in SAML2, whereas endpoints represent an always-connected/always-public/low-latency view of the internet which is not yet real

‌

[Yavor Vasilev]

A ticket was opened with the OIDC Federation spec. The responses show that both validation methods are technically OK. But which one to choose and when - this depends on what the TM is about, i.e. on federation specific configuration.

https://bitbucket.org/openid/connect/issues/1791/federation-address-gaps-and

We were also wrong to think that the TM checking is part of the trust chain validation. It turns out it must be seen as an independent “add on” (with a caveat explained next). This means the plan to add this to the TrustChainResolver is probably wrong too. However it will be nice for the SDK to have a way to stop the TrustChainResolver from continuing if a required federation specific TM to “green-light” the resolution is missing.

[Simone Avogadro]

Functionally speaking decoupling the TM validation and the TrustChain validation surely makes sense, however functionally speaking I can’t imagine any client willing to use the TMs from the chain is they are not validates, thus probably some kind of “do it all” utility methods may make sense.

As you hint there are two point which clients will probably want to have:

• a shortlist of “required” TMs for purpose (e.g. is this a recognised RP?)
• know which TMs are valid respect to the trustchain (man maybe remove the invalid ones so that the remaining information is actually all usable and trusted)

probably the first point can be forfeit and replaced with a check after the second one is executed (e.g out of the remaining, validated, TMs is the XXX one present?)

The choice from the WG to trust a chain which might contain forget TMs poses implementation risks and surely might arise some concerns on how to avoid the lib users expecting it to happen (probably a clear statment in the TC validation methods which point to separate methods to purge untrusted TMs)