Scope and responsibility
This draft translates the accompanying essay into a compact architecture. It covers the authority to act, the evidence a service must check and the record returned to the person. It does not specify a national registry implementation, choose a model, or establish legal powers. It is a proposal derived from Alvar Laigna’s writing, not a separately published standard.
The order of work is need → process redesign → legal authority and safeguards → operational readiness → bounded agent → measurable outcomes. Start with a service failure worth fixing. Measure completion, time, avoidable contacts, accessibility, errors, appeals and staff workload.
Three lanes of assistance
Information and navigation. An agent explains a service, finds authoritative information and directs the person to the right channel. It does not change rights, obligations or authoritative records.
Assisted casework. An agent collects information, prepares a draft and checks completeness. A responsible person or deterministic service rule remains the decision-maker.
Consequential action. An agent expresses a citizen’s intent by submitting, modifying, paying or preparing a signing flow. Explicit authority, current policy, stronger evidence, confirmation where required and a remedy path are necessary. A citizen’s representative and a competent administrative authority are different roles.
Five objects with different lifetimes
| Object | What it carries | Owner |
|---|---|---|
| Mandate record | Revocable definition of exact delegated authority | Mandate issuer or registry |
| Mandate credential | Signed, portable representation of selected mandate facts | Trusted issuer |
| Presentation | Fresh verifier-bound evidence and required holder-key proof | Citizen-controlled holder |
| Service access token | Narrow, short-lived permission for one audience and key | Service authorisation server |
| Downstream action grant | Further attenuated authority for one internal actor or command | Delegating service |
A durable mandate may legitimately last longer than an execution token. Revoking the mandate must invalidate dependent authority within a declared bound. Expiring one token does not erase the mandate. A fresh presentation must not silently become an unlimited credential.
Trust distribution and direct service traffic
The control plane distributes trusted issuers, operator information, credentials and mandate status. It does not broker ordinary citizen-service transactions. Issuance and status distribution may contact the registry; ordinary protected operations should not require a synchronous national lookup on every call.
The data plane carries requests from the protected agent client to the public service. Two independent chains meet there: what the person authorised, and which workload presents the request. Neither chain suffices alone. Workload identity does not prove citizen intent, and a valid mandate presented by the wrong workload must fail.
The model’s context is an untrusted execution environment. Keys and trusted confirmation interfaces sit outside it.
The service decides every protected operation
Effective authority is the intersection of mandate scope, current service policy and citizen limits. The service verifies evidence before considering the requested action, then applies current ownership, eligibility, workflow and resource state.
The result is explicit:
- permit: current authority and state allow the action;
- confirmation_required: the action is eligible, but the specified human approval is still needed;
- deny: evidence, authority, policy or state does not permit the action.
Unknown authority-bearing fields are rejected. Derived grants may only narrow audiences, actions, resources, limits, validity and delegation depth. Stronger authentication cannot supply missing authority. A new or expanded mandate is a separate process.
Cumulative limits must be enforced atomically. Repeated commands with the same idempotency key and unchanged payload return the original result; a changed payload is rejected. An uncertain result is reconciled using the original operation identifier.
Confirmation binds what will actually happen
Where confirmation is required, the service freezes the transaction and displays authoritative details through a trusted channel. Approval binds the action, service, principal, mandate version, resource and version, material values, payload digest, nonce and expiry. The agent does not supply the confirmation screen’s text.
Signing is not delegated to the model. Current policy, status and resource state are checked again at commit and when queued work is dispatched. A receipt records the result; it does not substitute for a required signature.
Prompt injection can redirect the agent towards another action already inside its scope. It cannot expand verified authority. The service does not need to identify the injection: the proposed action remains bounded by the mandate, current policy and confirmation requirements. That is still a meaningful risk: narrow mandates limit exposure, and trusted confirmation helps the person detect a consequential change of intent.
Revocation is a measurable contract
The maximum revocation window includes publication delay, delivery or refresh delay, verifier application delay and clock allowance. It is an end-to-end property, not just a token expiry field.
The essay proposes pilot values of five minutes for API access tokens, sixty seconds for internal grants and 120 seconds for maximum signed status age. These are design targets, not statements of national capability. Production services need resilience and service-specific freshness contracts. Re-fetching the same stale snapshot does not make it fresh.
The evaluator on this site applies the 120-second example to protected writes and fails closed. Its replay and cumulative-limit presets use supplied synthetic state; it is not a transaction store, signature verifier or real authorisation service.
Invariants an implementation must enforce
- The strictest bound wins: effective authority is mandate scope ∩ service policy ∩ citizen limit.
- Every derived grant narrows audience, action, resource, limits, lifetime and delegation depth; none widens.
- No bearer downgrade: a token presented without its bound key is rejected.
- Audience and nonce bind a presentation to one verifier and one transaction; they never create authority.
- Status is checked at every protected operation; a protected write fails closed beyond the signed freshness bound.
- Approval binds the exact transaction: action, resource and version, material values, payload digest, nonce, expiry. It is consumed once.
- An idempotency key is bound to principal, mandate, action and payload digest; reuse with a changed payload fails.
- Cumulative limits are enforced atomically across concurrent requests.
- Unknown authority-bearing fields are rejected, never ignored.
- The model never holds a key, never renders a confirmation screen and never decides.
Building blocks and their limits
| Building block | What it proves | What it does not prove |
|---|---|---|
| SD-JWT (RFC 9901) | An issuer signed claims; selected claims were disclosed intact; the holder key was used | Anonymity, authorisation, revocation |
| SD-JWT VC (draft) | A credential profile for the above | A stable format until a version is pinned |
| OpenID4VP 1.0 | A verifier-requested presentation was validated | That the action is authorised |
| SPIFFE/SPIRE | Which attested workload in an operator’s trust domain is asking | Citizen intent, legal authority, model behaviour |
| DPoP (RFC 9449) | The token holder controls its key for this request | Authorisation; anything once token and key are both stolen |
| RAR (RFC 9396) | Structured authorization_details travelled with the request |
Government action semantics or approval rules |
| Token Exchange (RFC 8693) | Evidence was exchanged for a new token | Attenuation or parent-child revocation |
| Token Status List (draft) | A signed status the verifier can fetch | Freshness or fail-closed behaviour |
Threats and required responses
| Threat | Required response |
|---|---|
| Prompt injection or malicious tool output | Content is data; structured actions validated; egress restricted; limits enforced outside the model |
| Stolen token or replayed proof | Key proof, narrow audience, freshness, replay controls |
| Wrong agent with valid evidence | Logical agent, operator, workload and holder key verified together |
| Payload substitution after approval | Approval bound to digest and resource version; recheck at commit |
| Split or concurrent transactions | Atomic counters, reservations, idempotency, cumulative bounds |
| Stale policy or revoked parent | Descendants invalidated; current policy and bounded status at each effect |
| Issuer or operator compromise | Quarantine, key rotation, isolated trust domains |
| Malicious metadata or key URL | Pinned trust roots; approved resolution paths; no token-directed fetches |
Evidence, standards and adoption
Reuse established protocols for their actual properties: SD-JWT for signed selective disclosure, OpenID4VP for presentations, SPIFFE for workload identity, DPoP for sender-constrained tokens, and Rich Authorization Requests for structured action details. The essay records the proposed profile and the limits of each building block; the sources page lists every reference.
Law supplies competence, delegability, legal effect, reasons and remedies. Standards carry evidence; cryptographic validity alone does not make an action lawful. Estonia’s HMS § 7¹ amendment is a relevant foundation for automated administrative procedure, with its own conditions and effective dates.
Adopt incrementally: navigation and preparation, then narrow reversible actions, bounded submissions and finally consequential workflows where the legal and operational prerequisites exist. Test the denial paths before widening the mandate. The person must retain practical access to human contact, correction and review.
Operational readiness is organisational as much as technical, and each stage needs the people in place, not only the protocols. Procure problem-solving and iteration rather than a specification: a multidisciplinary team of service owner, domain expert, lawyer, ethicist and engineer; small, low-risk pilots in a sandbox; scaling only after the value is shown. Keep the junior workforce: when an agent absorbs routine work, pair junior officials with senior ones on the difficult exceptions the agent filters out, so judgement is still learned inside the institution. Set the rules before the tools: policy as code, platform guardrails, security oversight and a domain expert’s approval of changes. These criteria are summarised from the author’s article on AI readiness in the public sector.
The agent is never the authority.