Do the Majority of Public Sector Digital Services Need Credentials?

An argument for the lack of easily available high assurance credentials is that, given a lack of transaction volume, private sector providers may not find it economically interesting to invest in creating high assurance credentials just for the public sector.

So how about a potentially heretical suggestion? Don’t require credentials to access the application.

How often have you had to repeatedly login to the same public sector service during the course of a year? How often has the first action you have taken when you got to the service been ‘I don’t remember my login (because it has been so long), so reset’.

For the vast majority of public sector applications, and for the individuals who use them, the answers to the above two questions are ‘Once or twice during the year’ and ‘I did that!’ respectively.

So we end up with over-engineered, over-built capabilities with little to no regular usage for which we continue to incur expenses for credential lifecycle management. However, online access to applications is the present and the future of public sector services, so removing or not providing that access is NOT the answer.

An approach to addressing this issue may lie in something I came across in re-reading NIST SP 800-63-2, Electronic Authentication Guideline (PDF):

For infrequently used applications, issuance and maintenance of credentials would be prohibitively expensive. Claimants can be authenticated for immediate one-time access to an application for Levels 1 through 3.

At Level 1, there is no requirement for identity proofing before one-time use. At Levels 2 and 3, application owners act as the RA/CSP in the remote registration processes described in [SP 800-63-2 Section 5.3.1], using processes that do not require confirmation of the address of record and omitting credential issuance.

NIST SP 800-63-2, Section 5.3.4

Let us be clear on what is being said here. The application is still required to identity proof the individual (i.e. resolve, validate and verify the identity) commensurate with the results of a risk assessment.

<div class=“table-responsive”>

</div>

But the language above provides flexibility when it comes to verification of the identity (i.e. linking the validated identity information to the person making the claim of identity) and allows for omitting credential issuance.

The questions that should come up during a design session, when considering this approach, should include:

• What is the task that the individual expects to accomplish at the application, and how often does that happen?
• How important is it to the individual that the application remember them?
• What capabilities need to be in place within the application for auditing and non-repudiation when something goes wrong?

At the end of the road, this is not a one size fits all approach. But it could be a design choice that is made when evaluating how online access to an application is implemented.

Question: Have you encountered any applications where this approach to authentication and access is the norm?

RELATED INFO

• Identity Establishment, Verification and Validation
• NIST Electronic Authentication Guideline (NIST SP-800-63-2)
• Identity Validation as a Public Sector Digital Service?
• HOW TO Choose Attributes to Uniquely Identify a Person