Welcome, Guest
Username: Password: Remember me


GOV.UK Verify 11 May 2018 01:31 #7405

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
GOV.UK Verify

Although this service appears to have been used by several Government departments for some time the DWP now seems to be hell bent on making benefit claimants believe, by fair means or foul, that it mandatory to sign up for, or register on it or else lose their benefits.

This particular thread has been started in order to counter this new threat and prepare claimants to resist such an attack on their basic civil and human rights.

As always constructive comments and questions are welcome as are any further factual details garnered from other legitimate sources. In this way we can keep this thread as a useful factual reference point.

All I ask is that you verify the source of any details or information you add. By this I don’t mean that you should sign up to the GOV.UK service to verify your posts but merely that you provide a link to your source.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, comply or die, Catwoman, KatiLB

GOV.UK Verify 11 May 2018 01:32 #7406

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
Protecting privacy in GOV.UK Verify
Posted by: Toby Stevens, Posted on: 5 November 2014 - Categories: How GOV.UK Verify works, Policy, Research

GOV.UK Verify will provide users with a simple, trustworthy and secure means of accessing public services. Privacy is an essential component of that trust relationship. I’m an independent privacy specialist working alongside the GOV.UK Verify team to ensure that the system meets privacy expectations.

The GOV.UK Verify approach is a good starting point for a ‘privacy-positive’ authentication system, since concepts of anonymity, data minimisation and user control are baked into the underlying technical and commercial models. There will always be areas where we are obliged to retain or share data - for example where providers might need to hold audit records for the prevention and investigation of crime - but controls will ensure that these controls are transparent to the user, and cannot be abused by government or providers.

The privacy approach is guided by the Privacy and Consumer Advisory Group, an independent voluntary body comprising experts on privacy, civil liberties and identity management. They have developed nine Identity Assurance Principles, which define specific privacy goals, and which form the cornerstone of the privacy approach (in addition to duties under the Data Protection Act). Every identity provider and service provider, including the Government Digital Service, will be expected to embed those principles into their identity assurance services, and to demonstrate that they have done so.

As GOV.UK Verify enters public beta, we’re reviewing every aspect of the service to assure the users - and ourselves - that the service meets those privacy expectations. A comprehensive assessment will test how well it lives up to the requirements, and what more needs to be done. We are checking the procurement to ensure that it mandates good privacy practices, including the Identity Assurance Principles, and does not close the door on possible future privacy requirements.

Privacy is not a fixed deliverable, but a fundamental quality of the identity assurance programme, so this work is just the first step in ensuring that GOV.UK Verify builds and maintains users’ confidence that their privacy will be protected.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 01:50 #7407

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
Privacy and Consumer Advisory Group: Draft Identity Assurance Principles
Published 17 June 2013

1. Introduction
In our electronically enabled, 24/7 world it is very convenient to go online and receive information, pay bills, order consumables or send messages. So how do we know who we are communicating with? How do we identify ourselves so that it is our bill that is settled and not somebody else’s bill? What degree of identification is necessary to obtain a benefit or pension from the state? Is the same high degree of identity assurance needed to apply for a resident’s parking permit? How do we disclose the minimum detail that is necessary for the transaction we want to undertake? How do we fix things if there is a problem? And finally, how do we perform all these operations, in private, without raising any spectre that “someone, somewhere” could be keeping an unlawful record of our interactions?

The answer to such questions is provided by an Identity Assurance Service which is designed to allow individual users to control when to reveal their own identifying information and the minimum detail to reveal. Such focus on individual control and consent is far away from old-fashioned and discredited notions of an Identity Card Scheme where there are centralised databases, supported by mandatory disclosures and compulsion. The intention is to design a secure Identity Assurance Service that is attractive to consumers by allowing them to control a number of identity credentials, chosen by them, which can be voluntarily used with different Service Providers.

If individuals trust such an Identity Assurance Service then certain benefits follow: the Service Provider is less worried about ID theft and impersonation as fraudulent claims based on the use of diverse identities becomes well nigh impossible. At the same time, the individual citizen is reassured that their identity is secure and any transaction is safely delivered to the right organisation. This is a collaborative win-win outcome for the individual and all taxpayers; in summary everybody benefits.

To deliver these objectives there has to be a framework (the Nine Identity Assurance Principles) that gives real meaning to terms such as “individual privacy” and “individual control”. By necessity, therefore, there has to be a degree of precision concerning the wording of these Principles to ensure that those participating in an Identity Assurance Service are left in no doubt it is designed around the needs of the individual (and not on the needs of any state body or commercial corporation). So in order to demonstrate that these Principles do actually serve the interest of the individual, we have prepared a one sentence summary, expressed in the first person, which defines the intended effect of each principle.

Identity Assurance Principle Summary of the control afforded to an individual
1. User Control Identity assurance activities can only take place if I consent or approve them
2. Transparency Identity assurance can only take place in ways I understand and when I am fully informed
3. Multiplicity I can use and choose as many different identifiers or identity providers as I want to
4. Data Minimisation My request or transaction only uses the minimum data that is necessary to meet my needs
5. Data Quality I choose when to update my records
6. Service-User Access and Portability I have to be provided with copies of all of my data on request; I can move/remove my data whenever I want
7. Governance/Certification I can have confidence in any Identity Assurance System because all the participants have to be accredited
8. Problem Resolution If there is a problem I know there is an independent arbiter who can find a solution
9. Exceptional Circumstances Any exception has to be approved by Parliament and is subject to independent scrutiny

2. Commentary on the context of the Principles
Commentary to help the reader understand the context of how the Nine Identity Assurance Principles apply.

A. These Principles are not a set of principles devoted just to privacy or data protection. Although produced by the “Privacy Group”, these Principles cover ALL aspects of the operation of a user-centric, Identity Assurance Service which places the individual Service-User in control of when and how they assert their identity.

B. The Principles are equal to each other and do not-overlap. Each Principle has a specific role and, in combination, they are all necessary to engender trust in an Identity Assurance Service. Each Principle will apply in different circumstances (some of which, we stress again, are not limited to a mere privacy concern).

C. These Principles are limited in their application to the processing of data in an Identity Assurance Service (e.g. establishing and verifying identity of a Service-User; conducting a transaction that uses an identity, maintaining audit requirements in relation a transaction associated with the use of a service that needs identity verification etc). They do not apply to any other data (e.g. data that are used to deliver a service, or measure its quality).

D. The Nine Principles assume that an Identity Assurance Service is mature and well established. We understand that in the early stages that there might be a phasing in period in relation to each Principle or that in some cases, a Principle might need a degree of flexibility in the first instance. However, we believe that within a reasonable time-frame, all these Principles should have full effect.

E. We recognise that special interests (e.g. law enforcement) may need exemptions from the Principles. Such special interests are subject to a simple rule: exemptions have to be explicitly defined in any legislation required to establish the Identity Assurance Service infrastructure. We do not think it advisable to allow existing legislation to define access to any data from any Identity Assurance Service as such legislation, when enacted, could not have been scrutinised in the context of an Identity Assurance Service; any exemption from these Principles needs that public scrutiny in order to gain credibility and maintain trust. As these Principles only apply to Identify Assurance data used by the Identify Assurance Service, they have no impact on any operational matter of any law enforcement agency, except where the operational matter relates to obtaining such data from an Identify Assurance Service. In such cases, the “Exceptional Circumstances Principle” will apply.

F. The wording of each Principle has been carefully chosen to balance any competing claim; they have been widely debated within the Privacy Group so we request that any changes to the text of any Principle to be supported by the detail of the problem which has been encountered. The Privacy Group is convinced it has drafted Principles which allow all identifiable interests to be balanced. Of course, we accept that this view might not be wholly shared by others and that is why we ask for the detail we have requested to be provided. We intend to review the Principles at least annually in the light of experience and any comments received.

G. Where appropriate, we expect that the application of these Identity Assurance Principles will be described: * in public documents that explain the operation of any Identity Assurance Service * in presentations about any Identity Assurance Service * in procurement processes, technical design and associated procedures of any Identity Assurance Service

H. The Principles are limited to their application to any Identity Assurance Service in the UK, with a particular emphasis on the UK Government objective to deliver many services electronically by 2018. We note, however, these Principles could have international reach, especially in the USA, or in European Union, OECD and APEC countries. However, our starting assumption has been that such interchangeability with any other nationally based Principles will only become relevant when the UK Principles have shown to have a proven track record in gaining the confidence of individuals who use a Service. However, we can assert that our Principles are fully consistent with all national and international data protection requirements and the obligations arising from the UK’s common law of confidence.

I. The Principles are drafted in a way that allows for a degree of precision. They are not drafted in a way that defines statutory Principles but the text could form the basis of a Statutory Code of Practice, for example on the model provided by the Statutory Code of Practice on Data Sharing. We have not insisted on any statutory enforcement mechanism other than any exemption be identified in the law that establishes the Service.

2.1 Definitions
These Principles are limited to the processing of IDA data in an Identity Assurance Service (e.g. establishing and verifying identity of a Service-User; conducting a transaction that uses a user identity, maintaining audit requirements in relation a transaction associated with the use of a service that needs identity verification etc). It does not include, for example, any data used to deliver a service.

In the context of the application of the Identity Assurance Principles to an Identity Assurance Service:

“Identity Assurance data (IDA data)” means any recorded information that is connected with a “Service-User” that are:
• “Personal data” (which means any recorded information that relates to a “Service-User” who is also an identifiable living individual). (Note: this is a data protection type definition that avoids Durant complications)
• “Audit data” (which includes any recorded information that is connected with any log or audit associated with an Identity Assurance Service)
• “Relationship data” (which means any recorded information that describes (or infers) a relationship between a “Service-User”, “Identity Assurance Provider” or “Service Provider” with another “Service-User”, “Identity Assurance Provider” or “Service Provider”, and includes any cookie or program whose purpose is to supply a means through which relationship data are collected)
• “Attribute data”, which means any recorded information that is connected with (“insert definition if needed”)
• “Identity data”, which means any recorded information that is connected with (“insert definition if needed”)
• “Transactional data”, which means any recorded information that is connected with (“insert definition if needed”)
• “General data” which means any other recorded information which is not personal data, attribute data, audit data, relationship data, identity data or transactional data but still is connected with a “Service-User” (note: this is a much needed “catch-what’s-left”)

However, IDA data does not include any anonymous recorded information that is only remotely connected with a Service-User.

“Processing” in the context of IDA data means “collecting, using, disclosing, retaining, transmitting, copying, comparing, corroborating, correlating, aggregating, accessing” the data and includes any other operation performed on IDA data.

“Identity Assurance Provider” means the certified individual or certified organisation that provides an identity service (e.g. establishing an identity, verification of identity); it includes any agent of a certified Identity Assurance Provider that processes IDA data in connection with that identity service.

“Service Provider” means the certified individual or certified organisation that provides a service that uses an Identity Assurance Provider in order to verify identity of the Service-User; it includes any agent of the Service Provider that processes IDA data from an Identity Assurance Service.

