Delegation & Authorization How to read a pattern →

2.1 Frontier

Fine-grained scope negotiation

Letting a user grant an agent exactly one bounded permission (lodge this return, touch nothing else) in a form the service can enforce. If the agent misbehaves, the harm stops at the boundary of the one permission the user granted.

The impact of agents

As users authorize agents to act in government services, they will need to grant a single, bounded permission, such as "submit my annual tax return for the 2025 financial year but not access my superannuation records," rather than a coarse read-or-write grant. Conventional authorization scopes are blunt strings that cannot represent that nuance, so the difficulty is expressing and granting authority narrow enough to bound one transaction.

What must be verified

An agency needs each grant to be inspectable enough to confirm, at the point the agent acts, that it did exactly what the user authorized and no more. The service defining the scope catalog must enforce that boundary at the point the agent acts.

Protecting access

The scope screen risks excluding users with low digital literacy, low reading confidence, or little time. A long list of granular permissions can deter them, or they approve everything unread. Either way, they end up with a broader grant than they intended. Whoever can't set up the delegation alone needs a supported route, or this pattern's protection never reaches them.

Keeping the path open

Put a plain-language summary on every scope.
Pre-select a standard bundle as the default fast path.
Offer an assisted-digital route, by phone or in person, for users who can't complete the grant alone.
Let each permission on the scope-toggle consent screen be operated by keyboard and assistive technology, with its granted-or-withheld state announced, not only shown.

Response surface

Negotiate Scope

Each authorized action is offered as a single plain-language permission, with a standard bundle pre-selected that the user can narrow before granting.

User authorizing agent

City Digital Services

Authorize your assistant

Choose exactly what your assistant may do for your property tax relief application. You can narrow any of these now or change them later.

Standard bundle3 of 5 permissions granted

Make single payments on my behalf

One transaction at a time, up to $500. Each payment still needs my confirmation.

Read my income documents

Read-only, and only for this application. The assistant cannot change or share them.

Use my name and address

To pre-fill forms. Nothing sensitive beyond contact details.

Act without asking each timebroad

Ongoing authority, with no confirmation for each action. Rarely needed, and off by default.

Share my data with other servicesbroad

Pass your documents to third parties. Off unless you turn it on.

Or get in-person help at any service center.

System shows scope object

authorization_details: [
  {
    type: "payment_initiation"
    amount: "≤ $500"
    when: "single_transaction"
  },
  {
    type: "document_read"
    mode: "read_only"
    purpose: "this_application"
  },
  {
    type: "identity_read"
    fields: ["name","address"]
  }
]

This object updates live as the user narrows their grant. The surface and the policy are the same decision, seen two ways.

Maturity

Established

For granting a typed, single-transaction scope, where RAR is a ratified IETF standard now mandated and running in production: the Central Bank of the UAE's Open Finance profile requires RAR authorization_details. The first bank is live.
Frontier Headline

For government services, where no service catalog yet defines actions as machine-readable scopes to grant against.

Precedents

OAuth 2.0 Rich Authorization Requests (RFC 9396). The RFC introduces an authorization_details parameter carrying a JSON array of typed authorization objects, each with a type, locations, actions, and domain-specific fields. A grant can be narrowed as far as a single transaction.

GNAP (RFC 9635). The protocol supports fine-grained delegation with asynchronous authorization, requiring no browser, and admits software-only clients. Both properties fit a request made when no user is present to answer it.

RAR in production: Open Finance UAE. The Central Bank of the UAE's Open Finance security profile requires that an authorization server 'shall support OAuth 2.0 Rich Authorization Requests (RAR)', with typed authorization_details for account-access and service-initiation consents. Where the baseline FAPI 2.0 profile only suggests RAR, the CBUAE profile mandates it. The framework is regulator-mandated and live, with the first bank in production.

What carries over to agent use

RAR's JSON authorization objects are directly transferable to government service scoping. A government service catalog could define authorization_details types for each service action (lodge, view, amend, withdraw). GNAP's async interaction model suits agents that operate without a browser session. Open Finance UAE shows the structures work in production in the financial sector. The remaining gap is government-side: no government currently publishes a machine-readable catalog of actions that could populate these structures.

Where things go wrong

Without scoping, the failure is an over-broad grant: an agent given general access reaches far beyond its task. Scoped, revocable grants narrow what the agent can reach if it misbehaves, so an agent authorized only to lodge the 2025 return cannot reach superannuation or trigger a debt-recovery action. A service that defines only coarse-grained scopes can still call a grant 'narrow' while it reaches far beyond the task described. The plain-language summary is only as honest as the scope catalog behind it.

Sources

6 references IETF · Global · UAE · Global (FIDO Alliance)

Primary frameworks

The instrument, the operating deployment, or the official record itself.

Reporting & analysis

Writing about the subject rather than the framework itself, including vendor commentary.