(Pieter van der Meulen)
Pieter: We have a federation operator and strong authentication solutions. We asked to design a process that is executed by our members for vetting the second factor and linking it to the ID of their own institution. It was a lot of effort to read through all the standards and explaining to all institutions what to do and how to cope with the process. They all have their existing processes and their own notifying process to make it easier. What I am looking for is experience, help in this regard, what works and what not. The registration part is the hardest part always of such a process in my experience. The technical part can be solved quickly. Making decisions, dealing with risk management and establishing the process should be the most complex part of it.
The registration part of the user is always the first part solved. What happens then after if the user is not logging in anymore, if they are reluctant, if there are security issues? There it gets fuzzy already. We self-access the processes by a voluntary audit program. To join our federations, the IdPs need to comply with certain conditions, guidelines.
At SurfNet we handout second factor authentication devices through the users and we link them to the accounts of the university - that is how I became the owner of an identity management process. It is a distributed process. Each university handles their own users - that is how our federation works. All the mini authentication systems are then connected to make one bigger system.
Edith: In the enterprise environments it is quite a clear process. In federations this is harder to manage since each IdP handles their own identity management. How would this design be drafted from scratch?
Pieter: in an ideal world - because of it being a distributed process I don’t want to impose the local registration authorities - the people who handle all the process tasks that need human intervention. I like the idea of self-assessment and peer review. It keeps the quality up and has to be done regularly. One of the things we did was to ask the RA to enter the last digits of the ID documents, in order to have an overview and make checks on these documents. You can also ask a few users for what ID document they used and match it with the regulations in place.
Edith1: It cannot be checked though. It can remain in the system forever once you have put in the data. This can be checked with dummy data for example.
Marco L.: In a university the level of assurance for the user’s data is quite high. The process is more secure already. In our scenario we are currently rebuilding the ID management infrastructure. For most of them the level of assurance is quite low - example for accounting purposes. Since we are making it now from scratch it would be good to understand the correct process to put in place - like provisioning etc. The context of the European Space Agency - there is HR who registers users in the main DB. This matches with the AR regulations. Users have a right to this data - satellite data.
Pieter: The basic problem you are solving here is Identity of the users that you have registered from the users in the system - in your case a self-assured ID, not connected to some government issued ID.
Ian N.: If the information is freely available why do you ask people to register at all?
Marco: For purposes of accounting and controlling user activities. To monitor users and take decisions on how to provision users to this user. We additionally have another process next to the self-assured registration to give the users more specific services.
Pieter: what you want to do is link the ID to a real person in this case. the reason is to avoid denying access to a self-assured ID from your system if someone misbehaves, but you want to deny access to the real person behind it.
Marco: the process we have now is just for increasing the trust for certain users. it starts from self-registration but then to access certain specific data you have a more complex registration. this is a process that normally for a university is the main one. what I want to know are what are the best practices to implement this from the beginning?
Pieter: very good start are the NIST standards - the controls in there apply to authentication. if you want to link this self-given ID to the user, it is already a form of authentication. The total strength of your authentication depends on the weakest link between the ID-user link. What you should do in the process is establish the link properly since the beginning. What we do is we bring all of them together: User registration: from low level auth devices —-> to OTP Two-factor authentication: Mobile code or mobile application or some other second factor.
The authentication part is solved now. We then go to the RA, where we bring the 2-factor authentication, the OTP, the ID document and yourself. There you prove the user is able to register with this 2factor auth. There you have everything together – the user, the ID and the proof of successful 2 factor authentication. The authentication framework should aim for what the quality of the above links is – how strong is the authentication.
As a designer of a process there are a lot of choices to make in this regard. It turns into a creative design process. How high are the costs? How well does it scale? How high is the usability? What resources are needed? It is hard to know the consequences beforehand – what are the good practices in different scenarios. This kind of guidance is not part of the standards available and for good reasons – the variety is too high.
Marek: There is the example of Monzo Bank – they ask for a form of ID with picture such as a driver license. They confirm it and then they create your account and then you have the authentication available. You do not have the password though, only a token in your mobile device. You then receive the bank card to the registered address, which you have to then register in this same mobile device. The control of the information here is multi-level.
Peter: it is not immediate though and it does not sound very user friendly.
Marek: can you use e-ID as a federated ID, or you need approval from the gov?
Pieter: Typically, it is allowed but some bank id providers for example prohibit it to earn from the authentication of their users. In the ESA the use of e-ID can be a very good solution and not overly expensive. In case of a double nationality though you would have two e-IDs. The question is always which kind of information these e-IDs share and what properties do I need for my authentication process? The NIST standards are again helpful here because it lists all the requirements and you can check which properties apply and which ones do not apply to your case.
Marco: is it typical to have organizations federated with the e-ID infrastructure?
Not really. Some countries do not even have the e-ID and the setup of the infrastructure there is not the most transparent.
NIST SP800-63 is a great starting point for the standards and drafting any kind of this process from scratch.
