Consent receipts and records
Giving every delegation a durable, verifiable record: what was authorized, by whom, for how long, and what was done under it. When a delegation is later disputed, the user and the agency can point to the same record of what was authorized.
The impact of agents
As agents act asynchronously and at scale, the consent record has to stay verifiable long afterward: what was consented to, when, by whom, and under what conditions, in a form the agency receiving the agent's requests can check. The record at issue here is the grant itself. The receipt an agency issues for any single action taken under it is a separate instrument, and holding the two side by side is what makes an overreach provable.
What must be verified
After a delegation has been used, a relying agency and the user both need to verify its scope, the parties, and its temporal bounds, and to tell what was authorized apart from what the agent did. The agency or identity provider that issued the original delegation must generate and retain that receipt.
Protecting access
A machine-readable record the user can't read is evidence they can't use. The person least able to parse a structured receipt is the person least able to contest an agent that exceeded its grant.
Keeping the path open
- Give every delegation receipt a human-readable rendering: a plain-language summary in the user's preferred language, across web, PDF, email, SMS summary, and paper on request.
- Make the complete record of actions taken under the delegation available in an accessible format on request.
- Make the receipt view's timeline and download controls work with assistive technology, and state scope, parties, and time bounds in words, not codes.
Response surface
The consent lifecycle, from collection through to withdrawal, is rendered as a timeline the user can read and take away as a record.
Delegation record · TaxBot
Operated by AccountingCo Pty Ltd · reference DLG-2026-0Q47
The same record, machine-verifiable. The agency checks what was authorized against what was done. It is the user’s evidence if they dispute it later.
Maturity
- Established
For recording consent in a durable, machine-readable form.
- Emerging
As specified in Kantara and ISO/IEC TS 27560, designed for a relying agency to verify after the fact, though no named deployment is cited here yet.
- Frontier Headline
For a delegation receipt naming a software delegate: neither the Kantara specification nor ISO/IEC TS 27560 contemplates a non-human delegate.
Precedents
Kantara Consent Receipt Specification. The specification defines a JSON record carrying transaction information, the controller's contact details, the principal's information, links to privacy policies, and a description of the data collected with its purposes and processing. ISO/IEC 29184:2020 references it. The receipt is a settled structure with a published field list.
ISO/IEC TS 27560, consent record information structure. The specification covers machine-readable consent records and receipts across the full lifecycle: collection, storage, retrieval, modification, and withdrawal. It works alongside ISO/IEC 29184:2020, which handles the human-readable representation. The machine-readable record and the human-readable notice are standardized separately and designed to pair.
Australia's CDR receipts. A CDR receipt must be given as soon as practicable after a consumer gives, amends, or withdraws a consent, and it names who holds the consent, its purpose, the data covered, its duration, and how to review and withdraw it. The receipt must be given 'in writing otherwise than through the consumer dashboard'. The record of what was authorized therefore sits somewhere the authorized party's own interface cannot revise or bury.
What carries over to agent use
Consent receipts are directly applicable to agent delegation records. A "delegation
receipt" would extend the consent receipt model with: delegation scope (the specific
actions and services authorized, using RAR-style authorization_details); delegate
identity (the agent operator and, where possible, the specific agent instance); delegator
identity (bound to a verified digital identity); temporal bounds (start time, expiry,
renewal conditions); a revocation mechanism (how to revoke, and what happens to in-flight
transactions); and an audit trail of actions taken under the delegation.
The ISO/IEC 27560 lifecycle model (collect, store, retrieve, modify, withdraw) maps well to a delegation lifecycle. The gap: neither standard contemplates a non-human delegate or the provenance chain needed to prove an agent acted within its delegated authority.
Where things go wrong
Without a durable record, a user cannot prove what an agent was authorized to do versus what it did. A verifiable receipt of exactly what was authorized, and what was done under it, gives the user the evidence to contest an action taken outside its granted scope. An issuer who backfills the action log after an overreach, or withholds the record until a dispute has cooled, can make the receipt say whatever is convenient by then. The receipt only holds up if entries are appended at the time of action and cannot be edited afterward.
Sources
4 references
The instrument, the operating deployment, or the official record itself.