Interoperability

(Marco Leonardi)

• I am here to try to understand if we are so far from OIDC Federation. There or if there is something that could be implemented, so it’s an open discussion, as you are people working on the things and you are more informed and It’s my third time and before you gave me some useful suggestions before.
• There is a new implementation, implementer’s draft it’s called. There has been work on writing implementations. I think the libraries have been improved. There was a working implementation of this metadata. It’s going to get there, it’s still early days.
• I think in the identity python there is new one to replace the old ONDC OP library section. There already is a new one, called OIDCN point library which includes support. Specifically, for SATOSA Edu teams are in the process of writing a new OIDC from that, they have a road map with different milestones of what they want to include in the new SATOSA from that and OIDC Federation is in the last milestones. No working implementation in the next months.

Q: From your experience, is this the correct process in connection to the draft’s specifications? A: I think it will take, there’s no real alternative to it now, for now OIDC Federation will follow RP standard, which is great. The first thing needed is to have implementations that people can use and play around with. Having one implementation that people could use is not enough. What is really needed is to get Federation operators to pick it up.

Q: What is the way for any kind of sponsorship? A: Federation can pick it up, but before it happens some things need to be accomplished, so it will take a while.

Q: Summarize the specifications; metadata specifications (metadata exchange)? A: Not so much about exchanging. Specs - it won’t be big metadata files like in SAML, just a way to be able to verify trust.

• There are certain things missing, and in specs. The federation is really about how to exchange trust, its focus is not metadata. It’s about how to get the trust, so how to know whether to trust client. In SAML – done by exchanging keys. The question is how to get the trust, how to know which SPs and IPs to trust.
• Trust is required for the Federation, but metadata is necessary for the implementation.
• Trust is very specific.
• Federation is exactly that: stating this is who I am and this is who I trust.
• One question is how to express it, that’s a different approach is SAML than in OIDC but that’s done, that’s what the spec is for. From a policy point of view, a problem is issuing trust, detached from the technical discussion. If a federation operator says I’m willing to do the technical stuff to improve trust, then yes there has to be a process behind that.
• It would be nice if Federation adjust the standards so we can use them, it will give freedom in how you design your Federation.
• We have a federation for 20 years, but the problem is that you know who you want to trust but you don’t have the technology to implement it.
• Have the chance to manipulate something that will be genetic enough. Genetic – not specific for the domain. To have something that tomorrow you can expand, you can change in a way that other partners know how to do because they’re following the same processes you are.
• In terms of timing, I would not expect anything for 1.5 years more.

Q: What are the problems with the current draft? 2 years ago, it was already talked about this OIDC Federation and it was already ready 2-3 years ago. A: There was a problem 2 years ago, there was only one person writing the spec. No one was actually spending time on fixing the problems and there were a lot of inconsistencies in the spec as too little people were working on it. Last year they added new ideas, and they were working on merging the two. It’s an extensive spec that contains a lot of stuff and is difficult to read and to remove the inconsistencies takes time and there was a lack of people. In the last half a year, a lot of people from the OIDC federation have joined in and now it’s in better shape. In the end you need to start implementing things, to see where things can go wrong. Now people are doing the opposite, to write implementation based on spec. I am just a neutral observer. In the end people will start using it because they want to move away from SAML, but for time schedule I have no idea. I think for a certain time they will coexist. The question is if you want to build a new infrastructure, it makes sense to start with something else as in this stage there’s too little implementation.

• The PDI stuff you can do in SAML?
• You can do as you see fit but If you have a thousand of RPs and you want to move them around, in SAML it’s quite difficult. In SAML you always have to go via Federations.
• There is an issue with Federation. If you want to integrate Drobox or GitLab, usually there are SAML plugins but it’s easier to implement in OIDC.
• I don’t know if it’s realistic to assume that national federation will change to support all IDPs have to support all OIDC.
• it will be interesting to have metadata that will be compatible with both SAML and OIDC. Example with the Austrian government.
• We don’t need OIDC for that, but it gets complicated when you want multiple Federations to talk to each other.
• Maybe it won’t come from N-runs but from some research, getting a use case that is more realistic. One of the big things that might push this, is that you have a large number of clients that dynamically pop up and then unknown users want to improve registry while still maintaining trust. What OIDC want to do is, not just one Federation operator of clients, but delegation of trust.
• You can restrict the RPs. In SAML the use case is always…; in open id connect, use cases exists (more flexible) that once the process is done the client is also done. Dynamic registers, and dynamic ID and then the job is done, and it shuts down and you don’t need to know the client. OIDC Federation - I have department X which I trust and department X is delegated to issue OIDC Federation statements and the clients can shut them down and do whatever they like.
• And also…You have a security policy and you want somebody to sign that this time the IDP follows the recommendations.
• You can trace things, you have a chain of trust, you have traceability.
• It’s not a typical use case that you will see in the traditional era.
• You can’t do it in both dynamic and standard way.
• It’s realistic to expect it in 1.5 years. with plain open id connect you have a lot of services, but if you require to implement services and libraries for federation, that’s actually very difficult.