(Thomas Barton)
Distinguished Engineer Program
Thomas: Heather and I are very involved in REFEDS. How can this plan of work (link above) made and they are proposed by the community? Everyone can add ideas. There are discussions, those that tend to be most popular is what is proposed by the people. Participate!
Pieter: Many years ago, I exchanged experiences with a colleague from France, we came to a few tech details and it occurred that we should salvage channels where we can easily exchange results, in a form that is easily accessible to others. Something that will establish best practices. That never happened. The list exists. There were few useful discussions. With this list we discovered what is useful and could get the best results from. In order to encourage the open exchange, is a very closed forum. Two members must vouch for a new member, a secret handshake thing. Difficult for any who haven’t met any of us. Everything can be discussed in the group.
Thomas: The openID foundation, identifying the use cases of openIDconnect, and there’s a lot of OIDC related stuff across the R&E sector. The capstone of that is to coordinate lieus. It has had some other ones over time. Is anyone in some of these groups?
David: It’s not really active yet. It’s quite fresh. Thomas: This is the solution.
Pieter: I get the question, but I don’t know if anything needs to be changed to establish OIDC and SAML.
Peter: there is the third-party trust. That has been worked on in other forums. Without a lot of discussion.
Thomas: This list is for trying some stuff out. In reality, it’s a placeholder for others for what they want to do with OIDC. I don’t imagine it’s going to stay in R&E, in needs to be done everywhere.
David: Where you need a modified exchange token for OAuth2 to cross. Complements exist but something that is unique to R&E. T: SIRTFI
Heather: SIRTFI, is adding some contact information to the metadata SSO that if there is a security incident, and you can contact someone about it and ask them what is going on???
T: How to be ready when a security incident happens in a federation? There has been the existing certifying body at work and the current focus is how to put that together across federations. That’s the focus for this year, to finish that work.
Pieter: It’s always been a problem, to find the people that do that work. Observing the needs vs having the hands or the time to contribute to it.
Heather: It’s a volunteer community and a lot of same people volunteer and work on it.
Peter: Happiness about SIRTFI is not universal, the acronym cert is not able to understand a lot of things. I think the furthest to go is to provide security, the single university is Austria can’t claim Sirtfi. It’s not the success story yet but we wish it would become.
T: We have taken note of that.
It looks like it’s scoped for federation operators.
Peter: Operator isn’t involved, but the workplan is. Phase 3 is improving the standards from phase 1, and there ought to be a phase 4. Leif and I agreed, there is value in the phase 4. Have better data and better responsibility.
Pieter: What do you mean, proactive detection of issues?
Thomas: Most could share the compromise for the issue with others so that they know how to address how to operate
P: Sharing of security incidents.
T: It could just be a stream of account management events. It’s a bunch of things that is normal activity. You might have a correlation between streams.
P: Inside of a university I can see it happening but not outside of it.
Pi: CERT does incident reports. There is a problem and you could be doing it because all of your data passes through your ap. It is at least not the traditional roll of the cert.
P: But our federation prevents it by design.
Pi: Make SIRTFI work on the base level, like how incidents work for network events. Most are not actively gathering data for the institutions.
P: It should be fine as you have authenticated individuals while in Africa it can be from 30 different countries.
IDP of last resource H: This is interesting because it came out with good output 2 years ago and it keeps struggling with finalizing everything. There is work to do but getting the right chair seems to be a key struggle.
I tried using different IDPs and I couldn’t find the united ID, they are too complicated, if I am onboarding somebody, I need to do it fast, if I need to go through so many things it’s going to take so long, and I will lose them by then.
P: It allows only multi-factor auth.
Heather: Why is this a REFEDS thing you asked, there are a lot of bad ways you can implement this. Can we at least have a saying, consistent model if you have to do this.
I don’t think you can do it at that level, some are going to need MFA, some don’t care.
T: How is that different from a regular IDP? People represented by their IDP go to different SPs for their needs. An IDP that can support any of them. P: It becomes a REFEDS issue because IDPs share knowledge.
To do this right you would have to serve SPs, a lot of times why I need one is because they failed in their ability to enroll in their IDP. Most of the time they don’t have one because they are in Africa. And you are saying that the IDP has an API that I can provision my users into it and to onboard them onto the project.
T: Entity Category Support: Dealing with exchanges that deal in R&S. This is listed under working group but never existed as one. We will get together on that. We did two revisions on the R&S. There is a deployment profile as well. Last one is the future federation trust 2.0
P: There was an organized or individual, federation members to go to the underdeveloped countries in Africa to help them with their federations.
There was a lot of improvement seen in the federations of Asia compared to South America which still seems like an isolated island. There is still a gap there. Some of the solutions that they picked were very alien to our mindset.
P: They would have an IDP and still use Google as the IDP.
