OSA phase 3: user identity verification
In the fourth in our series of explainers on the draft OSA Phase 3 proposals published by Ofcom for consultation, David Babbs from Clean up the Internet looks at Volume 2 (user identity verification tools).
Introduction
The draft User Identity Verification Guidance is issued under section 65 of the Online Safety Act 2023 (the “Act”); its proposed Code measure ADU A8 (found here) on filtering out non-verified users, implements section 15(9).
This explainer describes the statutory duties and Ofcom's proposals.
What the Act requires
Section 64(1) of the Act requires Category 1 providers to offer all adult UK users the option to verify their identity, where verification is not already required to access the service. Verification is optional for the user. Section 64(2) provides that the verification process "may be of any kind (and in particular, it need not require documentation to be provided)". Section 64(3) requires providers to "include clear and accessible provisions in the terms of service explaining how the verification process works".
Section 65(1) of the Act requires Ofcom to produce guidance "to assist [providers] in complying with the duty set out in section 64(1)". Section 65(2) directs Ofcom, in producing it, to "have particular regard to the desirability of ensuring that providers of Category 1 services offer users a form of identity verification likely to be available to vulnerable adult users". That is the only substantive constraint Parliament placed on the content of the guidance. Note that section 65 requires guidance, not a code of practice.
Section 15(9) of the Act is a duty "to include in a service features which adult users may use or apply if they wish to filter out non-verified users". Section 15(10) specifies that those features are ones which, if applied, result in systems or processes "designed to effectively" (a) "prevent non-verified users from interacting with content which that user generates, uploads or shares on the service", and (b) "reduce the likelihood of that user encountering content which non-verified users generate, upload or share on the service". Ofcom refers to these as the "preventing interaction" and "reducing encountering" outcomes [Volume 2, 10.2].
Section 16(7) of the Act defines a non-verified user as a user who "(a) is an individual, whether in the United Kingdom or outside it, and (b) has not verified their identity to the provider of a service".
Ofcom's proposed section 65 verification guidance
Three approaches considered
In considering what guidance to give to providers on the nature of identity verification required under the legislation, Ofcom considered three possible approaches: a prescriptive approach that would specify what attributes of an individual identity must be verified and by what method (Option 1); "a minimum standard approach where we specify the set of attributes that providers should verify in all cases, but allow flexibility for the methods used to check them (Option 2)"; and "a flexible, principles-based approach where we do not specify which attributes to check and how they are checked but set out principles that the process should be consistent with, and provide examples (Option 3)" [Volume 2, 11.35]. Ofcom chose Option 3.
Throughout the consultation, "attributes" means the pieces of information about a user which a scheme verifies - a name, a date of birth, a photograph, a contact detail. Ofcom defines identity verification as a process whereby a user verifies "the process of the provider verifying the attributes that form a user's identity on a service, to a level that the provider is confident that the identity belongs to the individual who is a user of the service." [Guidance, 2.11].
Ofcom gives four reasons against the prescriptive approach. It would not let providers adapt verification to the nature of their service, and Category 1 covers services with differing functionalities, purposes and user bases; permitting no flexibility could also make it more likely that vulnerable users and those with protected characteristics are excluded [Volume 2, 11.37]. It would be "extremely challenging, potentially impossible" to decide a common set of attributes for all providers, a point Ofcom works through using the example of real name: users adopt abbreviations and pseudonyms for legitimate reasons, names change, professional and documentary names differ, and verifying a real name is likely to require official documentation with consequent inclusivity concerns [Volume 2, 11.38]. There can be several methods of checking any given attribute and it would be difficult to justify choosing one, since a more reliable method may be more likely to exclude vulnerable users; Ofcom adds that this particular difficulty "could be mitigated" by specifying attributes alone and leaving methods to providers, which is Option 2 [Volume 2, 11.39]. Finally, a prescriptive approach would be less future-proof as digital identity develops [Volume 2, 11.40]. Ofcom acknowledges that the prescriptive approach would give providers the most clarity about how to comply [Volume 2, 11.36].
Ofcom's reasoning against Option 2 is brief. It accepts that the approach would give providers clarity about which attributes must be verified while preserving flexibility over method, and that it would be more future-proof than the prescriptive approach [Volume 2, 11.41]. A single disadvantage is given: "the difficulty in deciding the common set of attributes that all providers would check as part of the verification process, as outlined at paragraphs 11.38 and 11.39" [Volume 2, 11.42]. No further reasoning is offered, and the two cross-referenced paragraphs are those summarised above in relation to Option 1. Ofcom concludes that, given the diversity of services in scope, the complexities of identity verification and the potential for change in this area, neither the prescriptive nor the minimum standard approach is appropriate, and that Option 3 strikes the best balance [Volume 2, 11.46]. In reaching that view it accepts that Option 3 "could be seen to provide less clarity to providers as to how to comply with the duties compared to the other two options" [Volume 2, 11.45].
One feature of the appraisal should be noted at this stage. All three options are defined by reference to the same variable: Option 1 specifies both the attributes a provider should check and the methods used to check them; Option 2 specifies the attributes but not the methods; Option 3 specifies neither [Volume 2, 11.35]. The question the appraisal asks is therefore how much of the attribute-and-method question Ofcom should settle centrally. Standards expressed as properties of a verification scheme, rather than as attributes of individuals to be checked or methods for checking them, do not appear among the options considered.
Providers set the purpose of their scheme
Having chosen Option 3, Ofcom builds the Guidance on the recommendation that "it is important to first decide the purpose(s) of the scheme, that is, what the scheme sets out to do and how it will do it", taking into account the nature of the service, its user base, functionalities, how it is used, and the type and levels of risk present [Guidance, 3.4]. Everything downstream is then judged against that self-selected purpose. Ofcom's reasoning is that "it is appropriate for providers to decide what purpose(s) their verification scheme serves, rather than Ofcom setting this out", because "there are a range of reasons identity verification might be offered on a service, and the purpose will depend on the nature of the service", and providers "would be better placed than Ofcom to determine the purpose(s) for their scheme to ensure it benefits users on their service" [Volume 2, 11.60]. While Ofcom does suggest things platforms take into account when deciding their purpose, it does not anchor these considerations in key documents such as the Illegal Contents Risk Assessments, nor require that the scheme addresses risks or improves safety, nor set a minimum level of ambition for the scheme.
The four principles
Once a purpose is identified, Ofcom recommends that providers "design, operate and communicate their verification schemes" consistently with four principles [Guidance, 3.1]: "relevance", "reliability", "inclusivity" and "clarity" [Volume 2, 11.56]. Each principle carries a set of recommended practical steps, summarised at Table 1 of the Guidance. All four are applied back to the purpose the platform has itself chosen, and compliance is assessed against taking the steps rather than against any outcome: Ofcom says that in considering whether a provider has complied it "will take into account whether it has acted in accordance with this guidance", and encourages providers to document how they have done so [Guidance, 2.7]. Each principle is described in turn below.
Relevance
The attributes checked must be "relevant to the purpose(s) of the verification scheme" [Guidance, 3.1], on the terms set out at Guidance 3.7 and 3.9, quoted in the previous section. They "should be sufficient in number and significant enough in nature when combined to tell the provider something meaningful about the individual, be able to be linked back to an individual user of the service, and reflect how people use the service" [Guidance, 3.7]. They "should also align with what users would expect to be verified based on how they use the service" [Guidance, 3.9]. Data collection must not exceed what the purpose requires. Ofcom is explicit that mismatched attributes create a misleading signal: users who take verified status into account "may be doing so based on a misunderstanding" [Guidance, 3.8]. Data minimisation applies, so providers should not gather more attributes than the purpose requires [Guidance, 3.10].
Reliability
The scheme must be reliable "so that providers can have confidence that users actually have the attributes they claim to have, and users have confidence in the process" [Guidance, 3.1]. Four practical steps follow. First, no self-declaration: providers should check claimed attributes "against a source separate and independent from the user claiming the attribute" [Guidance, 3.13], accepting an attribute only where the source is reliable and they are sufficiently confident [Guidance, 3.14]. Ofcom lists indicators of a reliable documentary source, and mentions but does not mandate digital verification services (DVS) certified under the UK's DVS trust framework, the government's certification regime for organisations that carry out identity checks [Guidance, 3.15]. Second, anti-circumvention: providers should identify and mitigate misleading techniques "easily accessible to users", such as impersonation, faked attributes and the buying and selling of verified accounts [Guidance, 3.18]. A reliable check "should not be capable of being easily circumvented" and should be able to detect falsified documentation or manipulation, including AI-generated forgeries [Guidance, 3.19]. Third, where a user changes a verified attribute in a way that suggests a risk of harm, re-verification may be required, and verified status should be removed where a user declines or fails to re-verify [Guidance, 3.21 to 3.23]. Fourth, currency: attributes go stale, so providers should consider "offering users the option to verify regularly or make clear to other users when the user was last verified" [Guidance, 3.25].
Inclusivity
The process must be inclusive "so that no adult user is unduly excluded from being able to verify" [Guidance, 3.1]. The statutory anchors are that verification need not require documentation, and the section 65(2) regard to vulnerable adult users [Guidance, 3.26]. Ofcom treats inclusivity as covering both process and outcome [Guidance, 3.29], and identifies two failure modes: over-reliance on official documentation, which excludes those without access to it, including homeless people, Traveller communities, ethnic minority groups, carers, and those who are educationally or economically disadvantaged, who would then be shut out of the benefits of verification - among them, escaping the section 15(9) filter [Guidance, 3.32 fn33]; and bias in the method itself, with Ofcom explicitly naming "a lower degree of technical accuracy or reliability for users of a certain ethnicity" in facial recognition [Guidance, 3.31]. The practical asks are to consider whether government ID is necessary for all users, to offer alternatives in limited cases that do not require it, and to offer more than one method where possible [Guidance, 3.33, 3.35], with tax or benefit documents and vouching given as illustrations [Guidance, 3.34]. On cost, "the Act does not prohibit a provider from levying any charge for verification. However, if a provider chooses to require a charge, they should be able to demonstrate that it is small enough so it does not unduly exclude low-income or otherwise financially vulnerable users. The scheme being free would guarantee that it is accessible to all users" [Guidance, 3.37]. Notably, Ofcom accepts that the tension between reliability and inclusivity may be irresolvable and leaves providers to "use their judgement on the best balance to strike" [Guidance, 3.36].
Clarity
The process must be clear "so that users understand what identity verification means in practice on the service" [Guidance, 3.1]. This has two parts. The first is the statutory terms of service duty under section 64(3), where Ofcom imports the four sub-principles used in its other Codes, covering findability, layout, language and useability [Guidance, 3.40 to 3.41]. The second, which goes beyond the statutory text, is that the process should also be explained at the point verification is offered, Ofcom's rationale being that between half and two-thirds of users report signing up without accessing or reading terms of service [Volume 2, 11.97]. At that point providers should explain "the purpose(s) of the scheme, including which attributes the provider has chosen to verify, how these are relevant to the purpose(s) of the scheme, how they will be checked, and if that process may involve sharing information with third parties", and that verification involves submitting information to the provider "and not to other users" [Guidance, 3.43].
Separately, providers should explain what being verified actually means: the implications of not verifying, including being filtered out under section 15(9); any benefits accruing to verified users, such as promotion by recommender systems; which visible attributes have in fact been verified; and that verification "happens at a specific moment in time" so its reliability will likely decrease [Guidance, 3.47]. Incentives to verify are permitted, but users with valid reasons not to verify should not be given "an unduly degraded experience" [Guidance, 3.48]. Where verified attributes are not displayed, users may change displayed details without re-verifying, in which case it "should be made clear that the displayed attributes are not verified" [Guidance, 3.53].
Ofcom's proposed Code measure for the section 15(9) filter on non-verified users
Measure ADU A8 of the draft Additional Duties Code of Practice for Category 1 Services covers filtering out non-verified users. It repeats the wording of the Act, and then qualifies the requirement in a couple of respects. Firstly, it states that the requirement applies only "so far as technically feasible to achieve that outcome in relation to the service" [Code, ADU A8.4]. Secondly, it states that in deciding which functionalities the tool applies to, the provider "should ensure that the application of that feature or features to those functionalities will: (a) benefit adult users, in particular by improving user safety; and (b) not materially interfere with the core offering of the service" [Code, ADU A8.5]. Ofcom does not define "core offering" in the Code, though in Volume 2 10.7(b) it glosses objective (b) as implementing the filter "in a way that avoids undue impacts on a service's intended use(s) or user experience". Both objectives are self-assessed.
Ofcom makes two highly consequential choices in its interpretation of Section 16)7) which defines a non-verified user as a user who "(a) is an individual, whether in the United Kingdom or outside it, and (b) has not verified their identity to the provider of a service". Firstly, because a non-verified user is defined by the Act as an individual, as Ofcom puts it, "businesses and other organisations do not need to be filtered out" [Volume 2, 10.4]. And secondly, because the 16(7) definition makes no explicit reference to section 64, Ofcom concludes that users verified under schemes other than a section 64 scheme may count as verified for filtering purposes. The first point seems to have a stronger statutory basis than the second.
What implementation could look like
Ofcom leaves providers wide latitude over the form the tool takes as well as its reach. A provider "could choose to offer a single feature that achieves these two outcomes", or "may alternatively choose to give users more choice by offering different features that affect different functionalities or parts of their service", or "may also offer users a more granular choice over which functionalities they can apply the filter tool to" [Volume 2, 10.6]. Only "[w]here a user chooses to apply all the features offered" must both statutory outcomes be achieved. As drafted, then, the filter tool may take the form of a set of separate switches rather than one, with the two statutory outcomes achieved in full only for a user who enables all of them.
Features may be content-level or access-level. Content-level examples are "giving filter tool users the option to disable comments from non-verified users on their content, or hiding individual pieces of content posted by non-verified users". Access-level examples include "notifying a user that they are about to access a part of the service containing content posted by non-verified users and/or rerouting direct messages from non-verified users to a separate inbox, giving them the option to read those messages, or not" [Volume 2, 10.9].
Ofcom offers four illustrative examples "of what compliance could look like" [Volume 2, 10.14]. Two describe circumstances in which a provider narrows the range of material that will be filtered. In one, a video-sharing platform declines to bring liking a video within the filter while allowing filtering of reposting, on the basis that the "'like a video' functionality has not been identified as a vector for hate or abuse". In another, a crowd-sourced encyclopaedic platform declines to apply the filter to search: the provider "has decided it does not have evidence of the search functionality being used to enable harm to users on its service", and considers that exclusion "would represent a fundamental and therefore disproportionate change to the core offering of the service". It instead adopts the substitute of a click-through overlay warning filter tool users that an article was written in whole or part by non-verified users.
