]> 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 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 the read's price, and settles that subject more than every other party to the read combined. The person the data is about earns when the data is read, and earns the larger part of what the read is worth. This specification fixes a floor on the subject's position, not a ratio. Where the subject's share sits above that floor, and what the other roles are and how they divide the remainder, are policy of the settling substrate. The floor is normative because a share the intermediaries can outweigh is a fee paid to the subject, not a return of the value the subject's own data generated, and an extension that cannot tell those two apart has not served the relationship it exists to serve. The extension is deliberately narrow. It does not assert identity; an identity-attestation envelope does that, and this extension composes above it. It does not move value; a payment protocol does that, and this extension composes above it. It does not adjudicate who a credential is about; it binds the disclosure of an already- attested attribute to the subject's consent and to the subject's settlement. The two functions it adds are the two functions the subject relationship requires and the adjacent layers structurally omit. The extension composes with 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 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. Settlement to the subject occurs at disclosure time, synchronously with the read.
4. Disclosure ledger (Section 7). Each disclosure is recorded as a typed signed event in the substrate's identity log, binding the attribute hash, the grant reference, the reader, and the settled price into an auditable record without exposing the attribute value.

Layers 2 and 3 are the substance of this extension. Layer 1 is assumed present and is referenced, not defined. The record of Layer 4 is REQUIRED for a conformant disclosure but its transport and retention are substrate concerns. The extension is carried over an -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 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.

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 rather than advisory for a reason that is structural, not economic. A requirement that the subject share merely exceed zero is satisfied by a share of any size, including one chosen to be too small to notice. Under such a requirement an implementation can advertise consent-bound settlement, pass every mechanical conformance check in this document, and still return the subject a rounding error while the intermediaries divide the read between them. That implementation would meet the letter of the return clause and defeat its purpose, which is the same failure Section 10.6 identifies for consent itself. Fixing the subject's position relative to the other beneficiaries is the smallest normative statement that closes it, and it constrains no implementation that was going to honour the return clause anyway. The settlement instruction MUST be integrity-protected against modification between advertisement and settlement. It MUST either be covered by the host payment's signature or be carried as a COSE_Sign1 object signed by the disclosing substrate. A settlement instruction whose integrity cannot be verified MUST be treated as absent, and the read MUST NOT complete.

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 majority part, to the subject of the disclosed data. An implementation that omits the subject role, that sets the subject share to zero, that settles the subject a share the other roles jointly equal or exceed, or that discloses an attribute value without a settlement instruction does NOT conform to this extension, regardless of the correctness of its consent handling. Consent without return, and return without consent, are each incomplete; a return the intermediaries outweigh is not a return at all. This extension requires all three.

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

References 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 x402 Foundation (Linux Foundation)

Changes from draft-morrison-consent-settlement-01 This revision makes one substantive change. The requirement on the subject's share of a read's price, which -01 stated as a share greater than zero, is now a share greater than the sum of the shares of every other role in the settlement instruction. Section 6.1 carries the requirement and the reasoning for it; the abstract, the introduction, the definitions of settlement instruction and return clause, the architectural overview, the tiered-pricing rule, the return clause, the settlement-evasion mitigations, and the IANA registry entry for the subject role are aligned to it. The change reverses a position -01 took explicitly. That revision held that the specification should fix the existence of a subject beneficiary role and leave its magnitude entirely to the settling substrate. On reflection that leaves the return clause unfalsifiable: an implementation settling the subject an arbitrarily small share conforms in full, and no reader or auditor can distinguish it from one honouring the clause. A floor stated against the other roles in aggregate is the smallest change that makes the clause testable on the wire, and it still leaves the substrate every decision above the floor. Nothing else in the document changed.

Acknowledgements This memo arose from a single question about the economics of identity reads: when an agent pays to read an identity attribute about a person, what does the person get? The observation that the payment layer and the attestation layer each serve a different party, and that neither serves the person the data is about, is the observation behind this specification. Consent binding and subject settlement are the two functions that close that gap, and they are specified here as one extension because the subject relationship requires both and is satisfied by neither alone.

Contributors

cwhiteside.engineering@gmail.com