“Service-User” means the person (i.e. an organisation (incorporated or not) or an individual (dead or alive)) who has established (or is establishing) an identity with an Identity Assurance Provider; it includes an agent (e.g. a solicitor, family member) who acts on behalf of a Service-User with proper authority (e.g. an agent who is a public guardian, or a Director of a company, or who possesses power of attorney).

“Identity Assurance Service” includes all aspects of the technology (e.g. hub, hardware, software, database, documentation) in the possession or control of any “Service-User”, “Identity Assurance Provider” or “Service Provider” that is used to facilitate a Service; it also includes any IDA data processed by that technology or by an Identity Assurance Provider or by a Service Provider in the context of the Service. (Note: extends to a Provider’s agents by definition).

“Third Party” means any person (i.e. any organisation or individual) who is not a “Participant” (e.g. the police or a Regulator). Note: we think it helpful to create a link to the language from the National Strategy for Trusted Identities in Cyberspace (NSTIC) which defines participants as “the collective subjects, identity providers, attribute providers, relying parties, and identity media taking part in a given transaction”. This way, Third Parties are not Participants.

“Participant” means any “Identity Assurance Provider”, “Service Provider” or “Service-User” in an Identity Assurance Service. (Note: a “Participant” includes any agent by definition).

2.2 Note on the Principles
The subsets of IDA data (e.g. “personal data”, “identity data”) identify all the main components of IDA data. Some of them (e.g. “identity data”) have been left undefined in case they are needed to specify an exemption to be approved by Parliament (e.g. see “Note E in the “Commentary about the Nine Principles” above or The Exceptional Circumstances Principle – Principle 9 below). The division of IDA data in this way allows any exemption to be narrowly defined.

3. The Nine Identity Assurance Principles

1. The User Control Principle

Identity assurance activities can only take place if I consent or approve them.

An Identity Assurance Provider or Service Provider must ensure any collection, use or disclosure of IDA data in, or from, an Identity Assurance Service is approved by each particular Service-User who is connected with the IDA data.

Identity Assurance Providers or Service Providers cannot use or disclose IDA data without the Service-User’s knowledge and agreement (i.e. consent).

Service-Users must be able to control/choose whether or not to use or disclose their IDA data and whether or how they assert their identities.
Any exemption from the User Control Principle should be specified via the Exceptional Circumstances Principle.
The Data Minimisation Principle also applies to any collection, use and disclosure.

Legal commentary
The DPA requirement is that processing is either legitimised by consent of the data subject or is “necessary” for a contract with the data subject or is “necessary for a legal obligation or statutory functions of a public body. etc etc (i.e. one of the sched 2, paras 1 to 6 of the DPA).
Consent takes the meaning in the Data Protection Directive (or any successor Regulation)
Also covers some “fair processing” requirements.

2. The Transparency Principle

Identity assurance can only take place in ways I understand and when I am fully informed.

Each Identity Assurance Provider or Service Provider must be able to justify to Service-Users why their IDA data are processed.

Each Service-User, prior to using an Identity Assurance Provider or a Service Provider for the first time, must be provided with a clear description about the processing of IDA data in advance of any processing.

The information provided includes a clear explanation of why any specific information has to be provided by the Service-User (e.g. in order that a particular level of identity assurance can be obtained) and identifies any obligation on the part of the Service-User (e.g. in relation to the User’s role in securing his/her own identity information).

Any subsequent and significant change to the processing arrangements that have been previously described to a Service-User needs the prior consent or approval of that Service-User before it comes into effect.

Organisations should engender trust by being open about all aspects of the processing of IDA data (Processing means “collecting, using, disclosing, retaining, transmitting, copying, comparing, corroborating, aggregating, accessing” and anything else).

Such information does not need to be provided at every transaction, if the Service-User has been previously informed.

We expect that a public document explaining how these Principles have been applied to an Identity Assurance Service will be a valuable aid in meeting the objectives of this Principle (see also the Governance/Certification Principle below).

Where changes occur, any Provider would have to anticipate the fact that consent or approval might not be forthcoming.

Any exemption from the Transparency Principle should be specified via the Exceptional Circumstances Principle.

Legal commentary
First data protection principle requirement that the processing of personal data is fair.

3. The Multiplicity Principle

I can use and choose as many different identifiers or identity providers as I want to.

A Service-User is free to use any number of identifiers that each uniquely identifies the individual or business concerned.

A Service-User can use any of his identities established with an Identity Assurance Provider with any Service Provider.

A Service-User can choose any number of Identity Assurance Providers and where possible can choose between Service Providers in order to meet his or her diverse needs.

A Service-User shall not be obliged to use any Identity Assurance Provider or Service Provider not chosen by that Service-User; however, a Service Provider can require the Service-User to provide a specific level of Identity Assurance, appropriate to the Service-User’s request to a Service Provider.

A Service-User can terminate, suspend or change Identity Assurance and where possible can choose between Service Providers at any time

A Service Provider does not know the identity of the Identity Assurance Provider used by a Service-User to verify an identity in relation to a specific service.

These first three need no explanation.

Obviously where there is a monopoly Service Provider (as is often the case with public sector services), then the Service-User does not have a choice of Service Provider. However, in general, there will be a number of Service Providers to choose from; this explains why the Principle uses “where possible”.

Where Service Providers are a monopoly or near monopoly, they should not be able to require a particular Identity Assurance Provider to be used.

However, a Service Provider must be able to insist on a particular (and not unreasonable) level of identity assurance before delivering a service.

Any exemption from the Multiplicity Principle should be specified via the use of the Exceptional Circumstances Principle.

It should not be possible to link a Service-User’s activities in different contexts.

4. The Data Minimsation Principle

My request or transaction only uses the minimum data that is necessary to meet my needs.

IDA data processed by an Identity Assurance Provider or a Service Provider to facilitate a request of a Service-User must be the minimum necessary in order to fulfil that request in secure and auditable manner.

Note: it is useful to remind the reader that this principle has a wide reach because of the definitions of IDA data and Processing:
• “IDA data includes “Personal data”, “Audit data, “Attribute data, “Identity data”, “Relationship data”; “Transactional data” and other “General data”
• “Processing” in the context of IDA data means “collecting, using, disclosing, retaining, transmitting, copying, comparing, corroborating, aggregating, accessing” etc.

So for the absence of doubt, any aggregation, correlation or corroboration of IDA data from diverse Identity Assurance Providers or Service Providers are subject to all the Identity Assurance Principles.

All IDA data processed has to be the minimum necessary in the context of service delivery or identity verification. Note that a Service User can, for his own convenience, request a Provider to hold information beyond the minimum necessary. Subject to any audit or legal requirement, the Minimisation Principle requires any aggregation, correlation or corroboration to be of a transient nature.

Data minimisation is a very important design criterion; we expect compliance with this Principle will be an essential component of any Identity Assurance Service.

Any decision that requires a risk assessment of the Service-User will need the correlation of data from possibly a number of sources will also be subject to the Data Minimisation Principle Note that the User Control or Transparency Principle should ensure the Service-User can provide informed consent/approval.

There should be no centralisation of IDA data.

Any exemption from the Data Minimisation Principle should be specified via the Exceptional Circumstances Principle.

Legal commentary
Third and Fifth Data Protection Principles (“Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed” and “kept no longer than is necessary”).

The Data Protection Regulation currently being discussed by the European Commission and Member States aims to further strengthen the personal data minimisation requirements beyond those set in the Third Data Protection Principle of the 1998 Act. This is supported by Data Protection by Design objectives that also appear in the Regulation.

5. The Data Quality Principle

I choose when to update my records.

Service-Users should be able to update their own personal data, at a time at their choosing, free of charge and in a simple and easy manner.

Identity Assurance Providers and Service Providers must take account of the appropriate level of identity assurance required before allowing any updating of personal data.

Unnecessary retention and excessive data collection would breach the Data Minimisation Principle.

If a Service User fails to keep his information up to date, then his transactions could fail; this we believe is the incentive for Users to keep information up to date.

Any legal obligation that requires, for example, an individual to notify a public authority of a change of circumstances is unaffected; a Service-User can choose to use an Identity Assurance System, at any chosen time, to update their own records subject to any identity assurance requirement prior to accepting an update.

As failed transactions (e.g. by virtue of a data mismatch) are likely to be alerted to Service-Users, this affords a possibility of designing procedures that offer Service-Users the opportunity to update their own details immediately – again subject to any identity assurance requirement prior to accepting any update.

The Identity Assurance/Service Provider has to be able to decide the level of identity assurance before accepting a change to a Service User’s data.

Any exemption from the Data Quality Principle should be specified via the Exceptional Circumstances Principle.

Legal commentary
Accuracy requirements of DPA (4th Principle).

6. The Service-User Access and Portability Principle

I have to be provided with copies of all of my data on request; I can move/remove my data whenever I want.

Each Identity Assurance Provider or Service Provider must allow, promptly, on request and free of charge, each Service-User access to any IDA data that relates to that Service-User.

It shall be unlawful to make it a condition of doing anything in relation to a Service-User to request or require that Service-User to request IDA data.

The Service-User shall have the right to require an Identity Assurance Provider to transmit his personal data, to a second Identity Assurance Provider in a standard electronic format, free of charge and without impediment or delay.

The Service-User’s right to data portability shall also apply between Service Providers.

For the absence of doubt, such access includes access to logs of Service-User activity, disclosure logs of any Service-User data, and any audit data relating to that Service-User’s activity but excludes any anonymised data that can no longer be linked or associated with a particular Service-User.

The prohibition is needed as there is a practice in the UK of requiring data subjects to use their subject access rights to criminal records and medical records and show the product of their access request to an employer or insurer. The prohibition stops unscrupulous use of the access right. The text is based on the prohibition in the ID Card Act 2005.

This is the right to data portability.

Any exemption from the Service-User Access and Portability Principle should be specified via the Exceptional Circumstances Principle.

Legal commentary
Subject access under the DPA.

Privacy by Design (under the heading Data Protection by Design) should include a user access functionality; free Subject Access is part of the European Union’s Data Protection Regulation under discussion.

Stopping Enforced Subject Access is very important.

(Data Portability forms part of the European Union’s Data Protection Regulation under discussion).

7. The Governance/Certification Principle

I can have confidence in any Identity Assurance System because all the participants have to be accredited.

As a baseline control, all Identity Assurance Providers and Service Providers shall be certified.

There shall be a certification procedure subject to an effective independent audit regime which ensures that all relevant, recognised identity assurance and technical standards, data protection or other legal requirements are maintained by Identity Assurance Providers and Service Providers.

In the context of personal data, certification procedures include the use of Privacy Impact Assessments and Privacy by Design concepts.

All Identity Assurance Providers and Service Providers shall take all reasonable steps to ensure that a Third Party cannot capture IDA data that confirms (or infers) the existence of relationship between any Participant.

Certification can be revoked if there is significant non-compliance with any Identity Assurance Principle. The architecture of an Identity Assurance Service must be based on open standards.

