[Openid-specs-ab] OpenID Connect Federation draft 09 ready for your review

[Marcos Sanz]

Hi Roland,

> > I've been thinking about this conglomerate of issues and it'd be 
actually 
> > easier if the TA self-signed statement were *not* part of the chain: 
the 
> > Consumer should be configured with the TA's name (the issuer URI) and 
TA 
> > public key, and it could stop walking up the chain once it finds an ES 

> > whose iss and signature match these two configured values.
> 
> When how to get self-signed information became different from how to 
> get information about an entity from another entity then the TA's 
self-signed
> statement was removed from the trust chain. This may not have been 
spelled out 
> clearly enough.

ok, I see. Simmilarly to what RFC 5280 does, though, I'd expect the 
Consumer to be explicitly configured with both, the TA-identifier and its 
public key, and not only the latter like the document currently does (at 
least, that's what it looks to me).

> > The second thing, which is less of a recommendation but more a 
question on 
> > how to deal with this in the JWT trust chain, is the good practice of 
> > validating 'iss' in JWTs (s. for instance the "MUST" wording in 
> > https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-07#section-3.8). 
That 
> > soon-to-become-RFC showcases OIDC doing this via the jwks_uri 
mechanism to 
> > dynamically dig issuer public keys for verification. However, we don't 

> > resort to that mechanism at all in the Federations spec: the chain 
> > validator has to blindly believe the keys in the jwks element of the 
upper 
> > chain link. So it's unclear to me whether this key-to-issuer-binding 
is 
> > being neglected at the moment in our trust chain.
> 
> Well, it all starts with the TA. If you don’t trust the TA then you’re 
smoked.
> The Federation spec hinges on the fact that you do trust the TA.

I see it exactly the other way round: you start with a self-signed leaf 
statement and you walk your way up the trust chain via auth_hints *hoping 
to find* a TA. But until you do so (if you do so!), everything on the 
journey is not to be trusted and a potential attack vector. For instance: 
I am scared about rogue intermediate FEs that publish ESs via their 
federation API endpoint with fake issuers and keys that do not relate to 
them whatsoever (it's true that the problem would remain compartmentalized 
with the JWT typing we are introducing further down, but still).

While inspecting the workflow anew under this light I found out that it'd 
be important to add in 6.1.2 the requirement for the Consumer to verify 
that iss and sub of the ES response MUST match the values of the 
respective query parameter. In case the query had no sub query parameter, 
the consumer MUST verify that iss = sub.

> > Finally, and talking about the jwks element: the Federations spec says 

> > "keys that can be found here are primarily intended to sign entity 
> > statements and should not be used in other protocols". While reading 
that 
> > I was reminded of the aforementioned JWT-BCP's recommendation "Use 
> > different keys for different kinds of JWTs. Then the keys used to 
validate 
> > one kind of JWT will fail to validate other kind of JWTs", which is 
good. 
> > And then I realized that Federations is not using explicit JWT typing, 

> > though it is RECOMMENDED for new uses of JWTs (and Entity Statements 
are 
> > such). So I think we're still in time to include that.
> 
> Good idea!

Great! Looking forward to that.

Best,
Marcos