Identity and attribute exchange

Attribute exchange is defined as “the online, real-time exchange of data specific to the transaction in hand, with the verified user present and with their full knowledge and permission”.

For example, a local authority might, with the customer’s permission, ask the Department for Work and Pensions (DWP) if an applicant is eligible for a Blue Badge, based on their Disability Living Allowance or Personal Independence Payment status. The question would be asked online, in real time, with an immediate response from the DWP.

This “conversation” would be brokered by an attribute exchange hub, a generic hub that could connect any service provider to any attribute provider to establish entitlement to any service. Service providers and attribute providers might come from the private and public sectors.  

Proving entitlement in real time would be much cheaper, much better for the customer, and would allow a service provider to immediately offer linked services as part of a really joined up customer journey. An applicant found to be entitled to a Blue Badge might be offered a concessionary travel card as part of the same online journey.

It is important to establish the customer’s identity online if they are going to give permission for information about themself to be shared. GOV.UK Verify can deliver that assurance.
For further information see the write ups of the Warwickshire County Council/Open Identity Exchange projects published in 2014 and 2015. There is also a technical paper associated with the 2015 white paper.

The short answer at the moment is “we don’t know”. There are a number of reasons why it is impossible to put a figure on the service just now:

• GDS are in the process of consulting with local government about their requirements for highly assured citizen identities. When that consultation is complete GDS will be able to design an appropriate model for local government use. For example, will local government use the same identity hub as central government, or will there be a separate local government identity hub?
• The model chosen, the level of demand and the range of services requiring identity assurance will affect both the overall costs and the commercial opportunities and hence the cost to local authorities
• Once the costs are established and we know what needs to be paid there is another question about who should pay. There is a strong argument that citizen identity should be seen as a common good; the first organisation to register a new user is helping to hook them into the digital economy, which is of benefit to all public services. From that viewpoint central funding is the only sensible option.  

A number of local authorities already have customer online identity assurance solutions in place or are planning to deliver them. These allow additional services to be offered to customers. So do local authorities need GOV.UK Verify? What can it offer over and above a local solution? There are a number of advantages to GOV.UK Verify:

• GOV.UK Verify offers a high level of identity assurance. Level of Assurance 2 means that the customer’s identity can be established “on the balance of probabilities”. This is good enough to stand up in a civil court. This is likely to be a higher level of assurance than can be offered by most local solutions, and is more appropriate to higher risk services i.e. where benefits are being offered in money or kind, where sensitive personal information is being shared online with customers, and in some regulatory contexts where an audit trail is required.
• GOV.UK Verify offers customers a greater level of privacy. This is because the customer gets to choose their identity provider from a set of accredited providers, and the identity provider does all the identity proving on behalf of service providers. The service provider never knows who the customer has chosen as their identity provider and the identity provider never knows what services the customer is accessing using their online identity.
• The service provider reduces their risk because they are not holding the customer’s credentials. These are all held by the identity provider(s).
• GOV.UK Verify works to a defined set of standards and an accreditation process that is supported by independent scrutiny. This is likely to be a higher standard than could be achieved by any single local authority.
• GOV.UK Verify is a federated identity system. This means that a customer could have a single online identity that could be used to transact with a wide range of service providers – different government departments, different local authorities, and even private sector companies. Some customers will arrive pre-registered with a GOV.UK Verify identity, which will make their online journey much more seamless. GOV.UK Verify is currently only available to central government departments, but discussions are underway with local government and the private sector about increasing its scope.
• Because GOV.UK Verify is accredited to offer a known level of assurance it can be used to build ecosystems of trust. These ecosystems of trust will be used to implement attribute exchange so that eligibility for services can be established online, in real time, by requesting additional information about a customer from other organisations. Because the customer is authenticated to a high level of assurance they can give online permission for information about them to be exchanged in real time. This is “identity assurance on steroids” and delivers truly transformational capability.

It is quite possible for a local identity assurance solution to co-exist with GOV.UK Verify [See FAQ on “What should LAs do if they need an identity assurance solution NOW?”] , and for the appropriate solution to be used for each service depending on the level of identity assurance and other attributes needed

Some local authorities already have citizen identity solutions in place, others are thinking of introducing one. Some of those solutions use external identity providers, in other cases the local authority is acting as the identity provider, carries out the citizen registration and holds all the customer credentials locally.

Without a date for when GOV.UK Verify will be available to local government, councils may well want to put a local solution in place to improve their service delivery. It is quite possible for local solutions to co-exist with GOV.UK Verify, as long as the local solutions are architected correctly. Questions to ask include:

