]> Alter Meridian Pty Ltd

blake@truealter.com

Independent Submission agent identity transparency service HTTP 402 registration policy autonomous agent This memo describes a profile by which an autonomous agent that has no human or organisational principal at the root of its delegation chain registers itself, on its own behalf, as an economic principal in a transparency service, and by which that registration is the specific act that makes the agent eligible to be paid for subsequent reads of its own identity record. Admission of the agent's Signed Statement to the transparency service is gated on settlement of an HTTP payment challenge returned with the 402 (Payment Required) status. The profile makes no change to the registration semantics of the underlying transparency service: payment is expressed as an operator Registration Policy and authentication-layer concern, and where the payment is authoritative to the admission decision the payment proof is carried as an authenticated input committed to the service's verifiable data structure, so that admission remains a deterministic function of committed inputs and stays replayable by an auditor. The profile is positioned against the current agent- identity drafts, which either require a human principal at the root of the chain or leave the owner-less case undefined; it occupies that undefined seam without contradicting them. This document is Informational.

Introduction An autonomous software agent can now hold credentials, make paid HTTP requests, and act without a person in the loop for the duration of a task. The standards that describe how such an agent proves who it is, and on whose authority it acts, have converged on a delegation model: an agent presents a chain of authority that terminates in a principal, and a verifier trusts the agent to the extent it trusts that principal and the links between it and the agent. The published work decides the question of what stands at the root of that chain in one of two ways. Some drafts require the root to be a person or an organisation. Others contemplate an agent acting on its own behalf but stop short of defining what registering and being paid on one's own behalf actually requires. Neither construction serves an agent that has no human or organisational principal to attribute its actions to, yet participates in an economy: it reads, it is read, and value moves for those reads. Such an agent is an economic actor whose economic identity no current registration flow constructs. This memo describes a profile that constructs it. The agent registers itself as its own economic principal in a transparency service. The registrant of the Signed Statement and the beneficiary of the resulting record are the same owner-less agent, with no upstream principal referenced. Admission of that Statement is gated on payment: the registration endpoint answers an unpaid attempt with the 402 (Payment Required) status defined in , and admits the Statement only once a payment proof satisfies the challenge. Once admitted, the agent's principal record is the payee of record for subsequent priced reads of its own identity, so registration is the act that opens earn-eligibility and not a bare identity claim. The profile is deliberately thin. It adds no normative requirement to the transparency service it runs over. It expresses payment entirely within the space the transparency-service architecture already leaves to the operator, and it takes care that where payment is authoritative to admission, the payment proof is committed to the service's verifiable data structure so that the auditability property the service depends on is preserved. Its contribution is to name, and to make interoperable, the owner-less economic-principal registration that the surrounding drafts leave undefined.

Conventions and Terminology 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 used throughout this document.

Transparency Service:

A service that admits signed statements to an append-only, cryptographically verifiable data structure and issues receipts proving admission, as described in the SCITT architecture and its reference APIs . This document does not restrict the profile to any single such service; it uses SCITT as the reference model.

Signed Statement:

A signed claim submitted for admission to a Transparency Service.

Registration Policy:

The operator-defined set of checks a Transparency Service applies before admitting a Signed Statement. The contents of Registration Policies are out of scope for the transparency-service specifications and are left to the operator (, Section 5.1.1; ).

Owner-Less Agent Principal:

An agent principal record that carries no reference to an upstream human or organisational principal at the root of its delegation chain. The canonical machine-checkable predicate is a credential whose delegated-subject field is null.

Registration Entry:

The Signed Statement admitted to a Transparency Service under this profile, together with the Receipt proving its admission. This is the artefact another profile references when it needs to name a principal registered under this one ().

Payment Challenge:

A description of a required payment, returned by the registration endpoint with the 402 (Payment Required) status, specifying at least an amount and a settlement destination.

Payment Proof:

Evidence, presented by the registrant, that the Payment Challenge has been settled.

Receipt:

The proof of admission returned by the Transparency Service for an admitted Signed Statement.

Earn-Eligible Payee:

The state of a registered principal record that makes it eligible to receive settlement for subsequent reads of, or queries against, its own identity record.

Settlement Event:

A payment that moves value from a payer to a payee for a read of, or query against, an identity record.

Relationship to Existing Work

