Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Data request handler series ~5 min read

How a requester gets verified

Verification is where these processes most often go wrong in both directions. Too little and you send somebody’s data to a stranger. Too much and you have built an obstacle course, which is a documented tactic and reads exactly like one.

Key takeaways

  • Three tiers: already-authenticated, matching contact details, and unknown.
  • An email from the address on the account is usually sufficient on its own.
  • Never ask for photo ID by default. It is disproportionate and it is a red flag.
  • A request on somebody else’s behalf needs authority, which is a different check.
  • Whatever is asked for is deleted once verification is complete.

Three tiers

How a data requester is verified proportionatelyA vertical chain of five steps entered by a box labelled A recognised request, with the clock running. Step one asks whether they are already authenticated, either logged in or arriving through a signed link; if so it exits to Verified with nothing more needed. Step two asks whether the message came from an address held on their own account; if so it exits to Verified for their own data. Step three asks whether the request is for their own data or somebody else's; somebody else exits to Authority needed, which is a different question. Step four asks one thing that only they would know. Step five is Verified, with the clock paused while asking. A note says two of the three tiers need nothing and the third asks one question rather than for documents.AWS ACCOUNTA recognised requestclock runningAlready authenticated?logged in, or a signed linkVerifiednothing more neededyesFrom an address we hold?on their own accountVerifiedfor their own datayesFor their own data?or somebody else'sAuthority neededa different questionsomebody elseAsk one thingsomething only they would knowVerified, and the clockpaused while askingTwo of the three tiers need nothing. The third asks one question, not for documents.
Fig 1. How verification is decided. Most requests clear at the first or second tier, which is the correct outcome rather than a shortcut.
  • App integration
  • Machine learning
  • Security & identity
  • Management
  • Front-end & mobile
  • People

Why photo ID is the wrong default

Asking for a passport scan in response to a request from the email address already on the account achieves nothing protective — anybody with access to that mailbox can already reset the password — and it does three bad things. It adds friction that deters legitimate requests, it collects a highly sensitive document you now have to store and delete, and it looks precisely like obstruction to anybody assessing your process.

Where identity genuinely is uncertain, one question about something only the account holder would know — a recent order number, the delivery address on file — is both more proportionate and more effective.

Pausing the clock

Where verification genuinely is needed, the period spent waiting for the answer does not count against the response deadline in most regimes, and the system records the pause explicitly with its start and end. That is worth building because the alternative is somebody reconstructing it afterwards from an email thread.

It is also worth being disciplined about: pausing the clock for a verification question that was not necessary is exactly the pattern that gets characterised as obstruction, and a system that logs every pause makes that visible to whoever reviews it.

Requests on somebody else’s behalf

How a data request made on somebody else's behalf is verifiedA horizontal row of five boxes. A solicitor: acting for their client. A parent: for a child. A representative: with authority. Check authority: which is not the same as identity. Then verify the subject: as normal. A note says authority to ask and the identity of the person the data is about are different questions.A THIRD-PARTY REQUEST IS TWO CHECKSA solicitorfor their clientA parentfor a childA representativewith authorityCheck authoritynot identityThen verify the subjectas normalAuthority to ask, and the identity of the person the data is about. Different questions.
Fig 2. Why a third-party request needs two separate checks. Conflating them is how a request is either wrongly refused or wrongly fulfilled.
  • Machine learning
  • Security & identity
  • People

These are uncommon and they are the ones most likely to be mishandled, because the instinct is to verify the person who sent the email. That is the wrong check: a solicitor’s identity is not in question, their authority to act is, and that is established by a letter of authority rather than by anything about them.

The system’s contribution here is modest and useful: recognise that the requester and the subject are different people, flag it as a third-party request, and present the handler with the two questions separately rather than one merged one.

Deleting what verification collected

Anything gathered for verification — a document, an answer, a scan somebody sent unprompted — is deleted once the request is closed, and that deletion is recorded. It is a small discipline and it prevents the specific irony of a data protection process accumulating a folder of identity documents.

Next: gathering the data.

All posts