• Is the local solution a federated solution?
• Is it based on common open standards (SAML, oAuth2, OpenIDConnect)?
• Can the local solution direct the customer to the appropriate identity assurance system according to the local risk assessment and the functionality required for the service in question?

Issues of interoperability between identity assurance systems were investigated in the first Warwickshire County Council/Open Identity Exchange project. A white paper and technical paper were published in 2013.  

The GDS engagement with local authorities over GOV.UK Verify is at an early stage. So far two workshops (in February and April 2016) have been run to start assessing the demand for GOV.UK Verify in local government, the priority services that would rely on it, and the capability and capacity in local authorities to adopt it. These factors will feed into discussions about the most appropriate model for delivering highly assured online citizen identities to local government. The delivery timetable will depend on the model chosen and it is too early to give any firm commitments on dates. We will update this answer when more information is available.

Data matching is an important part of both GOV.UK Verify and attribute exchange [See the FAQ “What is attribute exchange?”].

In the context of GOV.UK Verify, once a customer has been registered and/or authenticated by the customer’s chosen identity provider, the service provider has to match that customer against their own records. This ensures the customer is associated with the correct details held in the service provider’s internal system(s).

The first time a customer who has been authenticated through GOV.UK Verify requests a service from a service provider, the service provider has to use the Matching Data Set (MDS) to perform the matching (matching cycle 1). The MDS contains the name, address, date of birth and (optionally) gender of the customer. It will contain past names and addresses if the identity provider has them.

For matching cycle 1 the service provider will need a data matching solution capable of performing a match in real time and returning a “found/not found” response to the GOV.UK Verify Matching Service Adapter.

Once the initial match is made, the persistent identifier sent by the identity provider for that customer can be stored in the local directory and can be used for subsequent matches (matching cycle 0).

If a service provider requests an additional attribute for the customer via an attribute exchange hub, the service provider will send the MDS to the attribute provider. Using a similar process to that described above, the attribute provider will match the MDS to their internal records to ensure the correct attribute is returned for the correct customer.

Data matching is an essential capability for both service providers and attribute providers.  
There are further matching cycles that can be used if a match cannot be made on the MDS alone. More information on data matching can be found in this OIX white paper.

The attribute provider (AP) gets the data provided by the service provider (SP), but the matching data set of name, dob etc does come originally from the IDP. If the user has logged in to a local authority (SP) with Verify in order to change their personal details then that particular transaction need not involve an AP. The citizen could provide the new details to the council and the council could change them in their local database(s). The local council will have a hashed personal identifier from the IDP to store against the local record, so matching that citizen a second or subsequent time round will not rely on the matching data set anyway.

The SP could decide in any future transaction which address to use, or could be explicit with the customer about the mis-match. What the service provider can’t do is inform the IDP that the address details have changed. The SP can’t do this as they have no knowledge of who the IDP is. It would be up to the citizen to inform the IDP. The SP might help by suggesting to the citizen that they ought to inform their IDP.

The matching data set from the IDP will contain any historical addresses the IDP knows about, which can help with the initial data match.

APs would typically only have access to the matching data set provided by the IDP, passed on via the SP. Again, if the IDP-recorded address is out of step with the AP-recorded address this could cause problems with data matching. However, given that there is a browser redirect to the AX hub, it is possible for the AP to request further information to disambiguate the match (but see below).

This is not strictly true. The identity session invoked by the IDP and the Verify hub when the citizen logs in is not persisted and hence the AP cannot check that the citizen has really logged in using Verify. However, I don’t think there is anything in principle to stop the SP sending additional data to the AP with the matching data set. I can’t be definitive about this as we haven’t really considered this option, but I can’t see why the data payload from the SP couldn’t be specified service by service to accommodate additional data fields. As mentioned above, there is the option for the AP to request additional information given that the browser is redirected from the SP. I agree with you that this isn’t necessarily the best user journey in all cases, but it could be an optional step that is only required if the AP can’t make an unambiguous match on the matching data set alone.

It isn’t in the architecture we have built to date, but this is why we will be looking at the User Managed Access (UMA) standard in the next OIX project. UMA is all about giving the citizen the facilities to record, review and manage the consents they have given. It is intended as a generic facility that is citizen-centric i.e. not simply to record the consents given to one organisation, but to handle consents given to any organisation. We will be working with ForgeRock on this. Eve Maler from ForgeRock has been instrumental in driving the Kantara work on UMA