Registration of Owner-Less Agents as Economic Principals: A Payment-Gated Admission Profile for Transparency Services
draft-morrison-solo-agent-earn-registration-00

Independent Submission                                       B. Morrison
Internet-Draft                                    Alter Meridian Pty Ltd
Intended status: Informational                               7 July 2026
Expires: 8 January 2027

  Registration of Owner-Less Agents as Economic Principals: A Payment-
           Gated Admission Profile for Transparency Services
             draft-morrison-solo-agent-earn-registration-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Morrison                 Expires 8 January 2027                 [Page 1]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

   This Internet-Draft will expire on 8 January 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   4
   3.  Relationship to Existing Work . . . . . . . . . . . . . . . .   5
     3.1.  Payment is Out of Scope for the Transparency Service, by
           Design  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Authoritative Inputs Must Be Committed  . . . . . . . . .   6
     3.3.  The Agent-Identity Drafts Leave the Owner-Less Case
           Undefined . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   7
   5.  The Owner-Less Agent Principal  . . . . . . . . . . . . . . .   8
   6.  Payment-Gated Admission . . . . . . . . . . . . . . . . . . .   8
     6.1.  Payment as a Reachability Meter . . . . . . . . . . . . .   8
     6.2.  Payment as a Committed Authoritative Input  . . . . . . .   9
   7.  Earn-Linkage  . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Crediting Guardrails  . . . . . . . . . . . . . . . . . .  10
   8.  SCITT Neutrality  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Composition with Agent-Identity Work  . . . . . . . . . . . .  11
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  11
     11.1.  Fabricated Value and Self-Dealing  . . . . . . . . . . .  11
     11.2.  Payment-Proof Replay and Determinism . . . . . . . . . .  12
     11.3.  Trust in the Payment Rail  . . . . . . . . . . . . . . .  12
     11.4.  Sybil and Minting Pressure . . . . . . . . . . . . . . .  12
     11.5.  Revocation Independent of the Ledger . . . . . . . . . .  12
   12. Implementation Status . . . . . . . . . . . . . . . . . . . .  12
   13. Normative References  . . . . . . . . . . . . . . . . . . . .  13
   14. Informative References  . . . . . . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

Morrison                 Expires 8 January 2027                 [Page 2]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

1.  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 Section 15.5.2 of
   [RFC9110], 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.

Morrison                 Expires 8 January 2027                 [Page 3]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

2.  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 [RFC2119] [RFC8174] 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
      [RFC9943] and its reference APIs [SCRAPI].  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 ([RFC9943],
      Section 5.1.1; [SCRAPI]).

   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.

   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.

Morrison                 Expires 8 January 2027                 [Page 4]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

   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.

3.  Relationship to Existing Work

3.1.  Payment is Out of Scope for the Transparency Service, by Design

   The SCITT architecture [RFC9943] 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 [SCRAPI] 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 Section 5 and the earn-
   linkage of Section 7, 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.

Morrison                 Expires 8 January 2027                 [Page 5]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

3.2.  Authoritative Inputs Must Be Committed

   [SCRAPI] 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.  Section 6 specifies both compliant forms.

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

   [AIP] 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.

   [WIMSEARCH] 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.

   [KLRC] 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.

   [ATTENUATE] 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.

Morrison                 Expires 8 January 2027                 [Page 6]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

   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.

4.  Protocol Overview

   The registration flow has five steps.

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

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

   3.  Pay. The agent settles the challenge from value it holds, for
       example over an HTTP-native payment flow such as [X402], and
       obtains a Payment Proof.

   4.  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 Section 3.2.

   5.  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 Section 5 and the earn-
   linkage binding of Section 7, are the binding this profile exists to
   create.

Morrison                 Expires 8 January 2027                 [Page 7]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

5.  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 [WIMSEARCH] that
   autonomous requests be clearly distinguished from delegated ones.

