Consumer data rights consent flows
Taking a user's authorization through a consent flow the user completes with the government rather than with the agent: scoped permissions, strong authentication, and a standing dashboard for review and revocation. A compromised or over-reaching agent can't use credentials it never held.
The impact of agents
When a user authorizes an AI agent to reach a government service on their behalf, that authorization has to hold over months, not just at the moment it is granted.
A flow that re-prompts the user at every step collapses under its own ceremony, and one that never re-prompts drifts out of the user's control.
What must be verified
An agency needs the user's authorization to be specific, standing, and revocable, with the user authenticating to the government rather than to the agent, so that what the agent may do is informed and remains manageable over time. The government identity provider must hold and keep current that standing consent record.
Protecting access
Redirect flows drop a screen-reader user's context mid-journey. A time-limited strong-authentication challenge fails people with motor or cognitive impairments before they can complete it. SMS one-time codes assume a personal mobile, excluding those without one. In each case, the user intends to grant the authority, and the ceremony itself refuses them.
Keeping the path open
- Extend the strong-authentication challenge window.
- Offer authentication channels that don't assume a phone: a hardware token, an email.
- Confirm consent through an alternative channel, such as a phone call with an automated readback of the permissions being granted.
- Let assistive technology read each permission's state on the consent screen and the standing dashboard, and keep revocation reachable by keyboard alone.
Response surface
Delegations that only view data are kept apart from those that act, so authorizing an action takes a heavier confirmation than authorizing a look.
HealthMate is requesting access to your health records
You are signed in to City Digital Services, not to the agent. Approve only what it needs to complete your application.
To allow access, first acknowledge the statement above.
Every consent the user grants is kept here as a standing record. They can review or revoke it long after the redirect.
Maturity
- Established
For consumer-data consent in banking, where redirect flows, strong customer authentication, and consent dashboards run in production under PSD2 and the CDR.
- Frontier Headline
For a government service taking scoped, revocable authorization for a user's agent through such a flow, which no agency yet operates.
Precedents
Open Banking UK Customer Experience Guidelines. The consent journey runs as a redirect: the customer starts in the third-party provider, the provider states the scope of data or payment access, the customer is sent to their bank for Strong Customer Authentication, confirms the specific permissions, and returns. The Guidelines mandate consent and access dashboards for ongoing management, minimal information presentation, and platform-agnostic wireframes. Scope is stated by the requester and confirmed at the holder, which keeps the two acts apart.
Australia's Consumer Data Right (CDR). Data holders and accredited data recipients must both provide consumer dashboards that are 'simple and straightforward to use and prominently displayed', and the consent flow treats collection, use, and disclosure as separate elements. Later amendments introduced bundled and pre-filled consent for necessary data, and the Treasury design paper considered a principles-based ban on dark patterns. The regime carries a formal Consent Review process covering authorization, revocation, re-authorization, and notification.
CDR authentication standards. The CX Standards require data holders and recipients to tell consumers that third parties do not need their passwords to reach CDR data, and prohibit forgotten-details links on redirect screens as an affordance judged to raise the likelihood of phishing. The Guidelines make app-based authentication, by biometrics or a PIN in the data holder's own app, the preferred flow, with the web one-time-password redirect kept as a fallback. Credential isolation is stated to the consumer, and not left to the architecture to imply.
What carries over to agent use
Open-banking consent flows are the closest existing analogue to government-to-agent delegation. Directly transferable: redirect-based authentication (the user authenticates with the government identity provider, not the agent, which never sees credentials); scoped permissions with human-readable summaries; consent dashboards for viewing, managing, and revoking active delegations; SCA for re-authorization when the agent requests expanded scope; and time-bound access that expires and must be renewed.
Key differences for government services: government actions are often irreversible (lodging a tax return, applying for a benefit) in ways that viewing bank data is not. The consent model needs to distinguish "view" delegations from "act" delegations, with higher ceremony for the latter. The CDR's experience with dark patterns is cautionary: bundled and pre-filled consents reduce friction but can undermine informed delegation. The temptation to bundle ("just let the agent do everything") has to be resisted by design.
Where things go wrong
The failure to prevent is an over-broad or unauthorized data grab proceeding silently at scale. Redirect authentication keeps credentials away from the agent and forces the user to confirm scoped permissions, so that grab cannot happen unseen. A registered but rogue third-party provider can still request a bundled scope well beyond its stated purpose, counting on the user to confirm without reading it. A phished redirect can present a lookalike consent screen before the user ever reaches the bank's own page, capturing a grant the user never gave to the real service.
Sources
5 references
The instrument, the operating deployment, or the official record itself.