This Principle mandates the use of all relevant standards as the baseline for all information assurance/security/integrity controls used.

We expect that this Principle will require the production of document that describes how the design of the Identity Assurance Service has been informed by the application of the Identity Assurance Principles to the design (See also the Transparency Principle above).

The “reasonable steps” tries to ensure that web-based services cannot capture details of a relationship between a Service User and any Identity Assurance Provider or Service Provider (for example through the use of webcrawlers or webspiders)

(Note: this is why relationship data includes in its definition relevant cookies and programs that collect such data.)

Any exemption can be specified via use of the Exceptional Circumstances Principle, but we don’t expect many (or indeed any!).

Legal commentary
The Accountability Principle in the Data Protection Regulation (currently under discussion in Europe); the current obligations in the Seventh Data Protection Principle (or HMG Security Framework or ISO27000) are expected to form part of the Certification process.

Privacy Impact Assessments and Privacy by Design concepts will be legal obligation if the European Commission’s Data Protection Regulation becomes law (see under the heading Data Protection by Design and Data Protection Impact Assessments).

Consideration needs to be given as to whether it should be made unlawful for such details to be captured (even overriding any User’s explicit consent). We are very concerned that many Users do not know what permissions they have given nor do they read privacy policies of organisations based outside the EEA. There is a need to take away the defence of a Third Party that it has the permission of the User to capture details from an Identity Assurance Service.

8. The Problem Resolution Principle

If there is a problem I know there is an independent arbiter who can find a solution.

A Service-User, who after a reasonable time, cannot or is unable to resolve a complaint or problem directly with a Identity Assurance Provider or Service Provider can call upon an independent Identity Ombudsman to seek independent resolution of the issue.

As part of the certification process, Identity Assurance Providers and Services Providers are obliged to co-operate with the Identity Ombudsman and accept his impartial determination and to ensure that contractual arrangements:
• reinforce the application of the Identity Assurance Principles
• contain a reference to the Identity Ombudsman as a mechanism for problem resolution

The Identity Ombudsman can resolve the same or similar complaints affecting a group of Service-Users.

The Identity Ombudsman can co-operate with other Regulators in order to resolve problems and can raise relevant issues of importance concerning an Identity Assurance Service.

An adjudication/recommendation of the Identity Ombudsman shall be published.

There can be more than one Identity Ombudsman.

The Identity Ombudsman can recommend changes to standards or certification procedures or that an Identity Assurance Provider or Service Provider should lose their certification.

The central problem is that many different Regulators (e.g. Information Commissioner; FSA, OFCOM) could be involved and that an individual has to be able to complain to a central point of contact in order to resolve an issue.

Without an Ombudsman/Advocate, there is a risk that the Service User will be passed from pillar to post.

One assumes, however, that a Service-User will resolve a complaint in the usual way. However, it is possible that complaints will not be resolved satisfactorily.
We expect that any determination made by an Identity Ombudsman can be appealed to the Courts by any party to the dispute.

Any exemption from the Problem Resolution Principle can be specified via use of the Exceptional Circumstances Principle (but we can’t see the need of any exemption as explained as follows).

Take an extreme example, and suppose there was an exemption needed for say “national security”, then the Regulator who has the responsibility for the national security function could be designated as the “ombudsman” for that purpose. This would maintain the integrity of this Principle and the secrecy required of the national security function.

9. The Exceptional Circumstances Principle

Any exception has to be approved by Parliament and is subject to independent scrutiny.

Any exemption from the application of any of the above Principles to IDA data shall only be lawful if it is specified in a statutory framework that legitimises all Identity Assurance Services, or an Identity Assurance Service in the context of a specific service.

Any exemption from the application of any of the above Principles that relates to the processing of personal data must also be necessary and justifiable in terms of one of the criteria in Article 8(2) of the European Convention of Human Rights: namely in the interests of national security; public safety or the economic well-being of the country; for the prevention of disorder or crime; for the protection of health or morals, or for the protection of the rights and freedoms of others.

Any subsequent processing of personal data by any Third Party who has obtained such data in exceptional circumstances (as identified by Article 8(2) above) must be the minimum necessary to achieve that (or another) exceptional circumstance.

Any exceptional circumstance involving the processing of personal data must be subject to a Privacy Impact Assessment by all relevant “data controllers” (where “data controller” takes its meaning from the Data Protection Act).

Any exemption from the application of any of the above Principles in relation to IDA data shall remain subject to The Problem Resolution Principle.

There are a myriad of data sharing laws each with different standards and rules. To engender trust in identity assurance and to improve Parliamentary scrutiny, it is proposed that ONLY statutory gateways created by any legislation needed to establish the programme are valid. There might be a phasing in period (as discussed in the workshop).

The special interests indentified in Article 8(2) are expressly put into this Principle. However, the linkage to individual human rights means that the link can only relate to personal data (i.e. an identifiable living individual). This is why a definition of “personal data” is needed

This allows for limited onward data sharing, so long as it is consistent with Article 8 of the HRA. There is a real issue as to whether the current level of privacy protection is adequate for some public bodies (e.g. is the protection in RIPA adequate? is the Regulatory regime for the Security Service, GCHQ or the Police OK?).

Our construction avoids the opening up what would be an everlasting debate; however, the last paragraph of this Principle is the necessary “quid pro quo” for this position. (See comments at the bottom of Principle 8 re Governance on national security.)

Legal commentary
The Privacy and Consumer Advisory Group to the Government’s IDA Programme recommends that legislation is enacted to implement the Government’s Identity Assurance Plans. Any such legislation would be the natural vehicle to describe all aspects falling under the “Exceptional Circumstances Principle”.

It is expected that any exemption will be limited, and expressed in terms of particular subsets of IDA data (e.g. “personal data”, “audit data”, “relationship data”) necessary for the application of any exemption.

The European Commission’s Data Protection Regulation calls for mandatory Data Protection Impact Assessments (i.e. Privacy Impact Assessments).
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 01:58 #7408

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
How the GOV.UK Verify technical architecture protects users' privacy, and why it's appropriate
Posted by: Adam Cooper, Posted on: 5 November 2014 - Categories: How GOV.UK Verify works, Policy, Technical

When we designed the identity assurance architecture we wanted to protect users from identity theft and fraud, to secure their data as it is used online, and to reduce the amount of information needed from the user to a minimum.

These concepts have been embodied in the Identity Assurance Principles as developed by our Privacy and Consumer Advisory Group and have been a guide throughout the development of our architecture.

To help us to achieve these goals we created a hub service that sits between online government services and the identity providers to help users to authenticate with an appropriate identity provider, facilitate matching of users to services, and to enforce policy e.g. only allowing trusted services to make requests.

Services need some data to identify you but we want to keep that data safe…

One of the consequences of transacting with government services is that we need to connect the user wanting to access a service with records or identifiers that mean something in the context of that service. For example, we want to make sure that a service retrieves your records, such as your driver licence details, rather than those for the other John Smith who lives just a few streets away.

To do this services need data that we can trust so integrity and provenance are important to the service providers. We also need to move that data from a trusted identity provider across the internet safely. To achieve this we only send data we really need to help you access a government service, and we use powerful cryptography to ensure that only the intended recipient can read the data and that no one can change that data in-flight.

The data we send about you when you log-in is limited to something called a Matching Data Set which is made up of your Name, Address, Date of Birth, and Gender (if you provided it*). This data is verified by your choice of Identity Provider and is used to access government services by matching to the data they already have such as your driver licence in the example above.

We want to minimise the data we need…

We don’t keep your identity data centrally; in fact we don’t keep it at all, or even get to see it ourselves: it is held by the identity providers on your behalf.

Some people think “it’s the government, they know me…” but largely it’s only the service or department you are interacting with that know your details and even then the data they hold could well be out of date if you haven’t used their services recently, or incomplete if they didn’t need to keep all of your information as part of the process.

To protect your privacy the hub service only has access to a small amount of your data when you want to access a service, which is only released to us when you consent to that happening, and the identity provider of your choice verifies it in advance. We call this small set of identity data the Matching Data Set and we make sure that services don’t keep this data or re-use it for any other purpose unless they first gain your consent.

We don’t let identity providers know what service you are accessing…

One advantage of our hub service is that we can prevent identity providers from knowing which government service you are about to use. We appreciate that our identity providers are commercial organisations and we don’t think it’s appropriate for them to know what service you are trying to access. Unless you choose to tell your identity provider, they won’t know with which service you’re using, and they certainly won’t be able to see what you’re doing there, they will simply know that you are accessing a government service.

We want to make sure you can protect your identity…

Identity theft and account takeover are real-world problems and whilst we might not be able to completely stop this happening we do want to provide users with the ability to repair identities or to recover accounts depending on the situation.

Identity providers play a major part in this, but the hub service and our architecture allows us to identify potential problems as they happen, or investigate when and where identities have been used should an incident be reported.

In short, we care about your identity and we want to protect it but we realise that you also want a great service. Minimising the data we need, protecting it at all times, and making sure that we get your consent should we need to use your data as part of a service helps us to ensure that protection and still provide great services.

In simple terms there are three services that you will encounter when accessing a government service: the government service itself, the hub service, and an identity provider of your choice where you prove your identity or simply login. You are only asked to enter what we need, we minimise what is stored, and we always gain your consent to proceed.

*Clarification note:
Users are asked to provide their gender but it's not mandatory. If a user does say what their gender is, it may be useful in some cases as part of the set of data that's used to match them to the correct record in a department. But it's optional, relies on data asserted by the user (ie it is definitely gender, not sex), and unlike some of the other elements of the matching set, IDPs certainly don't ask for any history of gender (unlike, say, recent address history which is needed to help identify some people).
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 02:00 #7409

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
Using mobile phones as part of GOV.UK Verify
Posted by: Janet Hughes, Posted on: 7 November 2014 - Categories: How GOV.UK Verify works, Standards and certification

We've had some questions and comments this week about how mobile phones are used as part of GOV.UK Verify so thought it might be useful to write a short post about it.

In summary, you won't have to use a mobile phone to use GOV.UK Verify.

Identity providers have to meet published standards when they first verify someone's identity and in the way they authenticate of the person next time they want to access a service using GOV.UK Verify. We don't specify how the identity providers meet those standards, and we expect they will use a range of methods.

Identity providers have to include 2 steps to authenticate users - a secret known only to the user (eg a password), and another secret, communicated to the user through another channel. This is to protect against someone being able to steal the user's login credentials and pretend to be them.

The second step can be a code sent to a mobile phone (one of the more commonly used methods), or it can be another method such as a code communicated to you over your telephone landline, a gridcard or a hardware device similar to those used by some banks. We're expecting providers to give users a range of options. At least one provider is already planning to provide an alternative way for people who don't want to use a mobile phone when they authenticate. So if you want to use another method, other than a mobile phone, you'll be able to choose an identity provider that will enable you to do that.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 02:03 #7410

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
Identity assurance in the European Union
Posted by: Robin Walker and Sam Rea, Posted on: 17 November 2014 - Categories: Industry and market engagement, Policy, Standards and certification

