(Niels van Dijk)
All including solution for delivering researcher identity to researcher services requirements and services.
There is a proposal made at TechEx recently in New Orleans to try and resolve some of the issues that researches are going to have with access management, especially with authentications. In the authentications area, there is a problem because institutions have to release attributes so that collaboration uses stuff about the user and it was difficult to get that. It has been tried for many years to address this. There is an alternative proposal called researcher ID (RID) and this name has legal issues which are a minor problem.
The idea of RID is to enable the researcher to always be able to login to a service by providing proxy service that would either leverage federated identity from institutions for that we know they are capable of providing correct information. If it does not work for whatever reason there would be fall back IDP which would allow continuing to progress and continue to use the service.
We need one identifier which would be used by researchers.
What is being generated by RID is a persistent identifier for a user regardless of what backend system was used to have actual authentication. Should the user move between campuses or should he have no capability of using campus, this would always be a usable set of integration. See photo at https://imgur.com/GBNYrkD.
It seems to me that the chief activity of providers of this service would be to work with different campus IDPs that are not working properly as they need to.
I think the fact that many, many dysfunctional institutional IDPs is definitely as important as the concept of having a persistent identifier.
In a proposal page there is a list of things, see https://imgur.com/MaGLty2. Q: I have got an email from somebody who is running research community in Switzerland and his point was that organization of federation is really critical. A: Indeed the actual institution of federation is actually more important than all the rest of attributes. Federation is critical. In this scenario, the challenge would be how to deal with fall back IDP. From the graph, there are some components between DSP and IDP. Then comes the question, if we move everything but DSP and IDP, the unsolved problem remains. Is the idea that this is the one user portal that everyone should go to?
Q: Is this a proxy? A: I am more assuming at this point that this will be a dependency. The user typically starts by logging in from some of the IDP. It could be done by saying in UI that this method is not possible so please use this alternative scenario… until user logs in.
The best way would actually be if user would not understand what is happening.
On-boarding process: You have to generate or associate the research map. Of course, you can generate an arbitrary identifier. It would actually make sense to have ISO i40 either generated or you import one that you already own.
One of the critical points for this solution is, whatever identifier we come up with, it has to be portable in some way. That is one of the main issues we are currently facing.
It has to be something really portable. It could be the SNI format but… It can be asserted by other IP. We wanted to make the thing to be removable. If any IDP in the world can impersonate my identifier, I have just widened the attack area. You just need to hack any of the IDPs. What happens if an ADP in EduGAIN gets hacked to certify the background? Now you can have any of the IDPs in any of the federations EduGAIN and still assert a specific identifier for a specific person in a specific institution which is not possible due to scope protection that we have. It would take a bit longer via fishing but…
Q: How many identifiers one individual could be allowed to express? Is there one to one relationship between researchers and identifier or it can be more identifiers to one researcher? A: You can never prevent a user from generating more than one identifier. Even in a single centralized system it is extremely hard to have B uniqueness, so it does not guaranty that each person gets one identifier. So rather let us talk about everything else except identifier.
Q: Who would be trusted enough to run that thing? It could be done on a national level for example. It could be used everywhere. Who should run might be answered later on when we better understand it.
Q. Why it should be single identifier? A: That would be multi-party federation. Geographic area would be the criteria what proxy should be used. Things can get very complex. We need to keep idea of portability in mind.
Q: How far can we get if we just start fixing stuff in centralized world? Can it be solved in parallel? How much do we need to solve this complex technical problem? A: I don’t think you can take that as peace out of that process. You need access to the logs. I do not think these things should be solved in parallel. Things should be solved once and propagated to other. Having this centralized function helps a lot. It comes back again to who is operating it because there are so many little pieces.
None of us can predict how things are going to move in next few years, but we should try different things and move forward. Should we do the central solution bed or central support or both?
Most communities I know would consider using this and would be happy with this.
Many or some of the communities have already got this in place and I am not sure if they would go through this again if they already have it, why would they switch to it? I think very few communities are using it now… This means we also need to consider some migration scenario for those that already have their own implementation.
