Disruptive Proactivity

These are not ideas for Gov.UK Verify, but other conversations on the side where reuse of that model may be being considered – that service is referenced here as “Verify”.

The Principal consideration

The identity assurance principles, as overseen by PCAG, should apply to all deployments of a Verify hub model. Indeed, the Verify Hub codebase should probably include a configuration check that variable “follows_pcag_principles” is set to “yes” in order to start.

Care.data lessons, unlearned

HSCIC has a form you can fill in to opt yourself out of the various HSCIC datasets – it’s 12 pages long.  The equivalent form, ready to be handed to your GP, is 1 side of A4 and contains 2 tick boxes (plus space for your name, address, etc).

The HSCIC 12 page form has the same tick boxes, but the other 11 and half pages is all to verify identity, so that a remote institution that very rarely deals with patients knows that the right person filled in the form. A process, done at the wrong level, can generate that much extra paperwork. It doesn’t need to happen in a trusted system.

We assume the NHS is a trusted system.

1. Service reauthentication (A)

Normally there is a single step where you should log in and after that identity is assured, which in the case of legal identity, is entirely fine.  But not every service can be like facebook, institute a real name policy, and force citizens to produce papers on request.

For many services, there are points where a  high level of contemporary confirmation is required (just as some websites make you re-enter a password in order to change certain settings, or see certain information).

2. Service within a service

Like reauthentication, but where the process is less about reauthorisation, but landing on another, institutionally separate, service. That second service is only available to those who have logged in to the first (so there is a knowledge of valid accounts), but the interim step is the only point who knows where the individual went, and where they came from. The second service may have no attributes by which to work out their identity, but on arrival, it simply knows that the session belongs to someone with valid credentials.

There would be many small such services each protecting legally separate sensitive services (e.g. SH24), and ensuring there would need to be failures of at least three silos in order to compromise an individual’s identity. (C)

3. Define identity (e.g. NHS)

For example, the NHS has spent 20 years moving the NHS number to be the NHS equivalent of a passport number. But the criteria for getting a NHS number and a passport are different. Define who your customer group is.

If there are different definitions of identity and assurance models, a service within a service, using multiple implementations of the verify infrastructure, can provide a bridge between different definitions where that is appropriate to bridge between identity models.  (B)

Without this capability, this means either accepting the clinical definition of identity, or reworking every patient interaction in the NHS. Such a decision may be unwise.

4. Getting there from here

Existing identity providers need an on ramp that isn’t a full deployment of a IDP infrastructure on day 1. Given the existence of a trusted, shared, identifier within different institutions (e.g. NHS Number), that doesn’t matter as there is pre-shared knowledge.

Providers wishing to implement a light version of the infrastructure hand off using a custom API. The code they’d need being:

When a browser has logged with the relevant hidden field set:

$hash=sha3(rand() . $timestamp . $nhsno . $providerID);
$request=get(‘https://verifyheavy.nhsdigital.nhs.uk/private/confirmvalid?nhsno=$nhsno&timestamp=20161127191800&hash=$hash)
If (not error) {
Redirect browser to https://verifyheavy.nhsdigital.nhs.uk/clientrequest?hash=$hash
}

And when the browser shows up at NHS Digital, if the hash is current and valid, then the the NHS number is a confirmed attribute from the private request made earlier, and attribute exchange can continue from there as normal for a verify framework.

Over time, this lite client can be replaced as full pseudonymous attribute exchange becomes available.

ie