We wanted to share some of the work that we're doing to help make it possible for people to use GOV.UK Verify to identify themselves when accessing services in other European countries.

The eIDAS Regulation
European member states want people to be able to identify themselves online for digital services in other countries. Recently, a regulation has been passed in Europe to allow this - the eIDAS Regulation.

Context: The digital single market
The European Commission’s work in this area is is part of a wider programme to create a digital single market. Identity is an important part of the digital single market because there are some services that can only be offered digitally if providers can reliably know who the user is.

Impact on users
The regulation means that it will become possible for people in the UK to use GOV.UK Verify for online public services in other countries. This could include car registration, paying taxes or setting up a business in another country.

Looking beyond the eIDAS Regulation, in the future people may also be able to give consent for services to access information, such as health or education records, wherever they are in the EU. This could be important when seeking medical assistance abroad or applying to study in another European country.

Now the regulation is agreed, we're working on the technical infrastructure to make this all happen. This will take a little time whilst both public and private sector service providers adapt and develop cross-border services.

Setting standards for the EU identity assurance market

The Regulation has not prescribed specific technical practices - as we're doing in the UK, it takes an outcome-based approach to build confidence and trust between countries. This means that each country can use their current systems, while not preventing others from taking advantage of future digital and technological developments.

EU work with the private sector
This European progress also has great potential for the private sector, both as identity providers and as providers of online services.

In the UK, we work with the private sector through the Open Identity Exchange UK (OIX). This enables us to explore how organisations could develop new services to make use of GOV.UK Verify. Following on from our work on the eIDAS Regulation, we hope this sort of engagement will be possible at a European level too. This work could help to build trust in the sharing economy, make it easier for you to use banking services across border and also contribute to speeding up your journey through the airport.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 02:14 #7411

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
How does a certified company establish that it's really you?
Posted by: Janet Hughes, Posted on: 21 November 2014 - Categories: How GOV.UK Verify works, Standards and certification

GOV.UK Verify will protect you from someone else pretending to be you and fraudulently accessing sensitive records and services. This is increasingly important as it becomes possible for people to do more things entirely digitally (such as changing your personal details with a government service, claiming payments or accessing services).

When you want to access a service using GOV.UK Verify for the first time, you’ll be asked to choose from a list of certified companies (also known as ‘identity providers’ - they can actually be any type of organisation that is certified).

Your chosen certified company will ask you for some information and carry out some checks to establish, to a defined level of assurance, that you are who you say you are. Once you’ve done this once, your certified company will give you some sign-in credentials that you’ll be able to use to access an increasing range of government services. This post is about the types of information and checks the companies use to establish that it's really you when they verify your identity for the first time.

To verify your identity, certified companies have to look at a range of evidence and checks to establish that you are who you say you are - no single piece of evidence is sufficient. There are five elements involved, and the company has to achieve specific thresholds in each one before they can verify someone’s identity.

Certified companies have to work to published government standards when they verify your identity: Good Practice Guide 45 and the IPV Operations Manual. We’ve published a guide to the checks certified companies have to perform to summarise the requirements in the published standards.

The company has to get the your consent to access data sources such as credit reference agency data for the purposes of verifying your identity. The company can only use the data you provide for the purposes of verifying your identity - they can’t use it for any other purpose without your informed consent, and they have to process and store your data in accordance with data protection requirements.

Element A - capture evidence that the identity exists

The company will ask you to provide some evidence that demonstrates that your identity is real.

There are 3 categories of evidence - citizen, money and living. Different types of evidence are weighted according to how reliable and authoritative they are. So, for example, the fact that your name appears on the electoral roll is worth less than the fact that you have a UK passport or driver licence, reflecting how reliable each piece of evidence is in proving that your identity actually exists.

The certified company has to collect evidence of a sufficient weight across the citizen, money and living categories to achieve the required standards.

Element B - validating the evidence

The certified company has to establish that the evidence you've provided is valid, genuine or both, depending on the level of assurance required. ‘Valid’ means that the evidence matches a valid record held by the issuing body. ‘Genuine’ means that the evidence is real and is in the control or possession of the person who is asserting it.

To meet the requirements for element B, the identity provider can use the document checking service, or a similar commercial service, to check whether data asserted by a user is valid.

For example, if a person asserts the details of a payment card for element A, the company might establish it’s valid by checking with the issuing bank (or another reliable source) to see if the card matches a valid account, and / or it might establish it’s genuine by using a chip and pin device for the card. If a person asserts details from their driver licence or passport, the company can establish it is valid by using the document checking service.

Element C - establishing a link between the person and the identity

Having established that the identity exists, the company has to establish that the person asserting it is the owner of that identity.

They can do this through a range of methods. One commonly used method involves asking the person a range of questions it’s likely only they would know the answer to. The company can generate these questions from a range of data sources. These might include, for example, data they hold themselves (eg if they already know you because you have an existing relationship with them), data provided by another service provider, or credit reference agency data (if they do that, it won’t affect the person’s credit rating; only the person themselves will be able to tell that their credit reference agency file has been used in that way.)

Element D - counter fraud checks

The certified company has to establish that the identity is not known or likely to be false or stolen. They do this by assessing any signals that might indicate the identity is fraudulent, and by referring to data sources such as commercially available lists of known fraudulent identities or fraudulent documents.

Element E - activity history

The certified company has to establish that the identity has been active over a period of time. They can do this by finding evidence that the person has interacted with organisations like banks, utility companies, a mobile phone provider or another service provider. For example, if the person has paid a utility bill, a loan payment or a mortgage payment, that would qualify as an activity ‘event’. The provider has to find a sufficient number of events with a specified level of confidence they were generated by the person, to meet the required level of assurance.

Once they've completed these checks, the certified company can assure the service you want to use, through the GOV.UK Verify hub, that you are who you say you are. They won't share the data used to verify your identity with the government - only your name, address, date of birth and gender (if you chose to provide it). See Adam's post about how the technical architecture protects people's privacy for more information about how that works.

Where to find more information
If you’d like to know more about the standards the certified companies have to meet when verifying someone's identity, see the published Good Practice Guide, the IPV Operations Manual, and our guide to the checks identity providers have to perform.

Good Practice Guide

IPV Operations Manual

Guide to the checks identity providers have to perform
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 02:20 #7412

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
How we’re working to increase the range of data sources available for GOV.UK Verify
Posted by: Janet Hughes, Posted on: 1 December 2014 - Categories: Industry and market engagement, Policy

GOV.UK Verify involves people choosing a certified company to verify their identity and allow them to access digital government services. Over time, we want as many people as possible to be able to verify their identity using GOV.UK Verify. To do this, we’ll need certified companies to be able to use a broader range of data sources.

The main data sources certified companies can refer to
To verify a person’s identity, the certified company needs to be able to refer to a combination of official and commercially available data sources. This enables them to validate data provided by the person and establish that they are who they say they are to the required level of assurance.

The main ways certified companies refer to data sources today are:
• validating details provided by users about their passport or driving licence against official government records through the document checking service.
• drawing on data from credit reference agency files to validate evidence provided by the person about a bank or credit account, generate questions to the person that help establish that they are the owner of the identity they’ve asserted, and establish that an identity has been active over time.

Why we need to expand the range of data sources certified companies can refer to
This range of data means that to verify their identity using GOV.UK Verify today, users will need a passport and/or a driving licence and they will need to have been financially active over time (for example by holding a credit card, bank account, loan or mortgage).

So GOV.UK Verify will already work for most people, because the majority of people hold either a driving licence or passport and have a range of financial activity that a certified company can refer to. But some people won’t be able to verify their identity through GOV.UK Verify yet if they don’t have the necessary official documents and/or financial history.

To allow those people who don’t have a driving licence, passport and / or financial history to access GOV.UK Verify, we need to expand the range of data sources that are available to and used by certified companies.

There are two main ways to do this:

• expanding the scope of the document checking service and
• encouraging certified companies to make use of more commercially available data sources.

Expanding the scope of the document checking service
We’re working to identify more government data sources to add to the document checking service.

We’re hoping to be able to say a bit more about our plans on this in the new year.

The use of any additional official data sources would be subject to formal agreements on how the data can be used, and government data sources will only be used on the basis of informed user choice and consent.

Encouraging certified companies to use a wider range of good quality, relevant data sources - our next procurement exercise

We’re about to publish a Contract Notice in the Official Journal of the European Union, inviting companies to bid to be part of our new identity assurance framework.

We want to choose between four and ten certified companies (formally known as ‘identity providers’). We’re going to choose them using an evaluation mechanism that places equal weight on three factors: their price, the quality of their solution and the breadth and depth of the datasets they plan to use and refer to.

By using this approach, rather than simply selecting the cheapest providers who get over a technical or capability hurdle, we’re hoping to increase the range of data that GOV.UK Verify can draw upon.

There will be two main parts to the evaluation process: the selection stage, a process to make sure we select suitable organisations; and the award stage, where we choose the bidders that we consider will provide the best value.

To pass the selection stage, bidders need to demonstrate that they have the right skills and resources to provide the required services.

Award Stage 1
The first part of the Award Stage is designed to assess the overall quality of the bidders’ proposals. Bidders will be required to provide evidence showing how their proposed service would meet a number of criteria. These will include, for example, showing how the bidder proposes to fulfil each of the five elements of the identity proofing and verification (IPV) process.

Bids will be scored according to a marking scheme set out in the evaluation questions. Higher marks will be available for bids that demonstrate a wider range of high quality methods and approaches to Identity Proofing and Verification (IPV) and a high quality approach to service design and improvement.

To pass Award stage 1, the proposal must match or exceed the minimum pass mark for each criterion. If a bidder scores less than the minimum acceptable score against any of the criteria at Award Stage 1, they will not go through to the next stage (Award Stage 2) and will not be awarded a place on the Framework Agreement.

Any bidder that scores at least the minimum score against all of the criteria in Award Stage 1 will progress to Award Stage 2.

The scores from Award Stage 1 will contribute to the final combined score for Award Stage 2.

Award Stage 2
Award Stage 2 will be used to choose a number of successful bids by assessing them on:
(a) the quality of their solution as assessed at Award stage 1
(b) the characteristics of the datasets they propose to use
(c) their price.

The evaluation mechanism will allocate a score to each of these criteria and those three scores for each bid will be combined to create a single overall score. Those combined scores will then be ranked and we will choose our identity providers based on that ranking.

Assessment of data
We want to encourage certified companies to use more large, high quality datasets that are likely to help increase the number and volumes of available high quality datasets. This will increase the number of people who can use GOV.UK Verify to verify their identity, and provide choice about what kind of evidence they want to use.

The bidder must list each of the datasets it proposes to use to fulfil elements A to E of the Identity Proofing and Verification (IPV) requirements, as defined in Good Practice Guide 45 and the IPV Operations Manual.

Each dataset will be scored against the following criteria:
• quality (a measure of how much the data can be relied upon as evidence about someone’s identity)
• timeliness - how frequently it’s updated
• longevity and median age - how long the data goes back historically
• volume - how many unique individuals are covered by the dataset

