OIDC FED

OIDC Federation (OpenID Connect Federation)

Day/Session:Tuesday 5H

Convener:Roland Hedberg

Notes-taker(s): Nick Roy

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

OIDC Federation - Conveying trust via a federation in OpenID Connect

Entity statement - a JWT that contains iss, sub, iat, exp, but added to that we have metadata, authority_hints, jwks

Every entity has an entity_id - a URL, doesn't have to be, could be a URI, but has to be resolvable to a URL

Add a query part to the entity ID If issuer and subject are the same, you are interrogating a subject about its view of itself, using a self-signed jwks Authority hints point to superiors - organization, federation Then ask the organization about its view of the entity Then ask the federation operator about its view of the organization (n levels)

You'd ask about all entities of a specific type within that organization - common view of those from the federation's point of view. That is how you collect the trust path. Follow authority hints upwards until you hit the trust anchor. Then you go downwards again. You have the public key of the federation operator (obtained out of band). You use that to verify the signature of the FO's jwt. Inside of that, you have the public key of the organization's signing key, and you obtain that, and use that to verify the signature of the deployment.

Now you trust that nothing has tampered with the trust path.

You take the metadata stored in the jwts and you do flattening. You compare metadata at all levels - each level can only issue stuff allowed by the level above it. Cannot add anything that is not allowed by the level above it (for example cannot use elliptic curve if the federation has not allowed it). Authority hints could contain more than one - so you can get back a tree. If you are an OP and you want to know about the RP, you could, for example, get back multiple federations, and eliminate the ones that are not in your list of trusted roots.

Now we have a way of managing metadata in a way where we can handle distributing metadata in a controlled way.

When you do provider configuration discovery or client registration, the metadata is used.

For client registration, there are two different types: implicit and explicit. Implicit means that there is no registration going on between the RP and the OP. The RP will have the same metadata, disregarding what OP it's talking to. In implicit registration, you register with the federation, but you don't have to register with the OP. There doesn't have to be an RP client ID in that case. It can use the entityID as its client ID. Then the OP can traverse the trust tree to discover that the RP is a trusted client in the federation. The RP sends an authorization request, sends its entityID as its client ID, uses its private key to sign the authorization request. OP can cache all of this so it's not doing this lookup chain all the time. How long is the registration valid for? The OP will reevaluate the chain something like every 15 minutes. If something happens, say the organization is kicked out of the federation, the trust chain gets broken, then the registration just goes away. Otherwise, all the attributes of the metadata jwt have expiration times, and you have to do new metadata registration to renew the jwt/path.

There are variants of metadata:

• openid-client
• openid-provider

Those are the ones we're playing with, but already have use cases for other types of entities which may or may not have metadata.

Roland described how you could use a SCIM federation using this about a week ago.

Producer has keys, consumer has endpoints in signed metadata

Federation operator can specify that a different level can do anything it wants, by not specifying that in the jwt that it signs for the organization.

You can do stuff like baseline expectations by interrogating the clients of an organization using the federation operator's keys to access the interrogation endpoint.

You could do SIRTFI using its own federation, which would be used to define the trust path for SIRTFI organizations/entities.

Format of authority hints is a dictionary where the keys are the superiors, and the values are the trust roots. So you can eliminate trust roots you don't trust.

Mike Jones suggests calling authorities hints, just authorities

If I have conflicting things from two trust roots, what do I do?

If you an RP and an OP use different trust roots, what do I do?

Roland sees this as a problem, but Andreas does not.

Federation A might say you have to use RSA, and Federation B has to use EC

Do you just have to keep trying until you get things to work? Except that doesn't work in the browser, breaks the login flow

There has to be some signal between OP and RP that hints what trust path to use.

That hint might have to be in the authZ request from the RP to the OP.

The RP could say, "I'm in A, B, C, D" at client registration, and the OP says, "let's use B" <-- this means you need explicit registration. Andreas doesn't think this is a problem because he's not thinking of this multifederation use case, maybe?

Example of sources of conflict: HEART and IGov profiles specify which types of crypto you can use, they could be in conflict in different federations that OPs and RPs could be in.

Flattening has nothing to do with OIDC, it could be applied to any protocol

Draft 0.5 of this is an ID in the OIDF right now, and Roland is hoping to have it done by the end of the week.

Testing: GÉANT project has funding to do this, for R&E

If there are others outside R&E, for example health, it would be nice to do testing in the OIDF for multiple sectors.

Swedish K12 use case: SPs want to get continually updated on things like groups, email address, entitlements. So you want to push that info from the IdP to the SP. The K12s in Sweden chose SCIM to do this. They need to find the SCIM endpoint, and need to have the keys to sign the information that you want to send to the SP. They put all of that into the federation.

Discovery isn't in this because you don't want to couple it too tightly.

What Andreas brought into the picture was usage outside of OpenID Connect, to be able to support other protocols. Andreas' use case is OAuth stuff - Authorization Server federation.

Not changing the OIDC OP discovery stuff, we just add new claims to the metadata.

Client is a private client on a cell phone, can you have that RP have its own metadata?

You could host the client metadata somewhere else in that case. But mobile clients probably only belong to one federation, and they can just do implicit registration.

Need people to read, comment and implement this

The implementation is kind of terse, need to add examples/rationale for different choices. Hopefully will happen within the next few weeks.

Until we get several people putting eyes on this and writing code, we won't know what's missing. There are things currently left unspecified that may need to be specified

Mike Jones contributed an open issues section - one of the things that isn't in the spec is federation operator key rotation.

A cloud provider could run their own federation full of all of their tenants.

Federation represents a relationship of some kind, but different parts of a company have totally different relationships with themselves, and with parts of their customer base.