Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments
draft-morrison-consent-settlement-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Blake Morrison | ||
| Last updated | 2026-08-11 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-morrison-consent-settlement-04
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd
Intended status: Informational 12 August 2026
Expires: 13 February 2027
Consent-Bound Identity Disclosure with Subject Settlement for HTTP-
Native Agent Payments
draft-morrison-consent-settlement-04
Abstract
This memo specifies an extension to HTTP-native agent payment
protocols by which the disclosure of an identity attribute about a
human subject is bound to that subject's recorded consent and
settled, in part, to that subject. When an agent pays to read an
identity attribute about a person, the extension requires that the
read carry a reference to a scoped, revocable consent grant issued by
the subject, and it requires that the payment's settlement
instruction name the subject as a beneficiary of a share of the
read's price greater than the shares of all other parties combined.
The extension composes above an identity- attestation envelope (which
asserts who a credential is about) and above an HTTP-native payment
flow (which moves value for the read); it adds the two functions
neither layer provides: consent capture at disclosure time and
settlement to the data subject. The wire additions are an
advertisement in the server's payment-required response, a consent-
grant reference echoed in the client's payment payload, and a
settlement instruction enumerating subject beneficiary roles. The
extension is settlement-network-agnostic and attestation-format-
agnostic. The memo is Informational; the underlying COSE and CBOR
formats are normative per [RFC9052] and [RFC8949], and the HTTP
semantics are normative per [RFC9110].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Morrison Expires 13 February 2027 [Page 1]
Internet-Draft Consent Settlement August 2026
This Internet-Draft will expire on 13 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
4. Tiered Disclosure and Pricing . . . . . . . . . . . . . . . . 6
5. Consent Binding . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Consent Grant Object . . . . . . . . . . . . . . . . . . 8
5.3. Echo and Verification . . . . . . . . . . . . . . . . . . 9
6. Subject Settlement . . . . . . . . . . . . . . . . . . . . . 9
6.1. Settlement Instruction . . . . . . . . . . . . . . . . . 9
6.2. Settlement Timing . . . . . . . . . . . . . . . . . . . . 11
6.3. Return Clause . . . . . . . . . . . . . . . . . . . . . . 11
7. Disclosure Ledger . . . . . . . . . . . . . . . . . . . . . . 12
8. Composition . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. With an Attestation Envelope . . . . . . . . . . . . . . 13
8.2. With an HTTP-Native Payment Protocol . . . . . . . . . . 13
8.3. With Substrate and Handle Discovery . . . . . . . . . . . 14
8.4. With the Identity Accord . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Consent-Settlement Beneficiary Roles Registry . . . . . . 14
9.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Grant Forgery and Subject-Key Compromise . . . . . . . . 16
10.2. Signature-Algorithm Agility and Downgrade . . . . . . . 17
10.3. Grant Substitution . . . . . . . . . . . . . . . . . . . 17
10.4. Stale-Grant Replay . . . . . . . . . . . . . . . . . . . 17
10.5. Settlement Evasion . . . . . . . . . . . . . . . . . . . 18
10.6. Consent-Theatre Resistance . . . . . . . . . . . . . . . 19
10.7. Tier and Classifier Manipulation . . . . . . . . . . . . 19
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
11.1. Compute-Location of Subject Observations . . . . . . . . 19
11.2. Ledger Observability . . . . . . . . . . . . . . . . . . 20
11.3. Subject Linkage Across Readers . . . . . . . . . . . . . 20
Morrison Expires 13 February 2027 [Page 2]
Internet-Draft Consent Settlement August 2026
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 21
Changes from draft-morrison-consent-settlement-03 . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
An agent that pays to read an identity attribute about a person
participates in three relationships at once. It has a relationship
with the server that holds or asserts the attribute; it has a
relationship with whatever payment rail moves value for the read; and
it has, whether acknowledged or not, a relationship with the person
the attribute is about. The first two relationships are well served
by current work. HTTP-native payment protocols such as [X402] move
value for a metered read. Identity-attestation formats assert that a
credential is about a named subject and that an issuer vouches for
it. The third relationship, the one with the data subject, is
unserved: the subject neither consents to the specific disclosure at
the moment it occurs nor receives any part of the value the
disclosure generates.
This memo specifies an extension that serves the third relationship.
It does so with two additions, layered above an existing payment flow
and an existing attestation envelope, neither of which it replaces.
The first addition is consent binding. When a server offers an
identity read for payment, it advertises that the read requires a
consent grant from the subject. The client supplies a reference to a
scoped, revocable grant that the subject has issued. The server
verifies the grant covers the requested attribute and has not been
revoked before it discloses. Consent is captured at disclosure time,
against the specific attribute and the specific reader scope, not
inferred from a one-time account-creation click.
The second addition is subject settlement. The payment for the read
carries a settlement instruction that names the subject of the
identity data as a beneficiary of the read's price, and settles that
subject more than every other party to the read combined. The person
the data is about earns when the data is read, and earns the larger
part of what the read is worth.
This specification fixes a floor on the subject's position, not a
ratio. Where the subject's share sits above that floor, and what the
other roles are and how they divide the remainder, are policy of the
Morrison Expires 13 February 2027 [Page 3]
Internet-Draft Consent Settlement August 2026
settling substrate. The floor is normative because a share the
intermediaries can outweigh is a fee paid to the subject, not a
return of the value the subject's own data generated, and an
extension that cannot tell those two apart has not served the
relationship it exists to serve.
The extension is deliberately narrow. It does not assert identity;
an identity-attestation envelope does that, and this extension
composes above it. It does not move value; a payment protocol does
that, and this extension composes above it. It does not adjudicate
who a credential is about; it binds the disclosure of an already-
attested attribute to the subject's consent and to the subject's
settlement. The two functions it adds are the two functions the
subject relationship requires and the adjacent layers structurally
omit.
The extension composes with [X402] as the payment flow, with an
identity-attestation envelope (referenced abstractly; see Section 3)
as the layer asserting the subject, with [MCPDNS] for substrate and
key discovery, with [IDPRONOUNS] for the subject-handle namespace,
and with [IDACCORD] as a sibling consent-envelope ceremony for the
bilateral-agreement case.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are defined for the purposes of this document.
Subject The human being to whom an identity attribute pertains. The
subject is the party whose consent is bound and to whom a
settlement share is directed. The subject is named by a
Sovereign-tier handle per [IDPRONOUNS].
Reader The party, typically an autonomous agent acting for a
principal, that pays to read an identity attribute about a
subject.
Attribute A single item of identity information about a subject (for
example, a verification status, a trait band, a recognition
reading). This memo treats an attribute as opaque; its semantics
are the concern of the attestation layer.
Attestation envelope A signed document, supplied by the layer below
Morrison Expires 13 February 2027 [Page 4]
Internet-Draft Consent Settlement August 2026
this extension, that asserts which subject an attribute is about
and which issuer vouches for it. This memo is agnostic to the
envelope's format.
Consent grant A scoped, revocable, content-addressed assertion,
signed by the subject, that a defined reader scope MAY read a
defined set of attributes under defined conditions. The grant is
the object the reader references at read time and the object the
subject revokes to withdraw permission.
Settlement instruction A structured directive, carried with the
payment, that enumerates the beneficiary roles of the read's price
and their shares. A conformant instruction MUST include a subject
beneficiary role settled above the floor of Section 6.1.
Disclosure event A typed signed record, written to the substrate's
identity log, noting that an attribute was disclosed to a reader
under a named grant for a settled price. The event carries
references and hashes only; it does not carry the disclosed
attribute value.
Return clause The requirement of this specification that value
generated by a disclosure return, in majority part, to the subject
of the disclosed data. The return clause is satisfied by the
subject beneficiary role of the settlement instruction, settled
above the floor of Section 6.1.
Substrate The system, operated by a substrate operator, that hosts
the subject's identity log, holds the settlement policy, and
executes the consent-verification and disclosure-ledger steps of
this extension. A substrate defines the tier schedule and its
prices, the recognised reader classes, and any additional
beneficiary roles it supports. Multiple substrates may
interoperate; each is responsible for its own identity log and
settlement policy.
3. Architectural Overview
The extension comprises three composed layers and a record, each
addressable independently.
1. *Attestation envelope (below; not specified here).* A signed
assertion of which subject an attribute is about. This memo
requires only that the envelope name the subject by a handle
resolvable per [IDPRONOUNS] and [MCPDNS], and that the envelope's
issuer signature be verifiable. The envelope format is out of
scope.
Morrison Expires 13 February 2027 [Page 5]
Internet-Draft Consent Settlement August 2026
2. *Consent binding (Section 5).* A server advertises, in its
payment-required response, that the read requires a subject
consent grant. The reader echoes a grant reference in its
payment payload. The server verifies grant scope and revocation
status before disclosing.
3. *Subject settlement (Section 6).* The payment carries a
settlement instruction enumerating beneficiary roles, of which a
subject role carrying more than half the price is REQUIRED.
Settlement to the subject occurs at disclosure time,
synchronously with the read.
4. *Disclosure ledger (Section 7).* Each disclosure is recorded as a
typed signed event in the substrate's identity log, binding the
attribute hash, the grant reference, the reader, and the settled
price into an auditable record without exposing the attribute
value.
Layers 2 and 3 are the substance of this extension. Layer 1 is
assumed present and is referenced, not defined. The record of Layer
4 is REQUIRED for a conformant disclosure but its transport and
retention are substrate concerns.
The extension is carried over an [X402]-style flow as follows. The
server's payment-required response advertises the extension and its
consent requirement. The client's payment payload echoes the
extension, the consent-grant reference, and the settlement
instruction. The server, on a valid payment and a valid grant,
discloses the attribute and emits the disclosure event. The
extension uses the host protocol's advertise-and-echo mechanism and
its request lifecycle hooks; it introduces no new transport.
4. Tiered Disclosure and Pricing
A read of an identity attribute is not a single act of uniform value.
A reader may seek confirmation that a subject is known (a low-value
verification), a single attribute (a moderate-value read), or a
comparative judgement drawing on several attributes (a higher-value
read). An implementation MAY price disclosure in tiers graduated by
the depth of the read, and the consent grant MAY scope permission per
tier. The extension treats the tier as an attribute of the read
advertised in the payment-required response and echoed in the payment
payload; the tier schedule and its prices are substrate policy.
Morrison Expires 13 February 2027 [Page 6]
Internet-Draft Consent Settlement August 2026
A verification-tier read that returns only a boolean known/not-known
signal MAY be offered without payment and without a settlement
instruction, at the substrate's discretion, because it discloses no
attribute value. Any read that returns an attribute value MUST carry
both a consent-grant reference and a settlement instruction with a
subject beneficiary role settled above the floor of Section 6.1.
5. Consent Binding
5.1. Advertisement
When a server offers an identity read that returns an attribute
value, its payment-required response MUST advertise this extension
and MUST signal that the read requires a subject consent grant. The
advertisement carries:
extension (text string, REQUIRED) The extension identifier. This
specification uses the literal "consent-settlement-v0".
subject (text string, REQUIRED) The Sovereign-tier handle of the
subject whose attribute is on offer, per [IDPRONOUNS].
attribute_ref (text string, REQUIRED) An opaque identifier for the
attribute on offer, meaningful to the attestation layer.
tier (text string, OPTIONAL) The disclosure tier per Section 4.
consent_required (boolean, REQUIRED) MUST be true for any read
returning an attribute value.
grant_discovery (text string, OPTIONAL) A hint to the reader on
where a subject grant may be requested or resolved, expressed as a
well-known URI per [RFC8615] or a handle.
A reader MAY follow grant_discovery and MUST NOT treat it as
authorisation. A grant obtained by following the hint is admitted
only on the checks of Section 5.2, exactly as one obtained by any
other route. A reader that cannot parse or resolve the value MUST
ignore the field and continue, because the offer is well-formed
without it, and MUST NOT refuse the offer on that ground alone.
Morrison Expires 13 February 2027 [Page 7]
Internet-Draft Consent Settlement August 2026
5.2. Consent Grant Object
A consent grant is a COSE_Sign1 object [RFC9052] (CBOR tag 18)
wrapping a CBOR-encoded payload [RFC8949], signed by the subject's
Sovereign-tier signing key, the key bound to the subject in the
subject's attestation envelope (Section 3). The signature algorithm
is carried in the COSE protected header; the algorithm floor is given
in Section 10. The grant payload is a CBOR map with keys:
* version (text string): "consent-settlement-grant-v0".
* subject (text string): the subject's Sovereign-tier handle.
* grant_id (text string): a UUIDv4 identifying the grant.
* reader_scope (CBOR map): the scope of readers permitted under the
grant. Keys:
- mode (text string): one of any, handle, class.
- value (text string, OPTIONAL): for handle, the specific reader
handle; for class, a substrate-defined reader class identifier
(for example, a recognised-member class). Absent for any.
* attributes (array of text strings): the attribute_ref values the
grant permits.
* tiers (array of text strings, OPTIONAL): the disclosure tiers
permitted; absent implies all tiers the subject's policy allows.
* conditions (CBOR map, OPTIONAL): substrate-defined conditions, for
example a per-grant read ceiling or an expiry.
* inception (text string, [RFC3339]): start of validity.
* expiry (text string, [RFC3339], OPTIONAL): end of validity.
* revocation_commitment (byte string): the SHA-256 hash of a
revocation token of at least 256 bits drawn from a
cryptographically secure random source. Revocation is effected by
publishing the token preimage to the subject's identity log. The
commitment is carried inside the signed grant payload and is
therefore bound by the subject's signature.
Morrison Expires 13 February 2027 [Page 8]
Internet-Draft Consent Settlement August 2026
The grant is content-addressed by the SHA-256 hash of its complete
COSE_Sign1 serialisation, deterministically encoded per [RFC8949]
Section 4.2, so that the content address commits to the signature as
well as to the payload. The reader references the grant by this
content address. SHA-256 is mandated by this version of the
specification; hash agility is a concern for a future version.
5.3. Echo and Verification
The reader's payment payload MUST echo:
* extension: "consent-settlement-v0".
* grant_ref (byte string): the content address of the consent grant.
* reader (text string): the reader's handle, against which the
grant's reader_scope is evaluated.
Before disclosing the attribute value, the server MUST:
1. Resolve the grant from its content address and verify its
COSE_Sign1 signature against the subject's signing key as bound
in the subject's attestation envelope (Section 3).
2. Verify that the grant's subject equals the advertised subject and
that attribute_ref is a member of the grant's attributes.
3. Verify that the reader satisfies the grant's reader_scope.
4. Verify the grant's validity window against the current time and
evaluate any conditions.
5. Query the subject's identity log for a revocation event naming
the grant's grant_id or disclosing the revocation_commitment
preimage. A revoked grant MUST NOT be honoured.
If any check fails, the server MUST refuse the disclosure and SHOULD
return a structured error distinguishing absence of grant, scope
mismatch, expiry, and revocation, without revealing the attribute
value.
6. Subject Settlement
6.1. Settlement Instruction
A read that returns an attribute value MUST carry a settlement
instruction. The instruction is a CBOR map enumerating beneficiary
roles and their shares of the read's price. Keys:
Morrison Expires 13 February 2027 [Page 9]
Internet-Draft Consent Settlement August 2026
* version (text string): "consent-settlement-instruction-v0".
* price (CBOR map): the read's price, expressed as an amount and a
unit. The unit is settlement-network-agnostic; this memo does not
constrain the network or asset.
* beneficiaries (CBOR array): one entry per role. Each entry is a
CBOR map:
- role (text string): one of subject, operator, facilitator, and
substrate-defined additional roles.
- handle (text string, OPTIONAL): the beneficiary handle, where
the role resolves to a specific party.
- share (CBOR map): the role's share, expressed as a rational
fraction (numerator, denominator) so that the sum of shares is
exactly one.
A conformant settlement instruction MUST include exactly one subject
role whose handle equals the advertised subject. The subject role's
share MUST be greater than the sum of the shares of every other role
in the instruction. An instruction in which any combination of non-
subject roles is settled a share equal to or greater than the
subject's does not conform to this extension, and a disclosure
settled under such an instruction MUST NOT be treated as a conformant
disclosure.
The floor is a relation between the subject and the other parties,
not a fixed ratio. Where the subject's share sits above the floor,
how many other roles exist, and how those roles divide the remainder
are policy of the settling substrate and are NOT fixed by this
specification. A substrate that settles the subject a bare majority
and a substrate that settles the subject almost the whole price are
both conformant.
Morrison Expires 13 February 2027 [Page 10]
Internet-Draft Consent Settlement August 2026
The floor is normative rather than advisory for a reason that is
structural, not economic. A requirement that the subject share
merely exceed zero is satisfied by a share of any size, including one
chosen to be too small to notice. Under such a requirement an
implementation can advertise consent-bound settlement, pass every
mechanical conformance check in this document, and still return the
subject a rounding error while the intermediaries divide the read
between them. That implementation would meet the letter of the
return clause and defeat its purpose, which is the same failure
Section 10.6 identifies for consent itself. Fixing the subject's
position relative to the other beneficiaries is the smallest
normative statement that closes it, and it constrains no
implementation that was going to honour the return clause anyway.
The settlement instruction MUST be integrity-protected against
modification between advertisement and settlement. It MUST either be
covered by the host payment's signature or be carried as a COSE_Sign1
object signed by the disclosing substrate. A settlement instruction
whose integrity cannot be verified MUST be treated as absent, and the
read MUST NOT complete.
6.2. Settlement Timing
Settlement to the subject occurs at disclosure time, synchronously
with the read and the payment it settles. An implementation MUST
settle, or irrevocably commit to settle, the subject share as part of
the same operation that discloses the attribute. This memo does not
define deferred, credited, or session-bootstrapped settlement
arrangements; settlement under this extension is the synchronous
division of a paid read's price among its beneficiaries.
6.3. Return Clause
The subject beneficiary role satisfies the return clause: value
generated by a disclosure returns, in majority part, to the subject
of the disclosed data. An implementation that omits the subject
role, that sets the subject share to zero, that settles the subject a
share the other roles jointly equal or exceed, or that discloses an
attribute value without a settlement instruction does NOT conform to
this extension, regardless of the correctness of its consent
handling. Consent without return, and return without consent, are
each incomplete; a return the intermediaries outweigh is not a return
at all. This extension requires all three.
The return clause is satisfied by a settlement a third party can
recompute from the rail, not by the instruction that advertises it.
An instruction states an intended division; a finalised settlement is
what the rail moved. A return readable only from the instruction is
Morrison Expires 13 February 2027 [Page 11]
Internet-Draft Consent Settlement August 2026
asserted by the disclosing side, and a return that recomputes from
the rail is auditable by the subject, which is the point of settling
to them. An implementation that records only the advertised
instruction leaves the subject with the disclosing party's account of
the division and no independent means to check it.
7. Disclosure Ledger
Each conformant disclosure MUST be recorded as a typed signed event
in the substrate's identity log. Event types under this extension:
disclosure_settled Emitted on a completed paid disclosure. Payload:
the attribute reference, the SHA-256 hash of the disclosed
attribute value, the grant reference, the reader handle, the
disclosure tier, and a recomputable settlement receipt for each
beneficiary role, each binding that role's finalised payout to the
settlement network under net-balance-change-to-payTo, so the
division recomputes as the set of receipts rather than being
asserted by any one of them. A receipt binding of this kind is
described in [X402RECEIPT], whose settlement object binds a single
payTo, so one receipt per beneficiary role is the conformant
shape; receipts MAY share a settlement transaction digest where a
deployment pays every role in one transaction. A subject
verifying their own return needs only the receipt whose payTo is
theirs, and MUST NOT be required to recompute the division to do
it. Recording the content address of the advertised settlement
instruction alone does NOT satisfy this field, because an
instruction states an intended division rather than a completed
one. The attribute value itself is NEVER included.
disclosure_refused Emitted on a refused disclosure. Payload: the
attribute reference, the reader handle, and the refusal reason (no
grant, scope mismatch, expiry, revocation, payment failure).
grant_revoked Emitted on subject revocation of a grant. Payload:
the grant_id, the revocation token preimage, and the revocation
time.
The ledger records the fact and the price of a disclosure without
exposing the attribute value, so that a subject can audit who read
what category of attribute, under which grant, for what return,
without the ledger itself becoming a disclosure surface.
8. Composition
Morrison Expires 13 February 2027 [Page 12]
Internet-Draft Consent Settlement August 2026
8.1. With an Attestation Envelope
This extension composes above an identity-attestation envelope and
does not duplicate it. The envelope asserts which subject an
attribute is about and which issuer vouches for it; this extension
binds the disclosure of that attested attribute to the subject's
consent and settlement. A deployment MAY carry an attestation
envelope of any format alongside the advertisement of Section 5,
provided the envelope names the subject by a handle resolvable per
[IDPRONOUNS] and [MCPDNS]. The extension reads the subject identity
from the envelope and is otherwise indifferent to the envelope's
internal structure.
That indifference bounds what this extension can guarantee, and the
bound is stated here as a requirement on the layer beneath rather
than as a limitation of this one. A settlement floor expressed as a
majority share to the subject is only as meaningful as the subject it
names. This extension therefore requires of the layer beneath it
that the subject an envelope names be bound to a distinct person.
The requirement binds the deployment, which this document can test,
rather than the envelope layer, which it does not define. Where a
deployment settles value to subjects, the envelope it composes with
MUST be able to state that the key signing a consent grant is bound
to a credentialed unique human. The requirement is scheme-keyed and
names no scheme: any construction establishing a credentialed unique
human satisfies it, and this document takes no position on which. A
deployment composing with an envelope providing no such binding
obtains conformance to the rest of this extension without obtaining
the return the extension exists to produce. [X402PERSONHOOD]
specifies one satisfying scheme, including the case of a party that
does not pay, where control of an address is proved by an off-chain
signature over the document carrying the decision rather than by a
payment. A subject never pays, so a construction satisfying this
requirement MUST cover a party that does not pay.
This separation is deliberate. Attestation answers "who is this
about and who vouches"; this extension answers "did the subject
permit this read and does the subject share in its value". The two
are orthogonal and compose without overlap.
8.2. With an HTTP-Native Payment Protocol
The extension is carried over an [X402]-style payment flow using the
host protocol's advertise-and-echo mechanism: the server advertises
the extension in its payment-required response, and the client echoes
it in its payment payload, per the host protocol's extension model.
The settlement instruction of Section 6 is the host payment's
settlement directive enriched with beneficiary roles; the extension
Morrison Expires 13 February 2027 [Page 13]
Internet-Draft Consent Settlement August 2026
does not introduce a settlement network and does not constrain the
host protocol's choice of one. Where the host protocol defines
request-lifecycle hooks around payment verification and protected-
resource access, the consent verification of Section 5 executes in
the verification hook and the disclosure-ledger write of Section 7
executes in the post-access hook.
8.3. With Substrate and Handle Discovery
The subject's signing key, against which consent grants verify, is
the public key bound to the subject in the attestation envelope of
Section 3. A verifier obtains that key from the envelope it already
holds as the attestation input, so verification requires no external
key-discovery step. The means by which an envelope and its signing
key are published and discovered are out of scope for this extension;
one such discovery surface is described informatively in [MCPDNS].
The subject and reader handles are Sovereign-tier identifiers in the
subject's namespace; one such namespace is described in [IDPRONOUNS].
The extension introduces no new discovery surface.
8.4. With the Identity Accord
[IDACCORD] specifies a bilateral consent envelope between two legal
entities reaching a negotiated agreement. This extension specifies a
unilateral, per-read consent grant from a subject to a reader scope.
The two are siblings: the Accord governs a standing bilateral
relationship; this extension governs an individual metered
disclosure. A deployment MAY use an Accord's permitted-purpose scope
as the policy under which a class of consent grants is issued, but
the two objects are independent and neither requires the other.
9. IANA Considerations
This memo requests that IANA establish one registry and register one
media type.
9.1. Consent-Settlement Beneficiary Roles Registry
A registry of beneficiaries[].role values for the settlement
instruction of Section 6. Initial entries:
Morrison Expires 13 February 2027 [Page 14]
Internet-Draft Consent Settlement August 2026
+=============+===========+=====================================+
| role | reference | description |
+=============+===========+=====================================+
| subject | this | The subject of the disclosed |
| | document | attribute. REQUIRED in every |
| | | conformant instruction, and settled |
| | | above the floor of Section 6.1. |
+-------------+-----------+-------------------------------------+
| operator | this | The party operating the disclosing |
| | document | substrate. |
+-------------+-----------+-------------------------------------+
| facilitator | this | A party facilitating the read or |
| | document | the payment. |
+-------------+-----------+-------------------------------------+
Table 1
Registration policy: Specification Required [RFC8126]. The
designated expert confirms that a registration references a stable
specification defining the role's meaning and its settlement
semantics, and that it does not displace or weaken the REQUIRED
subject role. New roles are registered by Internet-Draft or RFC.
The change controller for this registry and its initial entries is
the author of this document.
9.2. Media Type
This memo requests registration of the media type application/
consent-settlement-grant+cbor per [RFC6838], with the following
information:
* Type name: application
* Subtype name: consent-settlement-grant+cbor
* Required parameters: none
* Optional parameters: version (the value of the grant payload's
version field).
* Encoding considerations: binary; deterministic CBOR per [RFC8949]
Section 4.2.
* Security considerations: see Section 10 of this document.
* Interoperability considerations: see Section 5 of this document.
* Published specification: this document.
Morrison Expires 13 February 2027 [Page 15]
Internet-Draft Consent Settlement August 2026
* Applications that use this media type: implementations of the
consent-settlement extension specified in this document,
exchanging subject-signed consent grants over an HTTP-native
payment flow.
* Fragment identifier considerations: none.
* Additional information:
- Deprecated alias names for this type: none
- Magic number(s): none
- File extension(s): none
- Macintosh file type code(s): none
* Person & email address to contact for further information: Blake
Morrison blake@truealter.com (mailto:blake@truealter.com).
* Intended usage: COMMON
* Restrictions on usage: none.
* Author: Blake Morrison blake@truealter.com
(mailto:blake@truealter.com).
* Change controller: the author (Blake Morrison, Alter Meridian Pty
Ltd).
* Provisional registration? No.
10. Security Considerations
10.1. Grant Forgery and Subject-Key Compromise
A consent grant's authenticity rests on the subject's Sovereign-tier
signing key. Compromise of the key permits an attacker to forge
grants permitting reads the subject never authorised. Mitigations:
* Sovereign-tier signing keys SHOULD be held in hardware-backed
custody and SHOULD NOT be exported in plaintext.
* The subject's attestation envelope (Section 3) binds the canonical
signing key; a compromised key SHOULD be rotated by republishing
the envelope with a new key and recording the rotation in the
subject's identity log. A server SHOULD verify the grant's
signing key was current at the grant's inception.
Morrison Expires 13 February 2027 [Page 16]
Internet-Draft Consent Settlement August 2026
10.2. Signature-Algorithm Agility and Downgrade
The COSE signature algorithm is carried in the grant's protected
header. An attacker able to influence a subject's published key
material may attempt to force a weak algorithm. Mitigations:
* A verifier MUST reject a grant whose signature algorithm is below
the floor the substrate publishes for Sovereign-tier keys; an
EdDSA signature over Ed25519 [RFC8032] is RECOMMENDED as that
floor.
* The algorithm identifier is inside the signed protected header, so
an in-transit downgrade of that field invalidates the signature.
10.3. Grant Substitution
A malicious server may advertise one subject while resolving a valid
grant issued by a different subject, or a valid grant of the
advertised subject scoped to a different attribute, to manufacture
the appearance of consent for a disclosure the subject did not
authorise. Mitigations:
* The verification steps of Section 5 bind the disclosure to the
grant: the server MUST confirm the grant's subject equals the
advertised subject and the attribute_ref is within the grant's
attributes before disclosing, and MUST refuse a disclosure whose
grant fails either check.
* The disclosure ledger records the grant reference against the
attribute reference and the reader, so a subject auditing the
ledger can detect a disclosure attributed to a grant they never
issued for that attribute.
10.4. Stale-Grant Replay
A revoked or expired grant may be replayed by a reader, or by a
server colluding with a reader, to justify a disclosure the subject
has withdrawn. Mitigations:
* A server MUST check the subject's identity log for a revocation
event before each disclosure, not only at first use of a grant.
* Grant validity windows SHOULD be set conservatively; an open-ended
grant is a standing liability the subject must actively revoke.
* The disclosure ledger of Section 7 makes a replayed disclosure
visible to the subject after the fact even where prevention
failed.
Morrison Expires 13 February 2027 [Page 17]
Internet-Draft Consent Settlement August 2026
10.5. Settlement Evasion
A server may disclose an attribute while omitting, zeroing, or
misdirecting the subject beneficiary role, capturing the value the
subject is owed. A subtler form of the same attack leaves the
subject role in place and dilutes it, settling the subject a nominal
share while a set of substrate-defined roles divides the rest, so
that the instruction reads as conformant to any check that tests only
for the role's presence. Mitigations:
* A conformant reader SHOULD refuse to complete a read whose
settlement instruction lacks a subject role matching the
advertised subject, and SHOULD refuse a read whose subject share
does not exceed the sum of the other roles' shares. Both tests
are arithmetic on the instruction the reader already holds, so
neither requires trusting the server.
* Adding beneficiary roles does not weaken the subject's position.
The floor of Section 6.1 is stated against the sum of the other
roles rather than against each one, so a substrate cannot dilute
the subject by splitting its own take across more roles.
* The disclosure ledger records one recomputable settlement receipt
per beneficiary role rather than the advertised instruction alone,
so a subject auditing the ledger recomputes their own finalised
payout against the settlement network and detects a disclosure
that settled to a role set excluding them, or that settled their
share below the floor. Per-role receipts also bound what an audit
requires. A subject checking their own return needs only the
receipt naming their address, so verification requires learning
nothing about what any other beneficiary was paid. Where receipts
share a settlement transaction on a transparent network, the other
payouts remain visible on the chain itself; a deployment wanting
that separation observable in the settlement settles roles in
separate transactions. A ledger carrying only the instruction
records the intention and not the act, which is the gap this class
of evasion exploits.
* Substrate operators SHOULD publish the settlement policy they
apply, so that the subject share is an inspectable commitment, not
a per-read discretion.
Morrison Expires 13 February 2027 [Page 18]
Internet-Draft Consent Settlement August 2026
10.6. Consent-Theatre Resistance
An implementation may attempt to satisfy the letter of consent
binding while defeating its purpose, for example by coercing a
subject into a broad any-reader, all-attribute, no-expiry grant at
account creation and treating it as standing permission for all
future reads. This is consent in form without consent in substance.
Mitigations are partly outside protocol scope, but:
* Per-read advertisement of the specific subject, attribute_ref, and
tier means a substrate CAN issue narrow, short-lived grants; the
ledger makes the breadth of a grant and the volume of reads under
it visible to the subject.
* Substrate operators SHOULD prefer attribute-scoped and tier-scoped
grants over any-reader blanket grants, and SHOULD expose to the
subject the reads accruing under each grant.
10.7. Tier and Classifier Manipulation
Where disclosure tiers are priced and consent-scoped per tier, a
reader may craft a request that a server misclassifies into a lower
tier than the disclosure warrants, underpaying the subject and
exceeding the grant's tier scope. Mitigations:
* Tier classification SHOULD be a server-side determination bound to
the attribute actually disclosed, not a reader-asserted field the
server trusts.
* A disclosure whose realised tier exceeds the grant's permitted
tiers MUST be refused, not silently downgraded.
11. Privacy Considerations
11.1. Compute-Location of Subject Observations
Where an attribute is inferred from a subject's own activity, the
provenance of that inference is itself sensitive. An attribute
inferred from observations that must remain on the device that
computed them MUST NOT be disclosed in a manner that exports those
underlying observations; only the attribute, under grant and
settlement, is disclosed. This extension carries no raw observation
and the disclosure ledger carries no attribute value, so the
disclosure surface is bounded to the attribute itself under the
subject's grant.
Morrison Expires 13 February 2027 [Page 19]
Internet-Draft Consent Settlement August 2026
11.2. Ledger Observability
The disclosure ledger records reader handles, attribute references,
tiers, and prices. An adversary with access to a subject's identity
log can observe who reads which categories of attribute about the
subject and how often, even without access to any attribute value.
Mitigations:
* Identity logs MAY be encrypted at rest; cross-substrate
reconciliation does not require exposing log contents.
* Reader handles in disclosure events MAY be pseudonymous where the
substrate permits, while the settlement still directs the subject
share correctly.
11.3. Subject Linkage Across Readers
A subject's attribute, disclosed to many readers, may be correlated
across them to reconstruct a fuller profile than any single
disclosure intended. This extension does not prevent downstream
correlation by colluding readers; it bounds what is disclosed per
read to the granted attribute and makes the pattern of reads
auditable to the subject, so that a subject who observes an
unexpected concentration of reads can revoke.
12. Implementation Status
A reference implementation of consent binding and subject settlement
over an HTTP-native payment flow is in active development by the
specification's author, comprising a payment-required advertisement,
a consent-grant verification path, a synchronous beneficiary-role
settlement step including a subject role, and a disclosure ledger.
In the spirit of [RFC7942], the present author notes that this
section documents implementation intent and is expected to be removed
before the document advances beyond the Independent Stream. No claim
of interoperability is made.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Morrison Expires 13 February 2027 [Page 20]
Internet-Draft Consent Settlement August 2026
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
13.2. Informative References
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Morrison Expires 13 February 2027 [Page 21]
Internet-Draft Consent Settlement August 2026
[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers
via DNS TXT Records", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
discovery/>.
[IDPRONOUNS]
Morrison, B., "Identity Pronouns: A Reference-Axis
Extension to ~handle Identity Systems", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-identity-
pronouns/>.
[IDACCORD] Morrison, B., "Identity Accord Protocol: A Peer Ceremony
for Bilateral Agreements Between Identity-Substrate-Bound
Principals", 2026, <https://datatracker.ietf.org/doc/
draft-morrison-identity-accord/>.
[X402] x402 Foundation (Linux Foundation), "x402: An Open
Standard for HTTP-Native Payments", 2026,
<https://github.com/x402-foundation/x402>.
[X402RECEIPT]
x402 Foundation (Linux Foundation), "docs(specs): add
settlement-receipt binding extension (x402 issue 2666)",
2026,
<https://github.com/x402-foundation/x402/issues/2666>.
[X402PERSONHOOD]
x402 Foundation (Linux Foundation), "Proposal: personhood-
gated resources, require a proof-of-personhood alongside
x402 payment (x402 issue 2677)", 2026,
<https://github.com/x402-foundation/x402/issues/2677>.
Changes from draft-morrison-consent-settlement-03
This revision makes two corrections, both raised in review of -03 and
both taken in the reviewer's wording.
The first is the close of the composition section. -03 ended that
section by naming the non-paying-party case of [X402PERSONHOOD] as
the case the section relied on, which made the requirement depend on
one specification rather than state a property of itself. A subject
never pays, so coverage of a party that does not pay is a property
any satisfying construction must have, and this revision requires it
of the construction instead. [X402PERSONHOOD] is still cited as one
satisfying scheme, and nothing else in the section changed.
Morrison Expires 13 February 2027 [Page 22]
Internet-Draft Consent Settlement August 2026
The second is the settlement-evasion mitigation for per-role
receipts. -03 said that verifying one's own receipt exposed nothing
about what any other beneficiary was paid. That overclaims against
-03's own allowance for receipts sharing a settlement transaction
digest, because resolving that digest on a transparent settlement
network shows every balance change in the transaction. What per-role
receipts bound is what verification requires learning; whether the
rest is discoverable is a property of the settlement network and of
the shared-digest choice. The two are now stated separately, and the
mitigation names the deployment lever, which is settling roles in
separate transactions.
Nothing else in the document changed.
Acknowledgements
This memo arose from a single question about the economics of
identity reads: when an agent pays to read an identity attribute
about a person, what does the person get? The observation that the
payment layer and the attestation layer each serve a different party,
and that neither serves the person the data is about, is the
observation behind this specification. Consent binding and subject
settlement are the two functions that close that gap, and they are
specified here as one extension because the subject relationship
requires both and is satisfied by neither alone.
Contributors
Christopher Whiteside
Email: cwhiteside.engineering@gmail.com
Author's Address
Blake Morrison
Alter Meridian Pty Ltd
Email: blake@truealter.com
Morrison Expires 13 February 2027 [Page 23]