Payment is Out of Scope for the Transparency Service, by Design The SCITT architecture places the scope of the checks a Transparency Service applies before admission with the operator: the architecture "leaves ... Registration Policies and trust anchors to the operator" (Section 5.1.1), and treats authentication and authorization as "implementation specific and out of scope" (Section 6.3). The reference APIs carry this through: Registration Policy contents are "intentionally out of scope", the policy "MUST be applied before any additional processing", and authentication "is out of scope", with the note that where authentication is not implemented, "rate limiting or other denial of service mitigations MUST be implemented". The status codes SCRAPI enumerates for the registration endpoint do not include 402; a policy refusal is reported as 400. The omission of a payment step is therefore a scoping decision, not a gap: payment sits above or beside the transparency service as an operator admission concern. This profile uses that existing operator space to gate the admission of an owner-less agent's registration on payment; it introduces no payment mechanism of its own and claims no novelty in payment-gating as such. Its contribution is the owner-less economic-principal registration of and the earn-linkage of , not the operator payment step those sections rest on. Using the operator space in this way violates none of the transparency-service specifications' normative requirements, provided it stays within the operator policy and authentication space those specifications leave open, and provided it respects the constraint described next.

Authoritative Inputs Must Be Committed constrains how unauthenticated signals may influence admission: an implementation "MUST NOT use unauthenticated signals as authoritative inputs to the registration decision", and any processing decision that affects the outcome of registration must be "fully determined by authenticated inputs, or ... captured in the Verifiable Data Structure, such that the registration process remains deterministic and replayable by Auditors" (Section 4.4.2.3). This constraint shapes the profile. A payment that gates admission of the owner-less agent's Statement, that is, a Signed Statement admitted because it was paid for, makes the payment proof an authoritative input to the registration decision. To respect Section 4.4.2.3, such a proof MUST be either an authenticated input to the decision or committed to the verifiable data structure alongside the Statement. specifies both compliant forms.

The Agent-Identity Drafts Leave the Owner-Less Case Undefined The agent-identity drafts decide, or decline to decide, what stands at the root of an agent's delegation chain. decides it in favour of a human or organisational principal: every delegation chain is required to have a verifiable principal at its root. An agent that is itself the root, with no upstream principal to verify, is outside that construction. contemplates an autonomous agent request that is "not attributable to a specific upstream principal" and requires such requests to be distinguished from delegated ones, but it does not define the principal at the root as anything other than "a user or a service", and it builds no registration-to-be-paid construction on the unattributed case. permits an agent to act "on its own behalf" in addition to acting for a user or a system, but specifies no registration flow, no payment step, and no linkage from registration to earning. roots authority at a human-agnostic issuer and deliberately omits a subject claim, but it is a token-attenuation scheme rather than a registration-to-a-transparency-service or earn-eligibility construction. The owner-less agent that registers itself and is thereby made payable is therefore an undefined seam across this body of work: one draft forecloses it and the rest leave it unbuilt. This profile occupies the seam. It does not contradict any of these drafts; an operator that adopts one of them for delegated agents can adopt this profile for owner-less agents in the same deployment.

Protocol Overview The registration flow has five steps. Register. An owner-less agent submits, to the Transparency Service's registration endpoint, a request to admit a Signed Statement that names the submitting agent as the sole registrant and beneficiary. The agent is represented by an Owner-Less Agent Principal record, that is, a credential whose delegated-subject field is null. Challenge. The endpoint, applying its Registration Policy, answers an unsettled registration attempt with the 402 (Payment Required) status and a Payment Challenge naming an amount and a settlement destination. Pay. The agent settles the challenge from value it holds, for example over an HTTP-native payment flow such as , and obtains a Payment Proof. Admit. The agent resubmits with the Payment Proof. The endpoint admits the Signed Statement only if the proof satisfies the challenge and the remainder of the Registration Policy passes. The admission decision is a deterministic function of committed inputs, per . Receipt. The Transparency Service returns a Receipt proving admission. On admission the registrant's principal record is bound to Earn-Eligible Payee state. Steps 2 through 4 use the transparency service's existing operator admission path and an ordinary 402 payment interaction; the profile adds nothing to them and claims nothing in them. Steps 1 and 5, the owner-less economic-principal registrant of and the earn-linkage binding of , are the binding this profile exists to create.

The Owner-Less Agent Principal The registrant of the Signed Statement is an agent that has no human or organisational principal at the root of its delegation chain. The same agent is the beneficiary of the resulting record. There is no delegation to resolve and no upstream principal to attribute the registration to: the registration act is the root of the chain, not a link in it. The machine-checkable form of "owner-less" is a null delegated- subject binding on the credential the agent presents. A credential that carries a delegated-subject value denotes a delegated principal and is out of scope for this profile; a credential whose delegated- subject field is null denotes an owner-less principal and is the subject of this profile. This predicate is what distinguishes an owner-less registration from a self-service registration performed by a human-delegated agent, and an operator MAY use it to decide whether the owner-less branch of its Registration Policy applies. Distinguishing owner-less from delegated principals at registration time is consistent with the requirement in that autonomous requests be clearly distinguished from delegated ones.

