WAYF supports MFA and everything else of the kind

WAYF enables IT users in an organisation to access services outside the organisation with the login they use for the organisation's internal systems. This provides a number of advantages for the users' organisation, the users themselves and the providers of the external services.

It works like this: The organisation sends the external service some pieces of information about the user upon her completion of logging in. Based on these, the service then assesses what kind of access to give the user – it can, for example, look at whether she is a student or employee, how old she is, or whether she has a specific user ID. These kinds of attributes are well-known access criteria for login-protected online services.

An additional criterion on the rise is how much confidence one can have that the person trying to get access is the right one: What did the organisation do to ensure that the login was initially delivered to the intended person – and which of the login means given to her by the organisation on that occasion (e.g. password, phone app, etc.) did she use in the login she just completed? The former determines how confident the service provider can be that the login was in the hands of the right person to begin with, the latter how confident he can be that it still is.

Some services require, for instance, that the user logs into his organisation with two “factors” – typically with something the user knows (a password) and something she has (e.g. her phone). Some services may have more detailed requirements for the “factors”, e.g. that one of them be a certain kind of hardware key. This kind of requirement makes it more difficult to steal the login and so gives the service providers the confidence they have deemed necessary that the user seeking access is the person to whom the organisation issued the login originally. But the service providers could also have a requirement that the organisation e.g. checked the user's passport or baptismal certificate to a certain extent before the login was handed to her. And that gives them the confidence they deem necessary that the user knocking on the service's door is who the organisation believed she was at the time of login issuance.

This kind of information about “login quality” increasingly is requested by service providers – they want, depending on what they're giving access to, to be sure who's logging in. Unfortunately, today there is no widespread standard for how to describe and denote the quality of a login – different environments or communities partly have their own definitions and their own designations for them. But the technical standard for the actual exchange of this kind of information is already in place – and WAYF fully implements it. In other words: If a service provider and a user organisation also implement the standard and in addition “simply” agree among themselves on how to designate e.g. that the user is logged in with several factors (“MFA”), then WAYF does not prevent them from communicating about the matter – but rather facilitates their doing so. A service can, for instance, ask the user organisation to require MFA from the user who wants to log in; and the organisation can then inform the service whether the user actually did log in with MFA – with WAYF in the middle. In this way, WAYF supports MFA – and all other login methods and identity assurance levels in, or ever coming into, existence.

At the more technical level, the service provider has the option to specify the required login quality in the element RequestedAuthnContext either in the metadata at WAYF or in the login request the service sends to the user's organisation when she tries to log in. In the login responses the service receives, the user organisations, correspondingly, can indicate in the element AuthnContext or in the attribute eduPersonAssurance the quality of the completed login. For instance, the value http://schemas.microsoft.com/claims/multipleauthn in RequestedAuthnContext will trigger Microsoft's brand of MFA when the login request is sent to user organisations that use ADFS or AzureAD for its login software. Another example is the value https://data.gov.dk/concept/core/nsis/loa/High, which in the context of Danish public-sector systems indicates (roughly speaking) that the user must have upgraded his MitID at a municipal Citizen Service office and can only use his login with a special key present on his device. In both cases, the achieved login quality will ideally appear as a value of the attribute eduPersonAssurance – which the receiving service can then inspect and use in its access decision in line with the other attributes of the login response. The service generally should check the quality of the login response – since it is possible that the user organisation's response has a different quality than that requested or otherwise required by the service.

Only it's impractical that concepts like MFA have no standardised designation across services and user organisations. This means the service must know the individual user organisation's “name” for e.g. MFA to be able to request MFA from it. But here WAYF, as a stepping stone between services and organisations' login systems, has the potential to add value – i.e. by accepting one and the same designation for MFA from all services and then “translating” this into the term the user's organisation has for it. An obvious candidate for such a standardised “name” for MFA is perhaps the one REFEDS uses for its definition of the concept – which probably corresponds to most people's expectations of what “MFA” implies. So the services will be able to request MFA from any user organisation in WAYF simply by specifying the value https://refeds.org/profile/mfa in RequestedAuthnContext. In this scenario, the organisations would also support that REFEDS standard without having to change their setups – which in several cases cannot even be changed in that regard. WAYF's “translation” of signifiers for login quality has not yet been implemented – primarily due to it being relatively complex to process the relevant information in the user organisations' login responses.

As indicated, there are already quite a few definitions and designations for various login qualities out there. However, only a subset of these can be requested by the service providers from the user organisations in the RequestedAuthnContext – and mostly designations for how the login itself is performed (e.g. with MFA or password only), not so much designations for how the user was registered with the organisation. The other values – typically with content such as “the user showed his passport when issued his login” – the user organisations send “unsolicitedly” in the eduPersonAssurance attribute. For a long time it has actually been mandatory for WAYF user organisations to indicate the quality of the login with the value 1, 2 or 3 in eduPersonAssurance – according to the old standard NIST 800-63-2. But over the years, more frameworks have appeared, with more definitions and values. The new NIST-800-63-3 doesn't define values for use at the technical level; but this is the case with e.g. the Danish NSIS, used in connection with the new Danish public-sector login, and with the closely related EU standard eIDAS . The most common values in login resposes – with urn: … :PasswordProtectedTransport probably the top scorer – originated from an early attempt to define a set of login  qualities in the community that developed the login technology itself. Of particular and growing relevance to service providers and user organisations in WAYF is the REFEDS Assurance Framework, tailored to needs established in the international research and education sector.

Of the login qualities that the services typically can request from the user organisations, MFA is probably the most popular one – because it is perceived as far more difficult to steal an MFA login than a login with e.g. a password alone. But this is not always so. If, when creating the user, the organisation only gives her the password and allows her to register the second factor herself at a later time on the basis of the password – then there is a risk that a thief having stolen the password can register the second factor and thereby gain access to MFA-protected resources. That risk grows the more time the organisation allows between login creation and the user self-registering the second factor. And the problem is not only theoretical – major IT landscapes in Denmark have been compromised due to precisely that weakness in the organisation's management of login means. In fact, REFEDS' current definition of MFA corresponds to this less secure version of the concept – and so, the designation https://refeds.org/profile/mfa doesn't promise the receiving service provider more than the login being statistically more secure than a password-only login. It could be relevant, then, to introduce, alongside “REFEDS-MFA”, a special term for “safe MFA” – i.e., MFA without a self-registered second factor – if WAYF's service providers deem this difference in quality relevant in their risk assessments. And similarly with other login qualities the service providers may need: WAYF would be able to define terms for them and, as described above, be able to “translate” these into what they correspond to in each user organisation's login system. The Danish governmental citizens' login is an example of a “user organisation” that can deliver “safe MFA”.

But as shown, WAYF already supports MFA – and everything else of the kind. To exactly the same extent as the connected services and user organisations do: These are free to communicate about login quality through WAYF, in accordance with the established technical standard.