What guides us at OneID® to design our solutions the way we have? Why do we care so much about privacy? Most importantly, how do we put in place privacy-enhancing measures to protect personal data? As I take you through the ins and outs of OneID®, these are the aspects I'll answer in this blog. I’m Stuart Kempster, Chief Product Officer at OneID®, and this is part 3 of ‘What’s under the OneID® bonnet?’
Need a recap?
In part 1, I shared how OneID® works and what makes it effective.
In part 2, I focussed on what makes OneID® trustworthy and reliable.
Now, on we go.
If you’ve stayed with me this far, you will probably have already figured out that we develop and manage OneID® solutions against a set of design, operating and governance principles. These will continue to guide all future OneID® product developments.
OneID® has been designed from the ground up as an identity service, custom-built for the UK market. The principles borrow from the thinking that went into successful digital ID schemes from around the world, such as the bank IDs in the Nordics, but have been adapted to fit with the UK’s particular history and culture with identity.
It also stems from our company values as a B Corp.
Our principles are:
The last principle is particularly important to us. When we say ‘privacy by design’, we mean it.
A double-blind to enhance privacy
The OneID® privacy model is designed with the GDPR's data protection by design and default principles in mind. It minimises the amount any party knows about what the user is doing while still enabling traceability (and, from that, accountability) back to the user if required.
OneID® has a privacy-enhancing model that is a ‘double-blind’ between the ‘relying party’ and the bank (neither party knows who the other is). We don’t store or monetise data —it stays with the bank. OneID® stores the consent for the data attributes that are shared from the bank but never the actual data.
Who can see user data?
|
|
Relying Party |
OneID |
Bank |
|
Holds customer data |
Yes (depending on the use case) |
No (*only hashed bank sub) |
Yes |
|
Data controller |
Yes |
Yes |
Yes |
Who knows who is requesting the data?
|
|
Relying Party |
OneID |
Bank |
|
Knows who the Bank is |
No (Yes, if payment is used) |
Yes |
N/A |
|
Knows who the Relying Party is |
N/A |
Yes |
No |
|
Knows who the User is |
Yes (depending on the use case) |
No |
Yes |
Each OneID® use from a customer (‘relying party’ API call) will return a user subject ID or ‘OneID sub’, which is a consistent unique identifier for each user, that OneID® sends to the relying party so they know that the person connecting is the same person each time. This ‘OneID sub’ attribute is returned with every OneID® product along with the personal data. The sub is generated by OneID® as a ‘pairwise’ identifier (RP-user pair) to be different for each relying party that the user connects to, increasing privacy by decreasing account data correlation risks in any data breach event. RPs cannot share ‘sub’ data to compare who their common customers are.
OneID® gets a different consistent unique identifier from the bank for each (a ‘Bank sub’) and hashes and stores the one-way hash so the ‘Bank sub’ cannot be reverse-engineered from OneID® data. This protects the user in the event of a OneID® data breach (they cannot be identified).
Keeping data within the UK
Finally, given its sensitivity and ownership, we want to keep data and services in UK ownership. For that purpose, we have a Social Benefit Trust with trustees who keep us on track with our social purpose. They also control a ‘golden share’ to protect the company from foreign or hostile takeovers.
So, to summarise, at OneID®, we continually ensure that anything we do is in the interest of our users and the UK as a whole. We protect individuals' right to privacy while allowing them to participate safely in the UK’s digital economy. How many can say that….
Take the OneID demo journey to see how fast it is and the format in which the data is shared with the relying party.