Open ID Connect Federation BoF

OpenID Connect Federation BoF

Tuesday 3M

Convener(s): Roland Hedberg, Mike Jones

Notes-taker(s): Nick Roy

Tags for the session - technology discussed/ideas considered:

 

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Interpreting the policy language has to be 100% deterministic and water-tight, or you will have big problems.

If you evaluate the chain of policies, can you have places where you throw an error, or will you always return a result?

Sometimes throwing an exception allows you to detect problems, not always best to ignore conflicting statements. Some times they meant something else, and if you don't throw an exception, they'll never know. This is where the "MAY" comes in about informing you what's going on. An exception should never carr meaning, it should purely be for debugging.

Major change that was made recently: .well-known URLs are supposed to point to configuration, not API endpoints. Depends on your definition of API endpoints, but OK. OIDC uses this to get the config, and from that a number of endpoints. The change that was made made the profile more aligned with how OIDC core does this. 

If you are interrogating an entity for its view of itself, you use .well-known. If you want to know someone else's opinion of an entity, you use the federation API. Went from a one-step, to a two-step. Eventually you will cache the results.

With the change in place, what is the data structure that you retrieve at the .well-known URL? A signed entity statement. Doing this split into two allows you to have different endpoints. Lets you put the federation API on a different domain/etc.

A number of other changes, one change was authority hints. A pointer to a superior, but coupled to that, info about where you would end up if you talked to that superior and kept climbing up the list. Comment: How would the leaf know anything about what's above it? The reason authority works in X.509 is that we don't play around with self-signed, use whatever the CA gives us. In this case, we are using our self-signed statement, and we are using the CA as an added feature. There's no way to feed the CA path back into the self-signed construct. 

Trying to put information in a data structure that's not reliable is not reliable.

Apart from that things that have come up lately are constraints- trust anchor constraints, for example: "You can only have 2 intermediates, or zero intermediates." Another: Naming constraints - entityID. Might not be used that much by the trust anchor, but by would be used by intermediates. Path depth restriction helps you as an FO restrict behavior that you're not vouching to by, say, allowing zero intermediates.

Key duration and rollover: I require my subordinates to issue statements with validity no greater than t timespan (say, one day).

Idea is that the validity window of any subordinate statement has to be less than the parent.

Without a flexible enough policy language in the implementation profile, you can't support it in practice using a deployment profile intended to inform how to build a real federation.

Key rollover for FOs is already suported by just creating a new trust path with the new key and keeping the old one around for some period of time.

The thing you are issuing can't be valid longer than the thing you're signing it with.

Mike is going to review the current draft and make suggestions. What of the rest of the stuff is checked in? Max path and naming constraints are checked in. Max validity is not, but could be easy to check in if it's needed. That is non-breaking if you ignore stuff you don't understand as an implementation.

What do you do when a subordinate tries to set a value that has already been set by a superior? Easiest one is you always go with what's been set by the superior. Have to think about that.

Is the policy language expressive enough? The more expressive you make the policy language, the less possible it is to implement correctly. 

Leif suggests that we do a gap analysis with PKIX, make sure that the policy language covers what's in PKIX. The fact that the web PKI is flat isn't a good argument for why we shouldn't put stuff like this into the federation spec.

Don't need to do gap analysis against SAML because this stuff doesn't exist in SAML metadata, we enforce it via federation management tools.

Having the "CA Bit" - can you issue stuff from this/path length=0 is a fundamental need.

There is a lot of cruft in PKIX that we wouldn't want to bring over. Look at it, "are we going to miss this bit when we don't have it?"

Mike suggestgs looking at this against not just what's possible in SAML metadata, but also how we deploy SAML federations using the tooling.

When they were building OIDC, one of the best things was getting feedback from the developers in Japan. We need implementations and testing of their interop.

Recruiting cross-sector implementers to attend the hackathon at TechEx in 2019.