Payment-Gated Admission Gating the admission of an owner-less agent's Signed Statement on payment is expressed within the operator policy and authentication space the transparency-service specifications leave open (, Sections 5.1.1 and 6.3; , Section 4.3). This profile defines no payment mechanism of its own. Within that existing operator space an operator has two SCRAPI-compliant placements of the payment step available, and where it gates the owner-less registration on payment it MUST adopt one of them; the profile identifies which placements keep the owner-less registration compliant, and claims no novelty in the placements themselves. The difference between them is whether the payment is authoritative to the admission decision.

Payment as a Reachability Meter In this placement, the Payment Challenge meters the ability to reach or attempt the owner-less agent's registration and does not enter the admission decision. Payment sits at the authentication and denial-of-service-mitigation layer that Section 4.3 already contemplates, standing in for the rate limiting that section requires where authentication is absent. The admission decision is determined solely by the Registration Policy, independent of the Payment Proof. This placement is fully compliant and requires no commitment of the Payment Proof to the verifiable data structure, because the proof is not an authoritative input. It is also weaker: it conditions the ability to attempt registration on payment, not admission itself.

Payment as a Committed Authoritative Input In this placement, admission is conditioned on payment: the owner-less agent's Signed Statement is admitted because the challenge was settled. The Payment Proof is therefore an authoritative input to the registration decision, and to satisfy Section 4.4.2.3 it MUST be carried as an authenticated input and committed to the verifiable data structure alongside the Signed Statement. Because the proof is committed, the admission decision remains a deterministic function of inputs recorded in the verifiable data structure, and an auditor can replay the decision from the ledger alone, without trusting an out-of-band payment rail. This placement delivers payment-gated admission in the sense the profile intends while preserving the auditability property the transparency service depends on. It is the RECOMMENDED placement where the operator intends payment to gate admission rather than merely to meter access. An operator MUST NOT treat an uncommitted, unauthenticated Payment Proof as authoritative to admission; doing so would violate Section 4.4.2.3.

Earn-Linkage On admission, the registrant's principal record is bound to Earn-Eligible Payee state. From that point the record is the payee of record for Settlement Events that read or query the agent's own identity record. A read of the agent's identity by a distinct party settles value, and the registered agent's share of that value is directed to it as the payee. Registration is the act that opens this eligibility; before admission the agent has no payee record to credit, and after admission it does. The size of any payee share is a policy of the settling substrate and is not fixed by this profile. What the profile fixes is that Earn-Eligible Payee state exists, that it is opened by admission, and that it is governed by the guardrails in .

Crediting Guardrails An earn-linkage that credited any Settlement Event to the payee without constraint would let an owner-less agent fabricate value by paying itself, and would be rejected on its face as circular self-funding. The profile therefore treats the crediting of a Settlement Event as a Registration-Policy concern subject to a set of predicates. The predicates are operator policy; this document enumerates the classes an operator SHOULD apply and does not fix their parameters. Cross-party settlement. A Settlement Event whose payer resolves to the same principal record as the payee SHOULD NOT be credited. This is the primary predicate: it prevents an agent crediting itself directly. Net of fees. Only the settlement value remaining after deduction of protocol fees SHOULD be credited, so that routing value in a circle cannot net a gain. Bounded credit. The cumulative value credited to a payee SHOULD be bounded relative to the fees that payee has itself paid, so that a self-contained ring of settlement routed back to the same payee, directly or through intermediaries, nets at or below the bound. Active membership. A payee SHOULD hold a live, non-revoked membership status adequate to the operator's proof-of-personhood or proof-of-work requirements at the time of crediting. These predicates are what make the earn-linkage a governed economic construction rather than a naive self-payment loop. An operator that adopts the earn-linkage without an equivalent guardrail set is outside the intent of this profile.

SCITT Neutrality This profile adds no normative requirement to the transparency service it runs over. Every element it introduces lives in space the transparency-service specifications already delegate to the operator: the payment step is a Registration-Policy and authentication-layer concern ( Sections 5.1.1 and 6.3, Section 4.3); the owner-less predicate is a Registration-Policy branch; the crediting guardrails are Registration-Policy predicates on settlement. Where the payment is authoritative to admission, the profile respects Section 4.4.2.3 by committing the Payment Proof to the verifiable data structure, so the determinism and auditor- replayability of registration are preserved. An implementation of that is unaware of this profile remains conformant, and a Transparency Service that adopts this profile remains a conformant transparency service. The profile composes with the service; it does not fork it.

