Progressive Authentication

Full Title or Meme

When the exact nature of the user request is unknown, it is best to try Authentication in the least obtrusive manner, which is typically not at the highest level they might need later in the interchange.

Context

The general use case is where trust elevation will occur at some time during a long term engagement, as when a user first goes to a site to get information, investigates the options and then decides to commit to a service offering that requires stronger identity in order to qualify for access to some resource, such as a state sponsored benefit.

An anti-use case was discovered when the NSA funded the Blacker System which attempted to use Mandatory Access Control with the Bell-LaPadula model for computer networking. Development started in 1984, it was certified in 1991. It became clear that security was given such precedence over usability that soldiers in the field would be forced to authenticate to their devices before they could talk on them. It was obvious when tested that no one had bothered to ask if this user experience was acceptable to a soldier in the field. The cautionary tale here is that following a set of rules created without thought of user experience is unlikely to ever be deployable.

When mobile devices became common it was early realized that any solution forcing a single mode of authentication was not feasible and progressive authentication was proposed for mobile devices and later specifically for Android devices.

An alternative definition of progressive authentication is a suite of authentication tests which can be selected to be run at a single time with a Trust Vector that can be tested by the authorization service. While this does provide some flexibility, it still presumes that required level of authentication be known at initial connection. This might work for systems that are wholly risk based with a captive audience, but will not work for users who have any choice in the selection of their providers.

Problems

NIST is now in the third update to their Digital Identity Guidelines where they still insist, at least for government purposes, that "digital identity is the unique representation of a subject engaged in an online transaction." But it is a fact, acknowledged in that publication, that users will have different personas, for example, for email versus banking, if not for various interaction with the government. Imposition of privacy obligations makes it clear that users must not be expected to offer detailed attributes of their life which are not needed for the transaction at hand, so there can be no expectation that any online representation of a user is anything other that what they are willing to release. While any Relying Party may insist on a high level of assurance as to the validity of the attributes provided by the user, in most cases those parties are willing to accept whatever assurances the user may offer, or the user will just go elsewhere. This need for multiple personas should not be considered as any reason to ignore the current NIST publications. As of May 2018 these publications are still the best available benchmark for authenticating users on the internet. Still it is time for industry to acknowledge their needs and the privacy regulations require more flexibility.

Security versus usability seems to always create the most intractable difficulties. Consider the issue of creating a connection between two system with minimal security, and then upgrading the level of security by adding additional authentication factors. If an attacker has been able to compromise the initial connection, they will be able to see the upgrade and "follow" the user to the next higher security level.

Solutions

The best solution is one that asks the user only for sufficient attributes to complete the simplest tasks on the relying party web site. As more verification of the user's trustworthiness are required because of the user's request to access protected information, the authentication of the user can progress as those desire of the user are made known.

The following is one such use case with a time line about how that user interaction might progress and the problems that could ensue:

1. The user contacts the web site to determine if that is the service that will meet their needs.
   1. The user may be given the option to provide some means of payment or authorization and remain otherwise anonymous with no continuity from one interchange to the next.
2. When the user determines that the site is appropriate and that a connection that survives from one interchange to the next, some registration process is required.
   1. The most basic form of registration requires that the user select a user-name, a means of authentication and a means to recover access if lost for any reason. The only personal information required is in the contact data.
   2. An alternate if for the user to have the option to select one of the various social networks (Google, Microsoft, Facebook, etc.) to provide authentication as well as a anonymized user name, possibly non-trackable.
   3. At this point the user can sign into the web site whenever it is wished and the potential for tracking is limited to the
   4. At a protocol level the user has two or three claims in the authorization request:an anonymized user-name and some means to contact the user when required by future events, such as a breach.
3. Access to more privileged parts of the site may require the user to enter additional authentication in the form of either: (1) a payment card, (2) an additional authentication factor, either of which provide more assurance.
   1. At a protocol level the user just as more claims that can be collected for use in an authorization request, most of which will be consider to be personal information.
   2. But any progression to higher levels of security cannot continue any network connection that might be compromised. But user experience would insist that continuity of connections is the best UX. Solutions might be:
      1. Network security must be established at the beginning of a session and maintained throughout the entire interchange, or
      2. The network connection must be re-established every time the user moves to a higher security level without the user be unduly challenged.