TIIME 2015 Session 14: OIDC federation

Convener: Roland Hedberg

Abstract: Discussion of two mayor problems connected to the issue: client registration and reliance on the WEB PKI.

Tags: OIDC, federation

Notes

2 major problems:

1^st Problem- Client registration (it is either completely static, or it is dynamic)

• Dynamic: you're registering someone you don't know anything about
• You want to be somewhere in between dynamic and static -- how would you do that?

SOFTWARE STATEMENT (SS)

The owner of the RP sends some necessary client information and key information, what happens is that the owner sends this information to the federation who signs it and sends it back, so when the RP does a client registration it includes the software statement and the OP can check if it’s correct.

• This would place you somewhere between static and dynamic; you could also imagine that the owner is a big company and by using SS can spin up as many RP as they want.
• Appealing: would be easy for relying party to start up in a B2B way, - could it be signed by different federations as well? - Yes
• RP and OP have to trust each other? - Yes - the same mechanism works for both RP and OP
• How could login procedure look like - fed A logs in to fed B? - this is still in the conveners head, we haven't tried it yet.

Thought about approach of one file that lists all participant of federation?

• Discussed in the Kantara OTTO working group, there is a discovery protocol where you do that, connecting, it is basically asked on the user entering some kind of identifier
• Federation could also collect these kind of information, has some kind of interface (MDX) for distributing the information.
• Federation must have a relationship to every RP and OP it will sign a SS.

Next steps, going to work with open ID foundation and other standards bodies?

- Yes, this idea is based on one RFC, a couple of existing internet-drafts. But we will also have to write some new specifications that probably will be submitted to IETF

2^nd Problem - reliance on the WEB PKI

Now you go to web pages and you have to trust the certificates and the SSL software.

Question to get rid of PKI? -- No solution, if this is broken than everything is.

• Now you go to URL and behind is that JSON document
• Instead: URL and you get JWS, signed document
• That ID that I have, again we use the software statement

Q: Would be similar for how it is today?

• Yes, it's all in the details, but pretty simple, you could use FTP/email for distribution of the information because you could verify the signature.
• Discussions: when you publish this parameter jwt url, we have to add a new parameter jwt urlsign.

Q: Outside of fed, it wouldn’t make much sense?

Given that you have these 2 options, we also would have to have something that singles that (jwt urlsign).

Google as a fed by itself, probably they could use that as well?

- Legal, standard documents

I’d like someone to look at it (participants from Tiime), also maybe use it in their federations

Would be easy for some feds today, cause there is SAML IDP/SP fed today u can set up these proxy, u can start testing these things (ie. mobile applications, getting a specific OP software)

Q: Where to find all the software statements?

- A group is working with mobile operators, and they have a similar idea / were all allowed to talk to the mobile operator / telephone as an RP, u can use any machine as an RP

Q: Is there any kind of filter?

- 3 different telephone numbers connected to one person (i.e. 3 different SIM card, you cannot go by the information alone, you still have to do authentication.

Concern: data protection?

   - You don’t have to use it, if you don’t want to. There is no standard way for doing it otherwise.

Q: MDX already running, you could leverage that infrastructure to do discovery that isn't based on email or ePPN.

- Yes ... you would need to add some query parameters to query on IDP displayName, entity category support, etc. (talk to Ian Young about this)

Q: Would work only for limited number of IDPs?

- no, but we may see a collapse of feds, we'll see more fed's / if this system allows for more dynamics, people with same interest will be constructing more of these fed's

Q: Is it sustainable, where federations connect at the same time?

- When you look at the policies behind fed, they are not going to change that.

Should consider talking to Marina (GÉANT Federation as a Service) and Janusz from HeaNet about getting support for this into Jagger, and then into FaaS to kind of slipstream support into the community.

Q: did u already experiment with open ID connect code?

A: there isn’t software enough, we are still working on it.

- Participant: in University of Chicago, there was (we) made a successful testing unit

Solving the chicken-and-egg problem with trusting the key that signs the JSON software statement:

Use a private signing key that signs keys that actually sign the software statements, then you can do key rotation on the keys that are doing the direct software statement JWS.