Blake Morrison

Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments

Internet-Draft, revision 07, 22 Oct 2026. Not adopted as a standard.

Official text and revision history on the IETF datatracker

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

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 a relationship with the person the attribute is about. Existing work covers the first two. 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. 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 [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].

Handle A ~handle naming a subject, reader or beneficiary. Each handle in this document corresponds to the alter:~handle URI defined in [ALTER-URI]. 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.

payTo The destination address of a settlement, as named in the receipt binding of [X402RECEIPT]. A receipt binds one payTo.

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.

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

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.

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

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.2. The grant payload is a CBOR map with keys:

The grant is content-addressed by the SHA-256 hash of its complete COSE_Sign1 serialisation, deterministically encoded per [RFC8949] Section 4.2. Hashing the whole serialisation makes the content address commit 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:

Before disclosing the attribute value, the server MUST:

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:

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.

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

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

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. The division is recomputed from the whole set of receipts and is asserted by none of them alone. [X402RECEIPT] describes a receipt binding of this kind, and because its settlement object binds a single payTo, 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 and never the attribute value. A subject can audit from it who read what category of attribute, under which grant and for what return, while the ledger itself never becomes a disclosure surface.

8. Composition

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.

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 therefore falls on the deployment, which this document can test, and not on an envelope layer 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. Since a subject never pays, 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.

8.2. With an HTTP-Native Payment Protocol

The extension is carried over an [X402]-style payment flow, whose HTTP semantics are those of [RFC9110], 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.

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 and needs 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:

+=============+===========+=====================================+
| 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:

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:

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:

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:

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:

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. The subject is settled a nominal share while a set of substrate-defined roles divides the rest, and the instruction passes any check that tests only for the role's presence. Mitigations:

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. Mitigations are partly outside protocol scope, but:

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:

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 ([MORRISON-IFT], 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. Because this extension carries no raw observation and the disclosure ledger carries no attribute value, the disclosure surface is bounded to the attribute itself under the subject's grant.

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:

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. A subject who observes an unexpected concentration of reads can then 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 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. 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>;.

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

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

[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", Work in Progress, Internet-Draft, draft-morrison-mcp-dns-discovery-09, 2026, <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-discovery/>;.

[ALTER-URI] Morrison, B., "The 'alter' URI Scheme for Dispatchable ~handle References", Work in Progress, Internet-Draft, draft-morrison-alter-uri-scheme-05, 2026, <https://datatracker.ietf.org/doc/draft-morrison-alter-uri-scheme/>;.

[MORRISON-IFT] Morrison, B., "Identity Field Theory: Toward a Physics of Being Known", 2026, <https://doi.org/10.6084/m9.figshare.31951383>;.

[IDPRONOUNS] Morrison, B., "Identity Pronouns: A Reference-Axis Extension to ~handle Identity Systems", Work in Progress, Internet-Draft, draft-morrison-identity-pronouns-05, 2026, <https://datatracker.ietf.org/doc/draft-morrison-identity-pronouns/>;.

[IDACCORD] Morrison, B. and C. Whiteside, "Identity Accord Protocol: A Peer Ceremony for Bilateral Agreements Between Identity-Substrate-Bound Principals", Work in Progress, Internet-Draft, draft-morrison-identity-accord-03, 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>;.

Document History

draft-morrison-consent-settlement-07

draft-morrison-consent-settlement-06

draft-morrison-consent-settlement-05

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

Christopher Whiteside Email: cwhiteside.engineering@gmail.com

Antoni Jagodka Email: tjagodka@gmail.com

Author's Address

Blake Morrison Alter Meridian Pty Ltd Email: blake@truealter.com

Next: The Compute-Location Gate

Last reviewed 9 Nov 2026