[dispatch] New work: APIX — service discovery and trust infrastructure for autonomous agents

[Carsten Rehfeld <[e-mail]>]

Three related Internet-Drafts have been submitted to the independent stream:

   draft-rehfeld-apix-core-01
   https://datatracker.ietf.org/doc/draft-rehfeld-apix-core/

   draft-rehfeld-apix-services-00
   https://datatracker.ietf.org/doc/draft-rehfeld-apix-services/

   draft-rehfeld-apix-iot-00
   https://datatracker.ietf.org/doc/draft-rehfeld-apix-iot/

They supersede draft-rehfeld-bot-service-index-08, which has been
submitted simultaneously as a supersession notice.


## Problem

Autonomous agents and bots that consume external services have no
standardised mechanism to discover available services at scale or to
evaluate service trustworthiness without out-of-band knowledge. An
agent that needs to find, say, a currency conversion API or a
smart-home control interface currently has no protocol-level means to
do so — it relies on hardcoded URLs, operator-specific directories, or
keyword search results that carry no verifiable trust signal.

Existing mechanisms address adjacent but distinct problems:
robots.txt governs crawler access policy, not service discovery;
UDDI defined an enterprise registry that was discontinued; DNS-SD
operates at the local-network layer. None provides a global, trust-graded
index traversable by an autonomous agent from a single entry point.


## Proposal

The API Index (APIX) defines a global discovery infrastructure for
autonomous agents, structured as three layered documents:

draft-rehfeld-apix-core-01 — Core infrastructure
   Defines the APIX Manifest (APM) base format, the organisation and
   service trust model (levels O-0 through O-5 and S-0 through S-4),
   the Index API with HATEOAS navigation, the Spider verification
   framework, and operator governance obligations.

draft-rehfeld-apix-services-00 — Web API and bot service profile
   Extends the APM for web API and bot-consumable service registration.
   Defines notification channel types, GraphQL introspection behaviour,
   capability taxonomy governance, and the accredited verifier programme.

draft-rehfeld-apix-iot-00 — IoT device profile
   Extends the APM for physical connected devices. Defines the two-layer
   discoverability model (public device class, private device instance),
   the presence signal protocol, fleet circuit breaker, and the Law
   Enforcement Request (LER) interface.

All three are informational and submitted on the independent stream.


## Architectural Rationale

Three design choices in this work are likely to attract scrutiny; we
address them here rather than in response to review.

Centralisation. The architecture uses a single globally authoritative
index rather than a federated model. This is intentional. DNS appears
decentralised but relies on a central root; what makes it function is
not federation but a governance model that protects the root from
capture. UDDI failed not because it was centralised but because its
operators had commercial incentives that conflicted with neutral
directory operation — no structural protection against preferential
treatment existed. The APIX governance model (a Swiss Stiftung with
a constitutional prohibition on preferential ranking, operating under
separation from the commercial operator) is the technical answer to
that failure mode. A federated model relocates the problem: federated
registries without a common trust root produce inconsistent trust
metadata. Regional read replicas are planned for Phase 4; the initial
single-operator deployment is a pragmatic starting point, not a
permanent architectural constraint.

Running code. The drafts are submitted as Informational on the
independent stream, where the "running code" bar applies differently
than for Standards Track. A reference implementation is in active
development. More importantly, the problem being specified is not
hypothetical: the origin of this work is a deployed autonomous buying
agent blocked by the absence of exactly this infrastructure —
Cloudflare interception, HTML-only service pages, no machine-readable
capability or trust signals. The draft documents the requirements
before the gap is filled by a proprietary solution under single-entity
control.

Scope. The suite is already decomposed into three documents. apix-core
contains governance and trust model because both are cross-cutting
dependencies of both profiles; separating them would create circular
references or a fourth document containing only shared definitions.
apix-services and apix-iot are independently adoptable: an implementer
can deploy the services profile without the IoT profile. The structure
follows the pattern of RFC 9110-9114: core semantics in one document,
profiles and transport bindings in separate specifications.


## Relation to Adjacent Work

webbotauth (I-D.meunier-webbotauth-registry):
   APIX provides the discovery layer; webbotauth provides the
   authentication layer. An agent uses APIX to find a service, then uses
   webbotauth-compatible credentials to authenticate to it. The two
   specifications are complementary and non-overlapping.

draft-nelson-agent-delegation-receipts:
   DRP addresses the user-to-operator delegation chain (does the user
   authorise the agent to act?). APIX addresses service discovery (what
   services can the agent call, and are they trustworthy?). These operate
   at different points in the same pipeline and do not duplicate each other.

draft-drake-agent-identity-registry:
   Proposes hardware-anchored identity for autonomous entities. Hardware
   attestation of this kind is a plausible evidence type for the higher
   APIX organisation trust levels (O-4/O-5), making the two specifications
   potentially complementary.

WIMSE WG:
   WIMSE addresses workload-to-workload identity in multi-service
   environments. APIX does not define workload identity; it defines service
   registration trustworthiness and index traversal. Non-overlapping.


## Requested Action

We seek dispatch guidance on an appropriate WG home or BOF path for
this work. Candidate homes we have considered:

   webbotauth — strong thematic alignment (bots, automated clients,
     HTTP-based service access); charter is currently scoped to
     authentication only and would need expansion.

   httpapi — APIX Index API is an HTTP API; however, the scope of APIX
     extends well beyond HTTP conventions into trust policy and governance.

   New BOF — given the breadth (trust model, discovery, IoT, governance),
     a focused BOF to assess community interest may be the cleanest path.

The authors are open to guidance from the chairs and area directors.

Carsten Rehfeld
[e-mail]