Some interim innovations enabling future deployments of verify infrastructure

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. 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).

  1. 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)

  1. 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.

  1. 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);
If (not error) {
Redirect browser to$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.



posted: 01 Dec 2016

First thoughts on a new macbook pro with touchbar.

My 6 year old macbookpro died a death with (minimal) notice this morning. I had a backup, but it was a clear hardware failure that was going to take time to repair.

So, instituting “oh fuck procedure 2″, I took a trip to the Apple Store and asked what they had in stock. 10 minutes later, I walked out with a 13” MBP with touchbar, a usb-A adapter, a USB-C iphone cable.

It took about 5 hours from walking into the apple store with my credit card, to sitting at home with a working laptop having restored from a time machine backup (which took about 3 and a half hours) happy that everything that had been backed up had been restored

These are my first thoughts on the new hardware.
1) Having 4 USB ports is ridiculously useful.

Right now, I have all 4 in use, all doing things.

They are ridiculously helpful being able to use both sides of the laptop interchangably.
2) The retina screen is adorable.

3) They Keyboard is taking a little bit of getting used to, but is pretty good

4) I can see that the touchbar will be really amazing when people finish figuring out how to use it for stuff. When it’s doing things, it’s so very helpful.

5) a USB-C only world is actually better for what it is, even if the transition is a bit of a pain.

Given the emergency nature of the change, it was not planned for. I’d thought about whether I wanted a new macbook, but had deferred a decision until the new year and customised availability was better. 

Something else happened instead. 
{This was written on Wednesday, and then work got in the way before posting. It turns out my laptop and monitor were both destroyed by a power spike which got past a failed surge protector.}

posted: 30 Nov 2016