]> Alter Meridian Pty Ltd

blake@truealter.com

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, CBOR and HTTP specifications are normative references, cited where used in the body of the document.

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 a relationship with the person the attribute is about. Existing work covers the first two. 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. Neither covers the third. The subject does not consent to the specific disclosure when it occurs and receives no part of the value the disclosure generates. This memo specifies an extension for the third relationship. It adds two things above an existing payment flow and an existing attestation envelope, and replaces neither. 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 reader scope. 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. 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 settling substrate. Section 6.1 gives the reason the floor is normative. The extension does not assert identity (an identity-attestation envelope does) and does not move value (a payment protocol does); it composes above both. 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 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 .

Handle

A ~handle naming a subject, reader or beneficiary. Each handle in this document corresponds to the alter:~handle URI defined in . The text-string fields of Sections 5 and 6 that carry a handle carry the bare ~handle, not the URI.

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

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 and , and that the envelope's issuer signature be verifiable. The envelope format is out of scope.
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. The subject share is settled, or committed so that the substrate cannot cancel it, at disclosure time (Section 6.2).
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 -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 Reads of identity attributes differ in 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 settled above the floor of Section 6.1.

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.

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.

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:

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.

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. 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. The floor is normative because a requirement that the subject share merely exceed zero is satisfied by a share of any size, including one 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, the same failure Section 10.6 describes for consent. Fixing the subject's position relative to the other beneficiaries closes that gap. 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 The subject share is fixed at disclosure time. An implementation MUST settle the subject share, or commit it, as part of the same operation that discloses the attribute. A share is committed when it is recorded at disclosure, the disclosing substrate has no means to cancel or reduce it, and it settles once the subject has a destination to receive it. A subject who has no such destination at the time of the read therefore does not prevent the share from being committed. A share that the substrate can still cancel or reduce after the disclosure is not committed. How a substrate holds a committed share, and when it becomes payable, are policy of the settling substrate and are not fixed by this specification.

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. Conformance requires all three of consent binding, a subject share above the floor, and a settlement the subject can recompute. 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. 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.

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 , 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. Where the subject share is committed but not yet settled (Section 6.2), the payload carries, in place of the subject's receipt, the committed amount and the subject's handle, and the receipt is recorded later by subject_share_settled. The attribute value itself is NEVER included.

subject_share_settled

Emitted when a committed subject share settles. Payload: a reference to the disclosure_settled event that committed it, and the subject's recomputable settlement receipt, bound as above. The amount settled MUST equal the committed amount.

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. Because the extension is indifferent to the envelope's format, it cannot establish that the subject an envelope names is a distinct person, and a majority share to the subject is only as meaningful as the subject it names. The requirement is therefore placed on the deployment, which this document can test, and not on 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. 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. 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, whose HTTP semantics are those of , 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, and settled above the floor of Section 6.1.
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. 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.

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. 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 (, Section 6.2). 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 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.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Informative References This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd x402 Foundation (Linux Foundation) x402 Foundation (Linux Foundation) x402 Foundation (Linux Foundation)

Document History draft-morrison-consent-settlement-06

• Section 6.2 (Settlement Timing): the requirement is restated. The subject share is settled or committed at disclosure. A share is committed when it is recorded at disclosure, the substrate cannot cancel or reduce it, and it settles once the subject has a destination. The "synchronously with the read" wording is removed here, in Section 3, and in Section 12. The sentence excluding deferred and credited arrangements is replaced by a statement that holding a committed share is substrate policy.
• Section 7 (Disclosure Ledger): a committed but unsettled subject share is recorded in disclosure_settled as its amount and the subject's handle, and a new event, subject_share_settled, records its receipt when it settles.
• Abstract: the three RFC citations are replaced by words, so the abstract carries no reference. is now cited in Section 8.2, where the HTTP semantics are relied on. The normative references are unchanged.
• Sections 1, 6.3, 8.1 and the Acknowledgements: argumentative and self-describing sentences are removed or restated plainly. No requirement changes in those sections.
• The floor (the subject share greater than the sum of all other shares) is unchanged.
• Sections 1, 4, 6.1, 6.3 and 10.6: further padding and self-describing sentences are removed. No requirement changes.
• Section 2: a Handle entry states that each ~handle corresponds to the alter:~handle URI of , added as an informative reference. The wire fields still carry the bare handle.
• Section 11.1 cites , Section 6.2, added as an informative reference.
• The changes section for -05 is replaced by this section. The Contributors list is unchanged.

draft-morrison-consent-settlement-05

• Antoni Jagodka is named as the author of the replacement text for the close of Section 8.1 and the settlement-evasion mitigation in Section 10.5, and is added to the Contributors list. No technical change.

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?

Contributors

cwhiteside.engineering@gmail.com

tjagodka@gmail.com