Who we are
Revolt Tech Ltd (“Ekuproof”, “we”, “us”), a company registered in England and Wales under company number 14992603, registered office 20 Wenlock Road, London, England, N1 7GU, is the data controller for the personal data described in this policy.
We are registered with the Information Commissioner’s Office under registration number [ICO REGISTRATION NO.].
For anything about your data, write to admin@ekuproof.com. [IF A DPO IS APPOINTED, NAME THEM HERE.]
The short version
Ekuproof exists so that you can prove you are over 18 without handing your identity document to a stranger at a door. You verify yourself once. After that, the only thing a venue receives is a yes or a no.
- To create an account we need an email address or a mobile number, and a password. Not both.
- Your identity check is run by a specialist provider, Didit. Your document and selfie go to them directly. They do not pass through our servers.
- Didit tells us your date of birth. We immediately turn it into a single true/false value — over 18, yes or no — and keep only that. We do not store your date of birth, your name, or your document number.
- When you present your QR code, the venue learns four things: the credential type, the claim, who issued it, and whether it is currently valid. Nothing else. Not your name, not your age, not your photo.
- We do record which venue scanned your credential and when. Read section 5 — this is the one thing in this policy we would want you to read properly.
- We do not use advertising networks, analytics SDKs, or third-party trackers of any kind. Neither app contains one.
What we collect, and why
This table is the complete inventory for a consumer account. Venue staff data is set out separately in section 11.
| Data | Where it comes from | Why we hold it | Lawful basis |
|---|---|---|---|
| Email address or mobile numberOne or the other, not both | You, at registration | To identify your account and let you sign in and recover it | Contract |
| PasswordStored only as a bcrypt hash, never in readable form | You, at registration | To authenticate you | Contract |
| Device identifier and sign-in sessionsA device fingerprint, plus hashed session tokens | Your device | To keep you signed in, to bind your credential to your device, and to let you revoke a lost phone | Contract Legitimate interests |
| Verification attempt recordWhich claim, pass or fail, when, the provider’s reference, and a failure category | Generated when you verify | To show you your own history, to allow retries, and to investigate disputes and fraud | Contract Legitimate interests |
Your age credentialCredential type, the claim age_over_18, issuer, status, issue and expiry dates |
Derived from the verification result | This is the product. It is what your QR code proves. | Contract |
| QR code issuance recordsWhich credential minted a code and when | Generated when you display a code | To make each code single-use, so a photograph of your screen cannot be reused | Contract Legitimate interests |
| Scan recordsWhich venue scanned your credential, on which device, when, and the result | Generated when a venue scans you | The venue’s own compliance record, and detection of credential misuse | Contract Legitimate interests |
| IP addressHeld briefly as a rate-limit counter, then swept | Your network connection | To stop password guessing and automated abuse of the sign-up and sign-in endpoints | Legitimate interests |
| Audit log entriesAppend-only: what happened, to which account, when | Generated by the system | To keep a tamper-evident record for dispute resolution and regulatory enquiry | Legitimate interests |
| Notification preferences | You, in Settings | To respect your choices about renewal, security and marketing messages | Contract Consent applies to marketing only |
Every row marked Legitimate interests requires a documented Legitimate Interests Assessment before it can be relied on. None has been carried out. The bases above are a reasoned proposal drawn from what the system does, not a completed assessment.
What we never receive
These are not things we promise to delete. They are things that never reach our servers in the first place, because the software is built so that they cannot.
- Your date of birthConverted to a true/false value at the point it arrives and discarded in the same operation. No database column exists to put it in.
- Your nameWe never ask for it and never receive it from the identity provider.
- Your document numberPassport and driving licence numbers stay with the identity provider.
- Your document images or selfieCaptured by the identity provider in their own flow. They are not uploaded to us.
- Your face or any biometric templateFace matching and liveness happen entirely at the identity provider.
- Your locationNeither app requests location permission. We know which venue scanned you, not where you are.
- Your photo library or contactsBoth apps explicitly block these permissions at build time.
- Your payment detailsConsumers are not charged. There is no consumer payment path in the product.
The identity provider sends us your date of birth. A boundary in our code turns it into
{ age_over_18: true } before anything else in the system can see it. Every layer
downstream — the credential, the QR code, the venue result, the admin portal — is protected by
the fact that the raw value was never carried past that point, rather than by each of them
separately remembering to leave it out.
Where you have been: scan records, honestly
When a venue scans your QR code, we record which venue it was, which of their devices did it, when, and whether the result was valid. That record is linked to your credential, and your credential is linked to your account.
So while a venue learns nothing about you beyond a yes or no, Ekuproof can see which participating venues you presented your credential at, and at what times. Over time that is a record of some of your movements.
We hold it because a licensee needs to be able to evidence that they checked a customer’s age — that is their defence under licensing law — and because it is how we detect a credential being used by more than one person. We do not sell it, share it for advertising, or use it to build a profile of you, and access to it is restricted and audit-logged.
This is a real privacy exposure created by a design choice, not by an oversight, and it is worth revisiting deliberately. The venue’s compliance record arguably needs to prove “a valid over-18 credential was checked at 22:14” — it does not obviously need to identify which credential. Severing that link would cost cross-venue misuse detection. That is a genuine trade-off between two things you want, and someone should choose it on purpose rather than inherit it.
Identity verification, and the provider who runs it
We do not check identity documents ourselves. When you verify, we open a session with Didit, a specialist identity verification provider, and hand you over to their flow. You photograph your document and complete a liveness check with them directly.
All we send Didit is an opaque reference number for the attempt. It contains nothing about you. What you then give Didit — your document, your face, and the liveness recording — is given to them, not to us.
Didit returns a result to us: whether the check passed, and the date of birth read from your document. Nothing else in their response is read by our software. In particular we deliberately ignore their facial age estimate: a credential a licensee relies on should rest on what the document says, not on what a model guessed from a photograph.
Biometric data
The liveness and face-matching steps involve biometric data used to identify you. Under UK GDPR that is special category data and needs a condition under Article 9 as well as a lawful basis under Article 6. We rely on your explicit consent, given before the check begins. You can refuse — but the age check cannot be completed without it, and so no credential can be issued.
Three items here are proposals, not settled positions. (a) Whether explicit consent is the right Article 9 condition, or whether a substantial public interest condition under Schedule 1 of the Data Protection Act 2018 fits better. (b) Whether Didit acts as our processor, as an independent controller for their own fraud-prevention purposes, or both — this changes what this section has to say. (c) A data processing agreement with Didit, and confirmation of where they process and how long they retain. None of that can be established from our code, and this draft does not assume it exists.
Automated decisions about you
The decision about whether you are over 18 is made automatically, with no human involved. Your document is checked by the provider’s systems, a date of birth is read from it, and our software compares it against the threshold. If you are under 18, no credential is issued.
This is a decision made solely by automated means, and it can matter to you — an age credential is what gets you through a door. UK GDPR gives you the right not to be subject to such a decision without safeguards. So:
- You may ask a person at Ekuproof to review any automated refusal.
- You may tell us why you think the decision was wrong, and we will take that into account.
- You may contest the outcome.
To do any of these, write to admin@ekuproof.com.
Where a check fails because the document could not be read or the liveness check did not complete, you can simply try again in the app.
The app’s “Contact Support” button used to open a mail client addressed to
support@ekuproof.example — a domain that does not resolve — so the one way out
of an automated refusal went nowhere. It now writes to the address above, with a subject line
that identifies what the message is.
What is still missing is the part that is not code: somebody who reads that inbox, a record of what was decided on review and why, and a turnaround people can rely on. A right that depends on an unread inbox is not a right. Until that exists, this clause is a promise running ahead of the practice behind it.
Who else sees your data
We do not sell personal data. We do not share it for advertising. There are no analytics or tracking SDKs in either app — the full list of who touches your data is below.
| Recipient | Role | What they get |
|---|---|---|
| DiditIdentity verification | [PROCESSOR / CONTROLLER — CONFIRM] | Your identity document, your selfie and liveness capture, given by you directly to them; plus an opaque attempt reference from us |
| RailwayApplication and database hosting | Processor | Hosts the servers and database holding everything in section 3. They do not use it for their own purposes. |
| [EMAIL PROVIDER — NAME BEFORE LAUNCH]Sending verification and security emails | Processor | Your email address, and the contents of the message — which is a short-lived numeric code and nothing else. No credential, claim or verification result is ever sent by email. |
| Participating venuesWhen you choose to present a code | Controller for their own record | Credential type, the claim, the issuer, and whether it is valid. No identifying information about you. |
| Regulators, law enforcement, courts | — | Only what we are legally required to disclose, and only when we are satisfied the request is valid |
An email provider appears in this table because registration now sends a confirmation code. The supplier is not yet named: the system speaks plain SMTP rather than any vendor's own interface, so the choice is a configuration change — but a named processor belongs here before launch, with a data processing agreement behind it.
If we later add a payment processor, an SMS provider, or an error-reporting service, this table changes and this policy is updated before that happens. None of those is in use today.
Where your data is held
Our servers and database are hosted in Amsterdam, the Netherlands. The UK Government has determined that the European Economic Area provides an adequate level of data protection, so your data can be transferred there without additional safeguards.
Didit, our identity provider, processes and stores identity data in the EU, on AWS infrastructure. That is its default configuration and the one our account uses; in-country residency is an enterprise option we have not taken. The same adequacy finding therefore covers it, so no additional transfer mechanism is required today.
If that ever changes — if we move to a configuration or a provider that processes identity data outside the UK or EEA — this section will be updated before the change takes effect, and the transfer will be covered by an appropriate mechanism such as the UK IDTA or the UK addendum to the EU standard contractual clauses.
How long we keep it
UK GDPR lets us tell you either the period, or the criteria we use to set it. We are giving you the criteria, because the periods have not yet been set. That is a deliberate position: the system is built so that each category has its own configurable retention period, and those numbers are set by legal review rather than fixed in the code.
| Category | How long, and what decides it |
|---|---|
| Account details | For as long as your account is open. When you delete it, contact details are erased immediately — see section 12. |
| Your credential and its history | Through its lifecycle and for a period after expiry or revocation, so that a scan which happened can still be explained. Set by the dispute and licensing record-keeping window. |
| Verification attempt records | Retained for retry handling, fraud detection and dispute resolution. Set by the fraud-investigation window. |
| Scan records | Set by how long a licensee needs to evidence an age check — a licensing and Trading Standards question, not ours alone. |
| Audit log | Set by UK business record-keeping norms and by whatever the DIATF certification scheme requires once certification is underway. |
| Identity documents and selfies | Held by Didit under their retention policy, not by us. We never hold copies. [CONFIRM DIDIT’S PERIOD] |
| IP addresses | Minutes. They exist only as a rate-limit counter and are swept automatically once the window closes. |
Replace this section with actual durations once they are set. Criteria satisfy Article 13, but stated periods are clearer for the reader and better practice — and the numbers should be entered into the system’s retention policy table at the same time, so that what this document says and what the software enforces cannot drift apart.
Venue staff
This section applies if you use the Ekuproof Venue app at work, rather than as a customer.
We hold your work email address, the venues you are a member of, your role, and a hashed version of your access PIN. We do not hold your name, your home address, or anything about you personally beyond your role at the venue.
Scans you perform are recorded against the device and the venue, not against you individually. The venue login is deliberately identifier-less — it asks for a device and a PIN, not for who you are — so the system does not know which member of staff scanned a given customer.
Repeated incorrect PIN entries lock the device for a cool-down period, and we record the device identifier and the venue to enforce it. This is device-scoped on purpose: locking staff accounts instead would let anyone take a whole door team offline by guessing at them.
Your employer is the venue. If they end your access, your membership is revoked and your sessions stop working immediately.
Your rights
Under UK GDPR you have the following rights. They are free to exercise, and we will respond within one month.
Access, correction, and portability
You can ask for a copy of the personal data we hold about you, ask us to correct anything inaccurate, and ask for it in a portable format. Write to admin@ekuproof.com.
Deletion
You can delete your account from within the app: Settings → Delete account. You will be asked to confirm, and it happens immediately. If you no longer have the app installed, you can do the same thing on the web at api.ekuproof.com/delete-account.
When you delete your account, we erase your email address and mobile number, destroy your password, and revoke your credentials so they can no longer be used. Any identity documents or selfies held on our side are destroyed.
One thing survives, and you should know why. We keep the account record itself as an anonymous identifier, stripped of anything that identifies you. This is because our audit log and the venues’ scan records have to remain complete — a venue must still be able to show that they checked a valid credential on a given night, and deleting the record outright would destroy that licensee’s legal defence. What remains cannot be traced back to you. You can sign up again afterwards with the same email address.
Objection and restriction
Where we rely on legitimate interests, you can object and we will stop unless we have compelling grounds to continue. You can also ask us to restrict processing while a dispute is resolved.
Withdrawing consent
Where we rely on consent — marketing messages, and the biometric processing in section 6 — you can withdraw it at any time. Withdrawing consent does not undo processing that already happened. Withdrawing consent for biometric processing means we cannot issue or renew an age credential.
Automated decisions
See section 7.
How we protect your data
- Everything travels over encrypted connections.
- Passwords and PINs are stored only as hashes, never in a form we could read.
- Your QR code expires fifteen seconds after it appears and cannot be used twice, so a photograph of your screen is worthless.
- The private key that signs credentials is held separately from the database.
- Signing out, deleting your account, or revoking a lost device stops existing sessions working immediately, rather than when their token happens to expire.
- Inside our admin tools, contact details are masked by default. Revealing one requires a stated reason and writes an audit entry that cannot be removed.
- Sign-in, registration and general API traffic are rate limited against automated abuse.
No system is perfectly secure. If we suffer a breach that is likely to put your rights at risk, we will tell the ICO within 72 hours and tell you without undue delay.
People under 18
Ekuproof is not a service for children, and we do not knowingly hold accounts for under-18s. But an age check is only meaningful if people who turn out to be under 18 can take it — so some of the people who use this app will be under 18, and will be refused.
If you are under 18 and your check does not pass, we hold the fact that an attempt was made and that it did not succeed. We do not hold your date of birth, because we never store one. You have the same rights as anyone else, including the right to have your account deleted.
The ICO’s Age Appropriate Design Code applies to services likely to be accessed by children. An age-verification app is, by its nature, exactly such a service, and this is arguably the most significant open compliance question in this document. It carries fifteen standards covering default settings, data minimisation, profiling and transparency, and it needs assessing properly rather than being answered with the sentence above.
Changes to this policy
If we change how we handle your data, we will update this policy and change the date at the top. Where a change materially affects you, we will tell you in the app before it takes effect rather than relying on you to notice.
Complaints
If you are unhappy with how we have handled your data, tell us first at admin@ekuproof.com and we will try to put it right.
You also have the right to complain to the Information Commissioner’s Office at any time, whether or not you have raised it with us. The ICO can be reached at ico.org.uk/make-a-complaint, on 0303 123 1113, or at Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF.