Convener: Roland Hedberg
Abstract: Discussion of two mayor problems connected to the issue: client registration and reliance on the WEB PKI.
Tags: OIDC, federation
2 major problems:
1st Problem- Client registration (it is either completely static, or it is dynamic)
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.
Thought about approach of one file that lists all participant of federation?
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
2nd 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.
Q: Would be similar for how it is today?
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.