Composition with Agent-Identity Work The profile is intended to coexist with the agent-identity drafts rather than to displace them. An operator that uses , , , or to describe delegated agents can apply this profile to the owner-less agents those drafts leave undefined, in the same deployment, distinguishing the two branches by the null delegated-subject predicate of . Where a subsequent read of an identity record is itself a paid, consent-bound disclosure about a human subject, the settlement discipline of applies to that read; this profile governs the prior act by which the reading or the read agent registered itself as a principal.

Referencing a Registration Entry A record admitted under this profile is an ordinary admitted Signed Statement, and it is referenced the way the transparency-service specifications already reference one. This profile introduces no identifier of its own. Another profile that needs to name the principal, for example to say which party performed an action, MAY carry the Subject claim of the Registration Entry. defines that claim as the one by which a logical collection of Statements is grouped, and by which a relying party identifies all Transparent Statements associated with a single Subject. It is therefore the durable identifier of the registered principal, and it is the value such a party field wants. The digest of a Signed Statement is not that identifier. It names one admission event. expects an Issuer that becomes aware of a changed state to register a new Signed Statement under the same Issuer and Subject claims, so the digest rotates where the Subject does not. A reference that pins the digest names the admission it pinned, which is the right thing to say where a specific admission is meant, and the wrong thing to say where the principal is meant. A reference of either kind is verified by the Receipt over the Registration Entry. Admission is not liveness. A Receipt proves that the principal was admitted, as of the anchored time. It does not assert that the principal's authority, or its Earn-Eligible Payee state, is current at the time of any later action; that state is revocable without altering the admitted Signed Statement (). A verifier that reads a Registration Entry reference as a liveness claim reads it wrong, and a profile that carries such a reference SHOULD state whether it relies on the fact of admission or on the principal's authority being current at the time of the action.

IANA Considerations This document has no IANA actions. It defines no new registries, no new media types, and no new protocol elements; it profiles the use of the existing 402 (Payment Required) status and the existing Registration-Policy extension point of the transparency- service specifications.

Security Considerations

Fabricated Value and Self-Dealing The central risk of an earn-linkage is that an owner-less agent fabricates value by paying itself and crediting the payment as earnings. The crediting guardrails of address this: cross-party settlement refuses same-principal credit, net-of-fees pricing removes the gain from circular routing, the bounded-credit predicate caps what a self-contained ring can net, and the active-membership predicate raises the cost of minting the principals a ring would require. An operator that omits these predicates reintroduces the risk.

Payment-Proof Replay and Determinism Where payment is authoritative to admission, the Payment Proof is committed to the verifiable data structure (). This is what makes the admission decision replayable, but it also means the committed proof must not be reusable to admit a second Statement. An operator MUST bind each Payment Proof to the specific Statement whose admission it authorises, so that a committed proof cannot be replayed against a different registration.

Trust in the Payment Rail In the reachability-meter placement, the payment rail is trusted only to throttle access, and a compromised rail degrades to a denial-of-service or rate-limit-bypass concern. In the committed authoritative-input placement, the payment rail's proof is an input to admission; an operator MUST ensure the proof is authenticated to a degree adequate to the value of the admission it gates, since a forged proof would otherwise admit an unpaid Statement.

Sybil and Minting Pressure Because registration opens earn-eligibility, it is a target for mass owner-less registration intended to farm settlement. The active-membership predicate and the payment gate together raise the cost of each registered principal. An operator SHOULD calibrate the registration price and the membership requirement to the value of the earn-eligibility being opened.

Revocation Independent of the Ledger An operator may need to withdraw a principal's Earn-Eligible Payee state, for example on a governance sanction, without rewriting the append-only admission record. Earn-eligibility SHOULD be revocable as a state on the principal record independent of, and without altering, the admitted Signed Statement, so that the transparency service's append-only guarantee is preserved while crediting stops.

Implementation Status In the spirit of , the author notes that a reference implementation of an owner-less-principal registration branch, a payment-gated admission step, and an earn-linkage governed by the crediting guardrails of is in active development by the author. The implementation is behind a feature flag and disabled by default. This section documents implementation intent, makes no claim of interoperability, and is expected to be removed before the document advances.

&RFC2119; &RFC8174; &RFC9110; &RFC9943; &RFC7942; x402 Foundation (Linux Foundation) Alter Meridian Pty Ltd

Acknowledgements This memo arose from a single observation: an autonomous agent with no person at the root of its authority is, today, born unable to earn in its own right, even where it can read, be read, and pay. The agent-identity work either requires a human root or leaves the owner-less case undefined, and the transparency-service work deliberately leaves payment to the operator. This profile connects those two open spaces, and it does so within the operator policy and authenticated-input discipline both bodies of work already define.