Once each dataset has been scored against these criteria, a combined score will be calculated using this formula:

Quality x (Timeliness + Longevity + Median age) x Volume.

We’ll publish detailed guidance on how to score datasets in the procurement documents.

This blog post is an introduction only; it’s not a formal part of the procurement process. The details will be set out in detail in the Contract Notice and that’s where interested parties should look for definitive instructions. We wanted to share our thinking now, as it's a new approach we've developed in the light of feedback we received at our market briefing event.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 02:42 #7413

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
How we're embedding the Identity Assurance Principles in GOV.UK Verify
Posted by: Toby Stevens, Posted on: 4 December 2014 - Categories: Policy

GOV.UK Verify is designed to preserve users’ privacy when they access digital services. The identity assurance programme’s independent Privacy and Consumer Advisory Group recognised the need for GOV.UK Verify to go further than the requirements of the Data Protection Act (1998), and has provided nine Identity Assurance Principles. These principles are intended to guide the operation of the service, both by government and the certified companies.

We’ve been working with the Privacy and Consumer Advisory Group to embed these principles in the way GOV.UK Verify is designed and built. We need to reflect the way the service is structured - a range of certified companies that people can choose from to verify their identity, working to defined standards, rather than a single supplier working to one technical specification.

The first contracts for certified companies were drawn up before the Privacy and Consumer Advisory Group had developed its principles. They therefore included a general requirement to cooperate with the Cabinet Office in the development and implementation of the principles.

We’re going into a second round of procurement for our next framework for certified companies, and as part of that we’ve included some more specific requirements in respect of the Identity Assurance Principles. These will cover data minimisation, user control, transparency and certification.

We also want certified companies to be clear and transparent about how they approach these important issues as part of their service, so we will require them to publish and comply with a privacy policy. Forcing one privacy policy on all certified companies runs the risk of ’one size fitting nobody’. That would be inflexible for users, and stifle innovation and diversity among certified companies.

Our proposed solution is similar to an approach used in the US, where the Federal Trade Commission (FTC) holds organisations responsible for living up to their own commitments.

Each company’s privacy policy must comply with relevant legislation and regulations in their sector, and they must also explain how they will embed the Identity Assurance Principles in their service. They will have to submit their terms and conditions and their privacy policy to the Cabinet Office as part of the requirements they need to meet before joining GOV.UK Verify.

Certified companies will then be held accountable for compliance with their own privacy policies. A breach of these commitments, or wilfully acting in a way that is contrary to the intent of the principles, would be treated as a breach of their contract with the Cabinet Office. This in turn will trigger remedies and penalties for the identity provider.

If the Privacy and Consumer Advisory Group needs to update the Identity Assurance Principles - for example, in response to changes in best practice, or to address a systemic problem - certified companies will need to update their privacy policies to reflect these changes.

This post is not part of the formal procurement process. More information regarding the next Framework Agreement will be included in the OJEU Contract Notice which is due to be published this month.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 02:43 #7414

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
Making sure we have a range of certified companies
Posted by: Janet Hughes, Posted on: 10 December 2014 - Categories: Industry and market engagement

This post is about how we’re going to approach the issue of sub-contractors in our next procurement. It gives an update on our approach based on feedback we received at our market briefing event in October. Full details will be published with our OJEU Contract Notice.

A diverse group of certified companies
GOV.UK Verify gives people a choice of certified companies rather than having one supplier or the government doing the verification work itself.

This approach gives people more choice and control over their personal data than if we were using a single supplier or if government were doing all the verification work.

We expect this approach to make GOV.UK Verify better for users (because it provides a range of options for them) and more resilient. We are expecting that it will also result in more investment, competition and innovation in the new and growing market for identity assurance services.

Given that the market for identity assurance services is still quite new, we need to make sure we encourage diversity and competition among the certified companies that are part of GOV.UK Verify. We want to establish a range of companies that provide identity proofing and verification services as part of GOV.UK Verify. We don’t want all the certified companies to rely on a much smaller number of sub-contractors to carry out the work involved in verifying people’s identity.

Restriction on the number of ‘material subcontractors’
For the next round of procurement, a single organisation will only be allowed to be a ‘material sub-contractor’ for a maximum of three certified companies. A ‘material sub-contractor’ is an organisation that assesses and analyses evidence and data to meet one or more of the 5 elements of the Identity Proofing and Verification process.

Other sub-contractors and suppliers
There will be separate rules for sub-contractors or data and attribute providers that are not carrying out the analysis and assessment of data that’s involved in identity proofing and verification work. These might include, for example, companies that provide data for certified companies to use as part of their identity proofing and verification work, or technology or other support services.

For these kinds of suppliers, normal contractual controls will apply: certified companies will have to notify the Cabinet Office and the Cabinet Office will have a right to object to a proposed subcontractor. We’re not specifically restricting the numbers of these other types of sub-contractors or suppliers.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 02:48 #7415

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
What it means to be a 'certified company'
Posted by: Janet Hughes, Posted on: 11 December 2014 - Categories: How GOV.UK Verify works, Policy, Standards and certification

This post is about how certified companies are assured as being safe for people to use as part of GOV.UK Verify.

When you use GOV.UK Verify for the first time to access a government service, you'll choose a certified company to verify your identity. The certified company will ask you for some information and check a range of evidence to establish that it’s really you.

This process involves the certified company asking you for personal data, and the certified company will be responsible for making sure it's really you each time you come back to use GOV.UK Verify to access a service. So it’s important to be able to trust your chosen certified company to protect your privacy and keep your data safe and secure.

There are four main ways that certified companies are assured as being safe for people to use. Certified companies have to be:
• certified by a certification body to confirm that they meet industry standards for information security
• certified by an independent body (such as tScheme) to confirm that they meet government standards for identity assurance
• compliant with the requirements in their contracts with the Cabinet Office
• compliant with data protection law

Certified against industry standards for information security
Certified companies must have appropriate information security management systems in place to look after people’s data and keep it secure.

They have to be certified to confirm that they meet an industry standard for information security management. This involves demonstrating that they have adequate processes in place to look after information securely and safely - how they set up, maintain and continuously improve an ‘Information Security Management System’ (ISMS).

Under the current contractual framework, the relevant standard is ISO27001, the international standard for information security management. In the next procurement we may accept other equivalent standards.

Certified against government standards for identity assurance
Certified companies also have to be certified by an independent certification body such as tScheme to assure that their service meets the published government standards for identity assurance.

The service auditors are accredited by the United Kingdom Accreditation Service (UKAS) for carrying out service assessments.

Compliant with contractual requirements
Each certified company operates under a contract with the Cabinet Office. The contracts set out the requirements the certified companies have to meet.

GOV.UK Verify is designed to protect people’s privacy and give people a secure way to access government services. We work according to a set of principles developed by our privacy and consumer advisory group. These include things like making sure people have a choice of certified companies, making sure they are in control of what happens to their data, and minimising the amount of data that’s collected and stored.

The identity assurance principles are reflected in the requirements certified companies have to meet. For example, certified companies are not allowed to use people's data for any other purpose without the person's informed consent.

Before they can join GOV.UK Verify, certified companies have to go through a number of contractual ‘gates’ - formal processes where the Cabinet Office assesses the service to make sure it will meet the requirements contained in the contracts.

We'll be launching our procurement exercise for a new contractual framework for certified companies shortly - see other posts we’ve published about ‘procurement 2’ for more information about that process. We’ve posted separately about how we’re making sure the new contractual framework reflects the identity assurance principles.

Compliant with data protection law
Certified companies are ‘data controllers’ under data protection law. They have to comply with all the relevant legal requirements about the storage and processing of data.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, comply or die, jobber

GOV.UK Verify 11 May 2018 08:52 #7418

  • Paul-UB40
  • Paul-UB40's Avatar
  • Administrator
  • Posts: 2818
  • Thank you received: 2535
A Great many Thanks BB; Hope this Information makes it clear to everyone B)
The administrator has disabled public write access.
The following user(s) said Thank You: jobber

GOV.UK Verify 11 May 2018 11:24 #7426

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
Paul-UB40 wrote:
A Great many Thanks BB; Hope this Information makes it clear to everyone B)
Thanks Paul.

Its beginning to look like we 'aint seen nothing yet.

Most of the people that are supposed to start using the service would not be able to anyway, even if they wanted to.

HMRC, have decided not to use the service, choosing to develop its own alternative.

Government Digital Service (GDS) the Government department in charge of the system, are trying to fob off responsibility for it onto the private sector

To which end they have initiated a competition for the service. Looks like even the grabbers of the private sector won't touch it with a barge pole without a substantial bung.

Confusion, desperation, panic. You couldn't make it up.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 11:29 #7428

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
Thousands of Universal Credit claimants unable to use Gov.uk Verify to apply for benefits
Bryan Glick Editor in chief of ComputerWeekly.com 31 Jan 2018


Government research shows that barely one-third of benefits claimants can successfully apply for new Universal Credit digital service using flagship online identity system

Hundreds of thousands of benefits claimants could be unable to register for the new Universal Credit (UC) digital service because of problems using the government’s online identity system Gov.uk Verify, according to new figures that show barely a third of UC users successfully use Verify.

The Universal Credit (UC) digital system, which is due to be introduced at all Jobcentres by the end of 2018, works on the basis that people applying for benefits will set up an account online and prove their identity electronically using Gov.uk Verify – either on their own computer or with assistance from Jobcentre staff.

But the Government Digital Service (GDS), which develops Verify, has revealed research showing that while 35% of UC users can set up a Verify account online, 30% are not able to, and the remaining 35% could use Verify, but do not.

“Further research at a job centre showed that out of 91 users, 48 needed help with the process,” according to the latest minutes from GDS meetings with the Privacy & Consumer Advisory Group (PCAG), a panel of independent identity experts who advise on Gov.uk Verify issues.

Further tests at the London Borough of Croydon showed that, even when claimants are given one-to-one support to help create a Verify user account, only one in five were able to successfully prove their identity online using the system.

“This highlighted two areas of concern – making people go to a venue where they were still unlikely to verify their identity, and the costs of the scheme,” said the minutes of the November 2017 PCAG meeting.

Verify uses publicly available data, such as passports, driving licences and credit histories, to prove that online users are who they say they are. However, since the system went live in June 2016, the majority of people attempting to register with Verify found they were unable to set up an account.

Digital footprint
Benefits claimants tend to have less of a digital footprint than people in employment, who are more likely to have mortgages or credit cards, and as a result Verify finds it harder to gather enough data to prove their identity. The new GDS research is the first time Verify figures have been published that are specific to the UC digital service.

Most of the 1.2 million UC claimants so far have used the original “Pathfinder” system, which handles only a limited number of benefit types and does not rely so heavily on Verify. It is being replaced by the digital service – now known as UC Full Service – which is being rolled out across the country and will be used for all new UC claims by the end of the year.

