Page History

Different registration processes and mechanisms applied to identity vetting, proofing and credentialing result in different registration assurance levels. An applicant may appear in person to register, or the applicant may register remotely.

Remote registration is limited to Levels 1 through 3 and is more vulnerable to threats and technically complex to achieve. Remote registration relies on the availability of trusted sources to cross-reference and validate the provided assertions such as name, home address, age, social security number (BSN), and photo. Examples of such sources are the institution’s HR system or the government/municipal administration (in The Netherlands: Basisregistratie Personen, BRP) Consultation of the latter source is restricted by legislation and not available for SURFconext Strong Authentication purposes; the HR system on the other hand could be used as an alternative source. Typically, after a successful validation, a registration activation code is sent to the applicant’s home address. This is cumbersome and expensive.

Therefore, in person registration seems the most efficient option. In case the user is somehow not able to register in person, video conferencing tools such as Skype or Lync could be used. In this case the user identifies him/herself via the video conference and shows his/her passport or other valid photo-ID to the registrar. The use of video conferencing tools for identification, however, has several drawbacks: it introduces scheduling overhead and it makes it harder to detect a forged ID. Other – less attractive and/or appropriate – alternatives (such as use of physical address, email & mobile phone, use of bank account).

Different circumstances may translate to different requirements. There are use cases in which a second factor authentication token without a strict registration process makes sense: Google, for example, offers second factor authentication to its users in the form of an SMS service and a smart phone OTP app, but has no face-to-face registration processes in place.

The difference between this “Google use case” and the use cases of most institutions is that Google users are protecting their own account (from, say, snooping governments) as opposed to the educational institute’s student information system use case where the IdP is protecting its organisational assets (or its reputation). In the latter case, there is a strong need to be able to determine that a service provider (e.g. a student information system) is dealing with a legitimate user, thus necessitating a stringent identity proofing process during user registration (i.e. a face-to-face process) described below.

 Dit zijn de meest gestelde vragen. Voor meer informatie kun je terecht op de wiki of bij het supporteam.