]> Alter Meridian Pty Ltd

blake@truealter.com

Independent Submission 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 defined share of the read's price. 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 and , and the HTTP semantics are normative per .

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 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 a defined share of the read's price. The person the data is about earns when the data is read. The share is a policy of the settling substrate, not a constant of this specification; the specification fixes the requirement that a subject beneficiary role exists and is settled, not the ratio. 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 as the payment flow, with an identity-attestation envelope (referenced abstractly; see Section 3) as the layer asserting the subject, with for substrate and key discovery, with for the subject-handle namespace, and with as a sibling consent-envelope ceremony for the bilateral-agreement case.

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 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 .

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 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.

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 defined part, to the subject of the disclosed data. The return clause is satisfied by the subject beneficiary role of the settlement instruction.

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.

Architectural Overview The extension comprises three composed layers and a record, each addressable independently. 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 and , and that the envelope's issuer signature be verifiable. The envelope format is out of scope. 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. Subject settlement (Section 6). The payment carries a settlement instruction enumerating beneficiary roles, of which a subject role is REQUIRED. Settlement to the subject occurs at disclosure time, synchronously with the read. 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 -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.

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. 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.

Consent Binding

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 .

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 or a handle.

Consent Grant Object A consent grant is a COSE_Sign1 object (CBOR tag 18) wrapping a CBOR-encoded payload , 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, ): start of validity. expiry (text string, , 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. The grant is content-addressed by the SHA-256 hash of its complete COSE_Sign1 serialisation, deterministically encoded per 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.

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: 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). Verify that the grant's subject equals the advertised subject and that attribute_ref is a member of the grant's attributes. Verify that the reader satisfies the grant's reader_scope. Verify the grant's validity window against the current time and evaluate any conditions. 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.

Subject Settlement

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: 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, and the subject role's share MUST be greater than zero. The presence and positivity of the subject share is the normative requirement of this section; the magnitude of the share, and the set and shares of the other roles, are policy of the settling substrate and are NOT fixed by this specification. 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.

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.

Return Clause The subject beneficiary role satisfies the return clause: value generated by a disclosure returns, in defined part, to the subject of the disclosed data. An implementation that omits the subject role, that sets the subject share to zero, 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; this extension requires both.

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 the settlement instruction's content address. 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.

Composition

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 and . The extension reads the subject identity from the envelope and is otherwise indifferent to the envelope's internal structure. 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.

With an HTTP-Native Payment Protocol The extension is carried over an -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 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.

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 . The subject and reader handles are Sovereign-tier identifiers in the subject's namespace; one such namespace is described in . The extension introduces no new discovery surface.

With the Identity Accord 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.

IANA Considerations This memo requests that IANA establish one registry and register one media type.

Consent-Settlement Beneficiary Roles Registry A registry of beneficiaries[].role values for the settlement instruction of Section 6. Initial entries: role reference description subject this document The subject of the disclosed attribute. REQUIRED in every conformant instruction. operator this document The party operating the disclosing substrate. facilitator this document A party facilitating the read or the payment. Registration policy: Specification Required . 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.

Media Type This memo requests registration of the media type application/consent-settlement-grant+cbor per , 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 Section 4.2. Security considerations: see Section 10 of this document. Interoperability considerations: see Section 5 of this document. Published specification: this document. 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. Intended usage: COMMON Restrictions on usage: none. Author: Blake Morrison blake@truealter.com. Change controller: the author (Blake Morrison, Alter Meridian Pty Ltd). Provisional registration? No.

Security Considerations

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.

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 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.

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.

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.

Settlement Evasion A server may disclose an attribute while omitting, zeroing, or misdirecting the subject beneficiary role, capturing the value the subject is owed. Mitigations: A conformant reader SHOULD refuse to complete a read whose settlement instruction lacks a positive subject role matching the advertised subject. The disclosure ledger records the settlement instruction's content address; a subject auditing the ledger can detect a disclosure that settled to a role set excluding them. Substrate operators SHOULD publish the settlement policy they apply, so that the subject share is an inspectable commitment, not a per-read discretion.

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.

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.

Privacy Considerations

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.

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.

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.

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 , 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.

&RFC2119; &RFC3339; &RFC8032; &RFC8174; &RFC8615; &RFC8949; &RFC9052; &RFC9110; &RFC6838; &RFC7942; &RFC8126; Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd x402 Foundation (Linux Foundation)

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.