In the month to 14 December 2017, 77,000 people applied for Universal Credit, according to the Department for Work and Pensions (DWP). With the UC Full Service being introduced at, on average, 50 Jobcentres a month this year, hundreds of thousands of new claimants will soon be expected to use Verify as part of the application process. Based on the latest GDS figures, at least three in 10 people will not be able to do so and many more will struggle.

A telephone helpline is available to help apply for UC, and Jobcentre staff can also assist, but the expansion of UC Full Service assumes that the majority of claimants will prove their identity using Verify. If many thousands of people are unable to successfully use Verify to submit a claim, it is likely to cause significant extra work for Jobcentre staff.

A government spokesperson said: “GDS is constantly working to improve Gov.uk Verify to ensure it delivers the best possible service. We partner with teams from across government, such as DWP’s Universal Credit delivery team, jobcentre staff and user researchers, to find the most effective way to support with the use of Verify.”

Citizens Advice

A report from Citizens Advice in July last year warned that UC claimants were struggling to verify their identity online and lacked the digital skills to use the system. The charity called for UC roll-out to be delayed to resolve the problems it identified with the Full Service process.

“To apply for UC, claimants must first create a Verify account online, which proves their identity. While this account is useful for accessing a range of government services, it can create challenges for those claiming UC,” said the report.

UC is not the only service where Verify has been struggling. The Verify completion rate has been below 50% for most of its live use since June 2016 – meaning that less than half of all people who attempted to set up a Verify user were able to do so. The current success rate at the time of writing is only 54%.

Even for those users who manage to create a Verify account, only 48% are subsequently able to access the online public service they wish to use, according to GDS figures up to 14 January 2018.

Independent observers have called for Verify to be reviewed, claiming it has fundamental problems. The government has committed to having 25 million Verify users by 2020.

The Labour Party has also called for the government to rethink its approach to using Verify. Shadow Cabinet Office minister Jon Trickett said in October last year that the Verify programme was “being handled appallingly”.

“Not only is it inefficient and clearly failing, it also brings into question the security of citizens and the accountability of public services,” he added.

GDS hopes the private sector will adopt Verify to establish it as a UK-wide standard for online identity assurance, but concerns have been raised about GDS delays in publishing commercial rules that would allow companies to create Verify accounts and accept users that first registered to use government digital services.

GDS is also working to make Verify conform with EU digital identity standards so it can be accepted for use across Europe.

Universal Credit has also had a chequered history with its IT systems. The controversial welfare reform initiative suffered huge IT problems before the project was “reset” in 2013. A report at the time from the National Audit Office revealed that as much as £130m of IT work would be scrapped by the time the system was due to go live.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 11:33 #7430

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
HMRC rejects Gov.uk Ver
Lis Evenstad 14 Feb 2017 12:00


HM Revenue and Customs says it won’t be using Gov.uk Verify, which could cause difficulties for the government’s target of having 25 million Verify users by 2020.

HM Revenue and Customs (HMRC) has decided against the idea of using the Government Digital Service (GDS) developed Gov.uk Verify identity assurance platform and will instead only use its own identity service.

Rumours have long been rife that HMRC was reluctant to adopt Gov.uk Verify, with sources suggesting the department had no confidence in the system.

In fact, the department has been investing in its own identity verification service, based on the 15-year-old existing Government Gateway, which is used for individuals and businesses to submit their tax returns.

In a blog post, Mike Howes-Roberts, HMRC programme director for transforming Government Gateway, said when the current Gateway service ends in March 2018, it will be replaced by the departments own system.

“HMRC is developing its own identity system for individuals, businesses and agents,” he said. “Other departments will use Gov.uk Verify for all individual citizen services.”

Update: Since the publication of this article, HMRC has edited its blog post and removed the above statement. Computer Weekly has asked HMRC why it decided to remove it.

What’s changing?
Nothing immediately for users, but the current Gateway service is scheduled to come to an end by March 2018. From this date, Government Gateway will be replaced by new solutions, and HMRC is developing its own identity solution for individuals, businesses and agents. Other departments will use GOV.UK Verify for all individual citizen services.

An HMRC spokesperson said the blog had later been updated as it was "causing some confusion", and told Computer Weekly in a statement that the department "is committed to Verify as the single identification service for individuals and is fully focused on delivering this".

"The authentication service that HMRC is developing to replace the Government Gateway will complement the existing Verify service for business representatives," the spokesperson said.

Howes-Roberts also said in his blog that HMRC is “exploring options around other government departments” using the Government Gateway replacement service.

“This would be restricted to business and agent-facing services only as Cabinet Office requires all other departments to use Gov.uk Verify: the cross-government service for any citizen-facing services where customers need to prove their identity,” he said.

In an interview with Computer Weekly in 2016, GDS chief Kevin Cunnington said the reason HMRC had been reluctant to fully adopt Verify was because the department requires a lower level of assurance than Verify currently offers.

Verify is designed only for individual citizen identity, while HMRC also requires a business verification system to replace the Government Gateway system.

The two departments have been in talks “for a while” about how to merge the services further down the line, but HMRC now seems to have decided to go it alone.
Success of Verify’s user target in question

The rejection of Verify by one of the largest government departments is likely to cause issues for the government’s goal, set out in its recent transformation strategy, of getting 25 million users of the service by 2020.

To reach its ambitious target, government would require large departments with high-volume services to get on board with Verify – HMRC’s digital tax services being one of them.

The identity assurance platform, which went live in May 2016, works by asking users to set up an account with one of a selection of third-party identity providers, such as the Post Office, Experian or Verizon.

Each company then asks the user to prove who they are, using available data such as their credit history or by allowing electronic access to documents such as passports.

The Department for Work and Pensions (DWP) has also been reluctant to adopt Verify, but is now using the system for its new, digital Universal Credit system.

The government is also running a series of pilots with local councils, trialling two local public services – applications for older people’s concessionary travel passes and residents’ parking permits.

GDS is also trying to persuade banks and online gambling firms to consider Verify as a means to identify users

Computer Weekly has approached GDS, Cabinet Office and HMRC for comment. ... ... ...

Still waiting?
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 11:36 #7431

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
GDS wants to take 'hands off control' on digital identity, says Gov.uk Verify boss
Lis Evenstad 11 May 2018 10:00


Gov.uk Verify boss Nic Harrison says GDS wants to take its “hands off the controls” of identity, as he confirms target of 25 million Verify user accounts “won’t all be created by government”

Gov.uk Verify boss Nic Harrison says GDS wants to take its “hands off the controls” of identity, as he confirms target of 25 million Verify user accounts “won’t all be created by government”

The government wants to work with the private sector to grow digital identity creation and drive uptake of Gov.uk Verify as it aims to become a consumer of identity, instead of a provider.

Speaking at a media briefing during Sprint 18, Nic Harrison, director of service design and assurance, digital identity at the Government Digital Service (GDS), said the government is actively pursuing opportunities to “take our hands off the control” of identity services.

The government’s identity assurance platform has struggled with delays and low uptake, and identity experts have strongly suggested that Verify needs a major overhaul.

However, despite the problems, the government has been firm in its target to have 25 million user accounts by 2020. Although numbers have grown from 2 million users to 2.2 million users in a couple of months, and moved from 1.7 million transactions to 6 million in the past six months, Harrison conceded that the numbers “still aren’t stellar”, but that there is an “acceleration going on”.

It’s no secret that the government has struggled to get departments on board with Verify, which has led to tension, and some departments have taken matters into their own hands.

Computer Weekly previously reported that the NHS is creating its own identity platform, and HM Revenue and Customs (HMRC) is ploughing on with Government Gateway.

Harrison said there has never been any kind of fight going on between departments and GDS on Verify.

“That was never the case. It was more that there were very real reasons why departments found it hard to use Verify on its own, or to just switch to Verify. There were very sound operational reasons,” he said, adding that at HMRC, for instance, the online tax accounts platform is “one of the biggest generators of Verify identities”.

He added that the financial situation government found itself in after the 2015 spending review, “combined with Brexit now, means departments aren’t doing a lot of back-office transformation”.

“They’re worrying about EU exit, so we are frankly just not going to get hundreds of new services being digitised in the next year to bring on Verify.”

Work with private sector
So how does the government plan to get to its ambitious target of 25 million accounts by 2020?

“Those 25 million user accounts won’t all be created by government services, they will come from other places as well,” Harrison said, adding “that has always been the strategy”, but that it has become one “we’re now more actively pursuing”.

Under current arrangements, Verify works by asking users to set up an account with one of a selection of third-party identity providers (IDPs), such as the Post Office, Experian and Barclays. These providers currently have exclusive access to public sector users. However, this could all change in the future.

“What we are trying to do and what we’re discussing with our partners at the moment is more about what government can do to take its hands off the control,” Harrison said.

“At the moment, we have very strongly through the contractual arrangements controlled the use of accounts that are created. We want to stop having all that control, because ultimately the direction of travel for Verify, and in fact for digital identity more generally, is that we want it to be a thing that the government is a consumer of, not an owner and curator of.”

Interoperable identity hubs
Maintaining that this has always been the plan, Harrison said what the government wants “is a ubiquitous digital identity for service users both for public and private sector”, which would be “Verify compliant” by following a set of standards.

“In an ideal world, they would be truly interoperable. Interoperability and standards based is the key for us,” said Harrison.

He added that there are already lots of companies going down the personal data store type approach.

“What we would really like is everyone to coalesce around the same standards. Ultimately, the role of government, at least in the near term, is to be the arbiter of those standards so that we can all interoperate. If somebody was to set up their own hub and follow standards of Verify, then I would like to think they would be interoperable,” Harrison said.

“Obviously there are contractual arrangements we have with the current IDPs and we’d have to look at how you did that from a contract point of view. But certainly our end state is one or more hubs operating interoperably of which government just ends up being a consumer.”
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 11:38 #7432

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
Government launches GovTech competition
Lis Evenstad 10 May 2018 8:30


Implementation minister Oliver Dowden will launch competition for UK tech firms to help solve the country’s social challenges, using funding from the £20m GovTech challenge fund

The government has announced a competition for tech firms to come up with innovations that will improve public services.

The competition will be launched by implementation minister Oliver Dowden at the Government Digital Service’s (GDS) Sprint 18 conference on 10 May, and covers a range of challenges, including the data economy, healthy ageing, mobility and clean growth.

It is being funded using the £20m GovTech challenge fund, which was first announced by prime minister Theresa May in November 2017 as a way of encouraging better use of technology in the public sector, and connecting tech suppliers to potential customers in government.

This competition is part of a series of challenges, and tech companies can begin bidding for funding on 14 May for a period of six weeks, with subsequent competitions following over the next few months.

Those who are successful will be awarded up to £50,000 to develop their ideas, and those providing the “best potential solutions” will then be given research and development (R&D) contracts with up to £500,000 to create prototypes of their products, which will then be available for public sector buyers.

Dowden, who became the fourth minister in two years in charge of GDS, wants tech experts to find innovative ways of solving issues around loneliness and reducing plastic waste.

