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.
Then general use case is where trust elevation will occur at some time during the a long term engagement, as when as 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.
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 user will have different personas 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.
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 few of the more common options:
- The user contacts the web site to determine if that is the service that will meet their needs.
- 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.
- 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.
- 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.
- 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.
- At this point the user can sign into the web site whenever it is wished and the potential for tracking is limited to the
- 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.
- 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.
- 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.
- But any progression to higher levels of security typically requires that any old connection be abandoned for a new one. But user experience would insist that continuity of connections is the best UX.
- Tom Jones Trust Elevation Use Case https://wiki.idesg.org/wiki/index.php?title=Trust_Elevation_Use_Case
- Donald MacKenzie, Mechanizing Proof: Computing, Risk and Trust, MIT Press ISBN 0-262-13393-8
- Oriana Riva +3 Progressive authentication: deciding when to authenticate on mobile phones Published in: Proceedings Security'12 Proceedings of the 21st USENIX conference on Security symposium Pages 15-15 Bellevue, WA August 08 - 10, 2012, http://feihu.eng.ua.edu/NSF_CPS/year1/SP_paper1.pdf
- Jeffrey Warren, +3, Progressive Authentication on Android https://css.csail.mit.edu/6.858/2013/projects/jtwarren-vkgdaddy-vedha-vvelaga.pdf
- NIST Digital Identity Guidelines https://doi.org/10.6028/NIST.SP.800-63-3