6.  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 ([RFC9943],
   Sections 5.1.1 and 6.3; [SCRAPI], 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.

6.1.  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 [SCRAPI] 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.

Morrison                 Expires 8 January 2027                 [Page 8]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

   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.

6.2.  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 [SCRAPI] 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 [SCRAPI]
   Section 4.4.2.3.

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

Morrison                 Expires 8 January 2027                 [Page 9]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

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

8.  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 ([RFC9943] Sections 5.1.1 and 6.3, [SCRAPI] 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
   [SCRAPI] 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.

Morrison                 Expires 8 January 2027                [Page 10]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

   An implementation of [SCRAPI] 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.

9.  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 [AIP],
   [WIMSEARCH], [KLRC], or [ATTENUATE] 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 Section 5.  Where a
   subsequent read of an identity record is itself a paid, consent-bound
   disclosure about a human subject, the settlement discipline of
   [CONSENTSETTLE] applies to that read; this profile governs the prior
   act by which the reading or the read agent registered itself as a
   principal.

10.  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 [RFC9110] and the existing
   Registration-Policy extension point of the transparency-service
   specifications.

11.  Security Considerations

11.1.  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 Section 7.1 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.

Morrison                 Expires 8 January 2027                [Page 11]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

11.2.  Payment-Proof Replay and Determinism

   Where payment is authoritative to admission, the Payment Proof is
   committed to the verifiable data structure (Section 6.2).  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.

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

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

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

12.  Implementation Status

   This section is to be removed before publishing as an RFC.

Morrison                 Expires 8 January 2027                [Page 12]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

   In the spirit of [RFC7942], 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 Section 7.1 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.

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

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

   [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

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

   [RFC9943]  Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", RFC 9943,
              DOI 10.17487/RFC9943, June 2026,
              <https://www.rfc-editor.org/info/rfc9943>.

   [SCRAPI]   Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains: SCITT Reference APIs
              (SCRAPI)", Work in Progress, Internet-Draft, draft-ietf-
              scitt-scrapi, 2026, <https://datatracker.ietf.org/doc/
              draft-ietf-scitt-scrapi/>.

   [WIMSEARCH]
              Richer, J., Sheffer, Y., and A. Schwenkschuster, "Workload
              Identity in Multi-System Environments (WIMSE)

Morrison                 Expires 8 January 2027                [Page 13]
Internet-Draft        Solo-Agent-Earn Registration             July 2026

              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-wimse-arch, 2026,
              <https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.

   [AIP]      Singla, G., "Agent Identity Protocol (AIP)", Work in
              Progress, Internet-Draft, draft-singla-agent-identity-
              protocol, 2026, <https://datatracker.ietf.org/doc/draft-
              singla-agent-identity-protocol/>.

   [KLRC]     Parecki, A., "Authentication and Authorization for AI
              Agents", Work in Progress, Internet-Draft, draft-klrc-
              aiagent-auth, 2026, <https://datatracker.ietf.org/doc/
              draft-klrc-aiagent-auth/>.

   [ATTENUATE]
              Niyikiza, P., "Attenuating OAuth Tokens for AI Agents",
              Work in Progress, Internet-Draft, draft-niyikiza-oauth-
              attenuating-agent-tokens, 2026,
              <https://datatracker.ietf.org/doc/draft-niyikiza-oauth-
              attenuating-agent-tokens/>.

   [X402]     x402 Foundation (Linux Foundation), "x402: An Open
              Standard for HTTP-Native Payments", 2026,
              <https://github.com/x402-foundation/x402>.

   [CONSENTSETTLE]
              Morrison, B., "Consent-Bound Identity Disclosure with
              Subject Settlement for HTTP-Native Agent Payments", Work
              in Progress, Internet-Draft, draft-morrison-consent-
              settlement, 2026, <https://datatracker.ietf.org/doc/draft-
              morrison-consent-settlement/>.

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.

Author's Address

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

Morrison                 Expires 8 January 2027                [Page 14]