Commenting on the competition launch, Dowden said the government is “committed to providing more providing more opportunities for tech businesses – including small firms – to access public procurement contracts”.

The GovTech fund encourages firms to find innovative ways to fix the big social problems we all face – loneliness, plastic pollution and national security.

“Through emerging technologies, this fund will elevate British companies onto a global market while helping to deliver outstanding public services and improving lives for people,” said Dowden.

As part of his role as implementation minister, Dowden is also responsible for, cyber and resilience, shared services and the Crown Commercial Service (CCS).

He is also responsible for the Infrastructure and Projects Authority (IPA), the watchdog that monitors large government projects, including many IT and technology programmes.

According to a report published in June 2017 by investment firm Public, the GovTech sector could be worth £20bn by 2025, and the UK has the opportunity to be a market leader.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, jobber

GOV.UK Verify 11 May 2018 11:51 #7433

  • jobber
  • jobber's Avatar
  • Platinum Member
  • Posts: 1009
  • Thank you received: 1871
Top stuff Benefits Bolshie, i have also stumbled upon this little ditty o f info which may become quite useful in the near future when people are given the must do this share this sign this crap .

"Public authorities, employers and other organisations in a position of power :cheer: are likely to find it more difficult to get valid consent."

The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, Dizzy

GOV.UK Verify 11 May 2018 14:31 #7434

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
Gov.uk Verify and identity assurance - it's time for a rethink
The government's Verify identity platform is not meeting user needs - it's time to step back and review how best to make online identity for public services work.
Jerry Fishenden This was last published in May 2017


Gov.uk Verify, one of the UK government’s flagship digital programmes, set out with the best of intentions. It aimed to establish an identity assurance framework that could work across private and public sectors, facilitating a marketplace of trusted third parties to identify and authenticate users of online services.

Various problems however were highlighted by the March 2017 National Audit Office (NAO) report, Digital transformation in government , including that the Verify platform missed its original 2012 live implementation date by nearly four years. Nine of the 12 services available when Gov.uk Verify finally launched in May 2016 also offered alternative ways for users to identify and authenticate themselves, confusing the online experience for users.

Part of the problem is that the Verify platform only caters for individual citizens, failing to meet many other well-known user needs. It offers no support for example for intermediaries acting on someone else’s behalf (essential for everyone from those with Power of Attorney to accountants to carers), and nothing for business users either.

Even in the citizen space, Verify is currently proving difficult to use. It’s suffering from a high rate of failure when trying to identify citizens. Many users drop out of the process without success. When citizens who manage to get a Verify credential then try to use it with online government services, they can encounter additional problems. Departments often fail to match Verify data with the data they hold – no great surprise since government services typically hold citizens’ data in a different form to that used by the Gov.uk Verify commercial companies.

According to the NAO, in February 2017 Verify had just 1.1 million user accounts. This includes 185,000 “basic” accounts created as part of a trial in July 2015. These basic accounts are unverified and do not allow account holders to access live services. “User accounts” is not the same as “users” - citizens may have an account with more than one Verify identity provider. What these figures suggest is that by February 2017, some six years in, Verify had not even reached the one million user threshold.

Business case
The original business case for building the Gov.uk Verify platform relied upon the reasonable assumption that major departments, such as HM Revenue & Customs (HMRC), would make extensive use of it. However, HMRC has suggested that it will proceed instead with an earlier, alternative approach based around enhancing the existing Government Gateway service – which supports not only citizens, but intermediaries and businesses too.

Despite its original worthy aspirations, Verify is displaying the worrying and familiar symptoms of a troubled government programme. It’s running significantly behind schedule and de-scoped, and possibly over budget - although this is difficult to determine since, as the NAO report noted, “…before 2016-17 GDS did not split its staff costs into specific programmes”. Verify’s lack of support for anything other than basic citizen authentication - a small subset of known user needs for online services - means it offers no clear transition path from what is already in place.

It’s worth remembering that what we refer to as “Verify” is at least two things: an online identity assurance framework that establishes trust across private and public sectors; and the physical Gov.uk platform built by the Government Digital Service (GDS). The Verify framework is all about developing consistent, interoperable standards of trust, security and privacy across public and private sectors. However, the poor track record of the physical Gov.uk Verify platform is in danger of torpedoing the significant potential benefits that a trusted identity assurance framework could bring to the UK economy.

So why has Verify ended up in this confusing state – and how might it be fixed?

The timeline
In May 2011, Francis Maude, then minister for the Cabinet Office (MCO), expected implementation of Verify to happen in August 2012. This date came and went, and several more years passed. When the NAO recently reviewed the progress of the Verify platform it found numerous missed targets.

“In 2014, GDS expected over 100 departmental services to be using Verify by 2016. In October 2016, GDS predicted that 43 services would be using Verify by April 2018. In February 2017, 12 services were using Verify. None of the nine services that were in the pipeline for connecting to Verify during the remainder of 2016 was ready to do so by that date,” said the NAO report.

Verify formally entered live service in May 2016, having appeared as a beta service in October 2014. By the time of its live implementation, Verify was nearly four years behind schedule and working with just 12 services. Most of these 12 services also offered alternatives to Verify.

As the NAO report commented: “Nine of the 12 services using GOV.UK Verify can now be accessed using both Verify and a department’s chosen way of allowing users to log-in to services. This parallel access undermines the current business case and risks creating confusion for service users.”

Far from helping improve the user experience of online services, Verify’s failure to provide trusted identity assurance across government services has resulted in the fragmentation of the user experience – the very opposite of what it originally set out to achieve.

The NAO report observed: “To achieve the target of 25 million users by April 2020, GDS needs the profile of users to increase at a much sharper rate from April 2019. The September 2015 business case predicted 4.4 million users by the end of March 2017. This projection was reduced to 1.8 million in the October 2016 business case. As of February 2017, Verify had 1.1 million user accounts.”

Poor discovery
Neither the Gov.uk Verify platform or the desire for a cross-sector identity assurance framework were created on a blank page. They had the significant advantage of entering an existing services environment where many lessons had been learned about online identity. Since 2001, for example, the Government Gateway has provided the primary means for users to authenticate themselves to a wide range of online government services, from self-assessment to the state pension forecast.

As the NAO report notes: “[The] Government Gateway currently hosts 138 live public sector services, and the Gateway is being improved. GDS has not reassessed the cost and security implications of an improved Gateway service.”

The Government Gateway was designed, like Verify, as a federated identity hub – as Mike Bracken, the former boss of GDS, acknowledged in November 2011 in a blog post titled Establishing trust in digital services. The Gateway was created to support a marketplace of trusted third-party identity providers who would carry out the process of identifying and authenticating users, and manage their credentials. For this reason the Gateway supported not only its own user IDs and passwords, but also third-party digital certificates and chip-and-PIN cards, using open standards such as SAML and W3C digital signatures.

Most of the problems with delivering the Gov.uk Verify platform are indicative of an apparent failure to follow GDS’s own guidance. In particular, a failure at the discovery stage to understand what had previously been tried (and failed), what was already in use (both good and bad), and what user needs Verify would have to meet if it were ever to become a viable means of large-scale user identification and authentication. However, there appears to have been little or no systematic attempt to understand the existing landscape. As a result, it lacked the necessary situational awareness.

HMRC, for example, has made use of the Government Gateway’s identification and authentication services – for citizens, intermediaries and businesses – since 2001. Both HMRC and other departments have learned a lot about what does – and doesn’t – work when it comes to online user identification, authentication and verification, and the related problems of data-matching, in the intervening years. As a result, there were already many important insights and lessons the Verify platform team should have tapped into, enabling them to accelerate and focus their efforts, and avoid repeating the mistakes of the past.

Use of APIs
HMRC and others also make extensive use of application programming interfaces (APIs), which let computer systems talk to each other, to interact with the outside world. It is unclear whether Verify works only for users logging into online government websites, or whether it can also be used where an external system needs to interact with a government department programatically. Existing Government Gateway APIs enable, for example, employers’ payroll and accounting services to make secure submissions to government signed with the user’s credentials, and to receive responses.

This apparent lack of focus on how Verify can be used with APIs for interacting with government services is surprising. APIs were a principal recommendation of the original Martha Lane Fox proposals (PDF) in her 2010 report that brought about the creation of GDS. The associated executive summary included a target that 50% of government services should be served by third parties via APIs by March 2012.

However, the recent 2017 NAO report found that: “GDS has only recently published guidance on using application programming interfaces (APIs) to link administrative systems, despite an emphasis on APIs when GDS was first set up.”

It remains unclear why Lane Fox’s recommended implementation of APIs across government for third-party provision of services didn’t happen. The emphasis instead seems to have been on front-end, website-based development instead. There is still no timetable for the opening up of APIs despite this being a key outcome set out in Francis Maude’s response to Martha Lane Fox, and its relevance to making better use of data.

Among the discovery steps described in GDS’s own guidance, the Verify progamme seems to have skipped at least the following:
• You should find out … your users’ needs and how you’re meeting them, or any needs you’re not meeting
• Which services currently meet your users’ needs and whether they’re government services or private sector
• How you’d start developing a new service if your discovery finds there’s a user need for one

Even within the subset of user needs it does propose to meet, Verify continues to experience significant problems with citizens’ initial registration and their subsequent re-use of their account(s). These problems are likely to be worse for those who do not have “recognised” or “acceptable” official documentation such as passports or driving licences, or other “established” forms of financial status – exacerbating existing problems of digital social exclusion from often essential public services.

Verify’s notably slow development and implementation is particularly surprising given it only tackles a subset of user needs. Yet after six years it’s struggling to meet even these simplified and de-scoped needs. This compares particularly unfavourably with the Government Gateway which was designed, built and operational in live service in just 15 weeks – despite meeting a demonstrably larger suite of user needs than Verify. It’s another reason why it lacks credibility with departments.

This slow progress with delivery and the continuing lack of functionality suggests a poor use of the agile processes recommended by GDS. When applied well and with discipline and rigour, agile can enable rapid delivery of functionality at both pace and at scale.

Given the Gov.uk Verify platform team had the advantage of tapping into all the experiences of federated identity and cross-departmental identity requirements accumulated across government and the private sector since 2001, it’s unclear why the Verify platform has ended up running so late and de-scoped.

The danger is that all of these problems with the physical Verify platform will undermine the more important work that aims to develop and establish a trusted identity assurance framework. It’s important that these two aspects are kept apart when considering “Verify” – it would be a major opportunity lost if moves towards a successful framework that spans public and private sectors were lost because of difficulties with the poor scoping and performance of the Gov.uk Verify platform.
Verify and federated identity

Federated identity usually involves using an existing trusted relationship to prove who you are to another party – such as when we use a UK passport to prove who we are when crossing a border; or a chip-and-PIN, or contactless, bank card to authorise payment to a retailer.

The original idea behind the Verify identity assurance model was that we should be able to prove who we are online when using government services using a trusted third party with whom we already have an existing relationship. For example, you turn up to do self-assessment online and prove who you are using a chip-and-PIN card issued by your bank or building society. A good, simple user experience (if we set aside the notable problems of reliable data-matching for a moment).

This is not what Verify currently does – and where it diverges from a trusted identity assurance framework.

Verify requires citizens to establish a brand new relationship with a commercial organisation with whom the citizen has no prior relationship - and probably no particular desire to have such a relationship. In creating this imposed relationship with a chosen commercial provider, the citizen is obliged to disclose a wide range of personal information. Such data include for example some or all of:
• full name
• date and place of birth
• full postal address
• email address
• telephone number
• passport number
• driving licence number
• marriage certificate
• birth certificate
• bank account details
• type and numbers of credit cards held
• mortgage details
• length of time at current address
• loan details

If a citizen gets through this whole process successfully, the commercial provider will maintain the citizen’s credential - typically a user ID and password. This new commercial provider now controls a user’s online authentication and access to government services.

This approach is not the one originally envisaged for the identity assurance framework. The original idea was that citizens should use a trusted third party with which they already had an existing relationship – and which could therefore provide assurance about their identity.

Instead, an artificial marketplace of commercial entities has been nurtured and paid for by the Verify platform. These new third parties have effectively been given an exclusive mandate as commercial gatekeepers of citizens’ access to online government services.

This approach also breaks one of the sensible “laws of identity” set out by Microsoft identity architect Kim Cameron many years ago. It inserts a brand new third party between citizens and government which has no obvious place in that relationship. Given all the political sensitivities about “privatising public services”, it’s unclear when the Verify platform team made the decision to insert and mandate commercial organisations as the monopoly controllers of authenticated citizen access to online public services.

In its current approach, the Verify platform has either by intent or by accident resurrected a mandatory sort of Microsoft Passport for government services. It has artificially inserted a new commercial organisation into the relationship between a citizen and their online government services, requiring citizens to hand over a considerable amount of personal information to third parties in the process.

Given that this was not the original vision or intent, it’s important to get the work on a trusted identity assurance framework back on track.

Policy questions
The government is understandably keen to promote the increased use of online services. Establishing a credible, reliable and trusted identity assurance framework that can work across private and public sectors, and enable us to prove who we are online, is an important ambition. Getting this right is a precursor to many other important developments, such as being able to get access to and control over our personal data – and to protect it from unauthorised or fraudulent access.

However, the physical implementation of the Gov.uk Verify platform and the aspirations of the work on an identity assurance framework seem to have drifted apart. The Cabinet Office’s Privacy and Consumer Advisory Group (PCAG) has aimed to ensure that the extensive and detailed personal information required by the commercial providers contracted by Verify cannot be misused, through the Identity Assurance Principles (PDF). However, the design and associated commercial arrangement raise numerous and significant policy questions about the Verify approach, including:
• Why and when was the policy decision taken that online government services requiring authentication can only be accessed by citizens via a commercial company with whom the citizen has no prior relationship?
• Why are commercial organisations being paid to vouch for “identity” when many of the checks they carry out, such as validating passport and driving licence numbers, actually use services that government itself provides and which it can use itself without any payment?
• What happens if a citizen refuses to hand over their personal data in order to use one of those commercial service providers, but still wishes to have access to online government services? Will they be unable to use online public services?
• What happens when a commercial provider exits from the Gov.uk Verify marketplace? Will a user have to start from scratch and go through all the same data-invasive and departmental data-matching steps again with another company?
• Given that departments and other public sector organisations still need to carry out their own assurance checks to match citizens accurately to the right records and data, what additional value is currently provided by the third-party identity providers?

The true costs are unclear
The charges imposed by the commercial providers for Verify have not been made public due to issues related to “commercial confidentiality”. However, informally people close to those running the services, both inside government and at the commercial providers, indicate that the charges made by the companies range from around £9 to over £20 per user.

At the moment, departments and other organisations using Verify services are having their costs heavily subsidised by the central budget GDS secured for the current spending period. As a result, they contribute only £1.20 per successful confirmation of identity per user per year, regardless of the actual cost to the taxpayer.

It’s unclear what will happen if departments and others using Verify cease to have their costs centrally subsidised in the future – as implied by the NAO report, which said: “Verify is expected to become self-funding in 2018-19. Of the £53m decrease in GDS’s funding between 2017-18 and 2018-19, two-thirds (£36m) relates to removal of revenue programme funding for Verify.”

If this is the case, public sector organisations planning to use Verify must allow for significant additional costs from their own budgets as the central subsidies are reduced or entirely withdrawn. Based on the rumoured actual costs of Verify, this could be anything between seven times and 17 times, or more, than the £1.20 they currently pay.

Behind schedule – and a poor user experience
Some six years since its inception, the Gov.uk Verify platform is struggling to establish itself as a viable service. This failure is having knock-on consequences. According to government insiders, Verify’s poor performance and lack of departmental buy-in is undermining the more important work underway to establish a trusted identity assurance framework able to work across both private and public sectors.

Meanwhile, many users’ experience of Verify remains poor, and they fail to prove their identity to the commercial providers. Verify’s own performance dashboard shows that just 55% of users succeed either in creating an account, or in re-using an account they have already created. The service dashboard reveals that only 44% of those users then “successfully access a service, following the creation or re-use of a verified account with a certified company”.

If these figures are correct, it implies that of the 55% of users who actually manage to create an account only 44% of those then successfully access a service. Does this mean only around a 24% overall success rate - that only 44% of the 55% of users who create an account are successful? It would be easier to understand the true situation more clearly if the published data were clearer – and did not bundle multiple aspects, such as “creating an account, or re-use of an account”, together into the same statistic.

Despite these figures, the Verify team remain optimistic and claim it will be mainstream by 2020 – the government transformation strategy set a target of 25 million users. This will be 10 years after the programme started, and after many similar repeated promises of imminent success. By 2020 Verify will be older than the “legacy” Government Gateway was when the Verify programme started and, based on current plans, still lacking essential functionality.

Time for a reset
It’s time that the Verify platform, other “competing” initiatives such as the updated Government Gateway, and the underlying work on an identity assurance framework are subject to an open, honest and fundamental reset. A significant amount of money, time and resource have been sunk into the Verify platform in particular, but without delivering the results desired or the success repeatedly promised.

The NAO report set out a series of high-level recommendations for the Gov.uk Verify programme, emphasising the importance of establishing a clear case; adequate early analysis or “discovery”; and a consideration and assessment of options.

GDS needs to follow the principle of “physician, heal thyself” and rigorously apply its own guidance to itself – from a fundamental and honest re-appraisal of user needs and a thorough (re)discovery process, through to a fundamental review of the original business case and the assumptions it made.

It’s important that the opportunity for a trusted identity assurance framework that spans private and public sectors is not lost on the back of the problems facing the Verify platform. If the Verify platform were a departmental programme, it would likely have failed the GDS spend controls implemented by Liam Maxwell when he was government chief technology officer.

GDS needs to apply the same discipline to its own programmes that it expects of others. This type of delayed and de-scoped programme is a world away from the welcome vision of improvement and success that GDS once promised – and is certainly not providing world-class digital products that meet people’s needs.

During this reset, government should look to:
• Revisit the fundamental question, “What is the problem we are trying to solve and how best might we do it?”
• Revisit its identity assurance policy requirements, including whether it is appropriate for Verify to mandate commercial third parties to (a) be the exclusive gatekeepers of access to online government services and (b) the controllers of users’ credentials
• Undertake a full discovery of user needs, including those previously neglected, missed or overlooked
• Thoroughly map all existing identity initiatives and technologies across both government and the private sector, and then plot these against user needs to identify matches and gaps
• Consult on and define a clear, cross-sector identity assurance strategy and related standards - work which needs to integrate closely with a related, but currently absent, data strategy and set of standards - including analysing the impact of various options on digital social exclusion
• Validate and ensure that any proposed identity solution will be able to work with APIs as well as browser-based services
• Undertake a full, and public, privacy impact assessment (PIA) of alternative options, and involve the Cabinet Office’s Privacy and Consumer Advisory Group closely in oversight and feedback on proposed options and solutions
• Bring together key players such as HMRC, GDS and other public and private sector bodies to openly explore existing services and best future options (without getting hung up on the various favoured projects already in play), including short-term and longer-term costs
• Apply the principles of “cloud first” and “buy before build”, exploring how the identity assurance framework might be better and much more quickly delivered via commodity cloud-based identity-as-a-service (IDaaS) options, rather than continuing bespoke work on in-house pet projects
• Consider separating the creation and control of users’ credentials from the identity assurance processes operated by the third-party commercial providers. Management of credentials has become a commodity service in the cloud, as illustrated for example by Kim Cameron’s work on the “identity experience engine”. Government could allow all users (citizens, businesses and intermediaries) to manage their own credentials, either via an IDaaS and/or the updated Government Gateway service as enhanced by HMRC, removing third parties from controlling users’ credentials while still being part of an overall trust framework
• Consider the benefits of moving the online identity proofing service provided by the Verify platform third parties elsewhere in the process. If external identity proving is required by a public sector organisation it should only take place when needed by a service owner rather than being placed right up-front
• Review whether the hub-based approaches employed by both the Government Gateway and Verify platform, with the known security and privacy concerns of hub-based models, could be superseded by more secure technical solutions
• If desired, keep the overall Verify brand. Use it for whatever comes out of the discovery, reset and redesign process

Francis Maude, when he was minister for the Cabinet Office, used to comment that becoming a “prisoner of sunk costs” – throwing more money at a problem solely because a lot of money has already been spent on it – is almost always a mistake.

Making the hard decision to do a fundamental review and reset of identity assurance and the various competing approaches and platforms is the right thing to do. The viability of online services and establishing digital trust between public and private sectors is dependent on getting this right. It would also represent a welcome return to GDS’s original principles of working in the open, being transparent, and learning from mistakes.

We urgently need to see credible leadership and a viable strategy in this essential area. It’s important for the future of online services that government helps nurture a robust, trusted, secure and viable approach to identity assurance that can work right across our digital economy. So it’s worth making time right now to do an honest, open and public reset to get this right – returning to GDS’s idealistic first principles of delivering world-class outcomes that meet people’s needs.
The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40

GOV.UK Verify 11 May 2018 16:17 #7439

  • Benefit Bolshie
  • Benefit Bolshie's Avatar
  • Platinum Member
  • Posts: 414
  • Thank you received: 728
I would suggest that there is more than enough material in the preceding posts to justify to even the dumbest of dumb work coaches that registering on the GOV.UK Verify service without your full consent would not only be illegal but foolhardy.

It would be remiss of me if I didn’t acknowledge at this point the excellent journalism at Computerweekly.com upon which I drew for many of the articles included in this thread and also for continuing to monitor and expose the sheer inadequacy of GOV.UK Verify that might very well have otherwise remained hidden from public scrutiny.

It might be helpful in bringing about the downfall of this service before it even starts if members who are active on other forums could post this link:

The administrator has disabled public write access.
The following user(s) said Thank You: Paul-UB40, comply or die