Agent Registry (AREG)
draft-schemacommons-areg-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Observalytics SL | ||
| Last updated | 2026-08-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-schemacommons-areg-00
Network Working Group B. van Bussel
Internet-Draft Observalytics SL
Intended status: Informational 2 August 2026
Expires: 3 February 2027
Agent Registry (AREG)
draft-schemacommons-areg-00
Abstract
The Agent Registry (AREG) is an open, vendor-neutral specification
for publishing, discovering, and resolving artificial intelligence
(AI) agent definitions. An AREG registry entry is a lightweight
metadata document that records where a specific version of an agent
definition can be fetched, who published it, what version it is, and
how consumers can verify its authenticity. AREG also defines a REST
API that conforming registry servers implement to expose search,
resolution, and publication endpoints to consumers and publishers.
AREG is the discovery and registry layer of the Schema Commons agent
stack. It is designed to compose with the Autonomous Agent
Interchange Format (AAIF, SC-006), which defines the content of the
agent definition document that an AREG entry points to, and with the
Agent Capability and Profile Model (ACPM, SC-014), which provides
richer capability, trust, cost, and service-level information that a
registry entry can reference. Neither AAIF nor ACPM is required for
a conforming AREG implementation.
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."
This Internet-Draft will expire on 3 February 2027.
van Bussel Expires 3 February 2027 [Page 1]
Internet-Draft AREG August 2026
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5
4. Registry Entry Format . . . . . . . . . . . . . . . . . . . . 5
4.1. Object Model . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Field Definitions . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Root Fields . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. Publisher Object . . . . . . . . . . . . . . . . . . 7
4.2.3. Resolution Fields . . . . . . . . . . . . . . . . . . 7
4.2.4. Discovery Metadata . . . . . . . . . . . . . . . . . 7
4.2.5. Lifecycle Fields . . . . . . . . . . . . . . . . . . 8
5. REST API . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. GET /v1/entries . . . . . . . . . . . . . . . . . . . . . 8
5.3. GET /v1/entries/{registry_id} . . . . . . . . . . . . . . 9
5.4. GET /v1/resolve/{agent_id} . . . . . . . . . . . . . . . 9
5.5. GET /v1/resolve/{agent_id}/{version} . . . . . . . . . . 9
5.6. POST /v1/entries . . . . . . . . . . . . . . . . . . . . 10
5.7. PATCH /v1/entries/{registry_id} . . . . . . . . . . . . . 10
5.8. DELETE /v1/entries/{registry_id} . . . . . . . . . . . . 10
6. Signing Model . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Signing (Publisher) . . . . . . . . . . . . . . . . . . . 11
6.2. Verification (Consumer) . . . . . . . . . . . . . . . . . 11
6.3. Normative Constraints . . . . . . . . . . . . . . . . . . 12
7. Versioning and Yanking . . . . . . . . . . . . . . . . . . . 12
7.1. Versioning . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Yanking . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Relationship to AAIF and ACPM . . . . . . . . . . . . . . . . 13
9. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10.1. Unsigned Entries . . . . . . . . . . . . . . . . . . . . 14
10.2. Publisher Impersonation . . . . . . . . . . . . . . . . 14
10.3. URL Redirection and Document Mutation . . . . . . . . . 15
van Bussel Expires 3 February 2027 [Page 2]
Internet-Draft AREG August 2026
10.4. Key Revocation . . . . . . . . . . . . . . . . . . . . . 15
10.5. Yanked Entry Misuse . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
A portable AI agent definition is only as useful as the
infrastructure that lets others find it. Today, agents are shared by
hard-coded URLs, proprietary marketplace databases, or not at all.
There is no standard vocabulary for expressing that a specific
version of an agent has been published, who is responsible for it,
whether it has been retracted, or how to verify that the definition a
consumer fetches is the same one the publisher intended to
distribute.
This document specifies the Agent Registry (AREG): a registry entry
document format and a REST API for registry servers. Together they
provide a common, interoperable foundation for agent discovery across
registries, orchestration platforms, and toolchains, without
requiring a central registry authority.
AREG is the third member of the Schema Commons agent stack. The
Autonomous Agent Interchange Format (AAIF) [SC-006] defines how to
express a portable agent definition that any conforming runtime can
execute. The Agent Capability and Profile Model (ACPM) [SC-014]
defines how to describe what an agent, platform, tool, or model
offers in terms of capabilities, trust, cost, and service level.
AREG defines where to find a published agent and how to establish
that the definition at a given URL has not been tampered with.
1.1. Requirements Language
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.
van Bussel Expires 3 February 2027 [Page 3]
Internet-Draft AREG August 2026
1.2. Scope
AREG is in scope for: the registry entry document format; the REST
API that registry servers implement; the signing model used to verify
that a fetched agent definition has not been modified since
publication; versioning semantics for entries; and yanking (soft
retraction) semantics.
AREG is out of scope for: the content of the agent definition
document at the entry's resolution URL (that is defined by AAIF
[SC-006]); capability, trust, cost, and service-level description of
the agent or registry server (that is defined by ACPM [SC-014]);
transport security configuration; billing and rate limiting above and
beyond what this specification mandates.
2. Terminology
Registry entry A JSON instance conforming to the AREG registry entry
schema. Describes one published version of one agent.
Registry A server that stores registry entries and exposes them via
the AREG REST API defined in Section 5.
Publisher The party that submits a registry entry to a registry.
Consumer Software that queries a registry to discover, resolve, or
verify agents.
Agent ID The stable UUID identifying one logical agent across all of
its published versions. Carried in both the AAIF document and the
registry entry.
Registry ID A UUID assigned by the registry to uniquely identify one
specific (agent_id, agent_version) entry. Stable for the lifetime
of that entry.
Yanked An entry that has been retracted by its publisher. The entry
remains in the registry with yanked set to true but MUST NOT be
used for new deployments.
Canonical JSON The deterministic byte representation produced by
applying RFC 8785 (JSON Canonicalization Scheme) [RFC8785] to a
JSON value.
Conformance level One of the four cumulative levels in Section 9
that a registry implementation claims.
van Bussel Expires 3 February 2027 [Page 4]
Internet-Draft AREG August 2026
3. Design Principles
1. *Entry, not copy.* A registry entry is a pointer and metadata
record. The authoritative agent definition lives at aaif_url.
The registry does not re-host agent definitions.
2. *Immutable versions.* Once a (agent_id, agent_version) entry is
published, aaif_url, signature, and published_at MUST NOT change.
Corrections require a new version. This makes entries auditable
and cacheable.
3. *Soft deletes only.* Yanking sets yanked to true but preserves
the entry. Consumers can audit what was retracted and why; the
record of a version's existence is never erased.
4. *Signature is optional but fully specified.* Not every publisher
will sign. AREG defines the signing model precisely enough that
a consumer can verify a signature when one is present, without
requiring one.
5. *Public reads, gated writes.* Discovery is a public good. All
GET endpoints MUST be accessible without authentication.
Mutating endpoints MUST require authentication.
6. *Decentralized by design.* AREG defines no central registry
authority. Any party can operate a conforming registry.
Consumers may query multiple registries and merge results.
4. Registry Entry Format
4.1. Object Model
A registry entry is a flat JSON object. The following diagram shows
its top-level structure (informative):
van Bussel Expires 3 February 2027 [Page 5]
Internet-Draft AREG August 2026
RegistryEntry (root)
sc_standard "SC-013" (required)
sc_version semver (required)
registry_id UUID — assigned by registry
agent_id UUID — from AAIF document (required)
agent_version semver — from AAIF document (required)
published_at date-time — set by registry on POST
updated_at date-time — set by registry on PATCH
publisher
name string (required)
url URI (required)
public_key_url URI — JWK Set or PEM endpoint
contact string — abuse/security contact
aaif_url URI (required)
signature compact JWS | null
tags[] string[]
conformance_level enum
required_capabilities[] string[]
acpm_profile_url URI | null
yanked boolean (default false)
yank_reason string | null
license string (SPDX ID)
4.2. Field Definitions
4.2.1. Root Fields
sc_standard REQUIRED. The literal string "SC-013". Identifies this
document as an AREG registry entry.
sc_version REQUIRED. The AREG schema version in Semantic Versioning
format. Current value: "0.1.0".
registry_id REQUIRED. A UUID (RFC 9562 [RFC9562]) assigned by the
registry at publish time. MUST NOT change after assignment.
agent_id REQUIRED. The agent_id UUID from the AAIF document at
aaif_url. MUST match the agent_id field in that document.
agent_version REQUIRED. The version of the agent definition in
Semantic Versioning format. MUST match the version field in the
AAIF document at aaif_url.
published_at REQUIRED. ISO 8601 UTC date-time of first publication.
Set by the registry on POST. Publishers MUST NOT supply this
field.
updated_at OPTIONAL. ISO 8601 UTC date-time of the most recent
van Bussel Expires 3 February 2027 [Page 6]
Internet-Draft AREG August 2026
metadata update. Set by the registry on PATCH.
4.2.2. Publisher Object
publisher.name REQUIRED. Human-readable publisher name.
publisher.url REQUIRED. Publisher's canonical URI.
publisher.public_key_url REQUIRED when signature is non-null. URI
resolving to a JWK Set (RFC 7517 [RFC7517]) with Content-Type
application/json, or a PEM file with Content-Type text/plain,
containing the public key(s) used to produce the signature value.
publisher.contact OPTIONAL. Contact email or URI for abuse and
security reports.
4.2.3. Resolution Fields
aaif_url REQUIRED. A resolvable URI at which the full AAIF agent
definition document can be fetched. MUST return a document whose
agent_id and agent_version match the entry.
signature OPTIONAL. Compact JWS serialization (RFC 7515 [RFC7515])
of a detached signature over the canonical JSON (RFC 8785
[RFC8785]) of the AAIF document at aaif_url. Null for unsigned
entries. See Section 6.
4.2.4. Discovery Metadata
tags OPTIONAL. Array of free-form topic strings. Lowercase
hyphenated strings are RECOMMENDED. Used as an OR-filter in list
queries.
conformance_level OPTIONAL. The highest AAIF conformance level the
agent claims, copied from the AAIF document. Allowed values:
Core, Tooled, Portable, Multi-agent, Observable, Enterprise,
Stateful.
required_capabilities OPTIONAL. Copy of required_capabilities from
the AAIF document. Allows capability-based filtering without
fetching the full definition.
acpm_profile_url OPTIONAL. URI of an ACPM (SC-014) [SC-014]
capability profile that further describes what this agent offers.
Null if none published.
van Bussel Expires 3 February 2027 [Page 7]
Internet-Draft AREG August 2026
4.2.5. Lifecycle Fields
yanked OPTIONAL. If true, this version has been retracted.
Consumers MUST NOT use yanked entries for new deployments.
Default: false.
yank_reason OPTIONAL. Human-readable reason for yanking. REQUIRED
when yanked is true.
license OPTIONAL. SPDX license identifier for the agent definition
document itself.
5. REST API
5.1. Conventions
A registry server MUST expose the endpoints defined in this section
under a stable base URL, referred to in this document as {server}.
All paths below are relative to {server}/v1.
All request and response bodies are JSON (RFC 8259 [RFC8259]).
Requests that include a body MUST send Content-Type: application/
areg+json. Responses MUST carry Content-Type: application/areg+json.
All GET endpoints MUST be accessible without authentication. POST,
PATCH, and DELETE endpoints MUST require authentication. The
authentication mechanism (Bearer token, API key, OAuth 2.0) is
registry-defined. A registry MUST document its authentication
requirement.
All error responses use the following format:
{ "error": "short_code", "detail": "human-readable text" }
All registry endpoints MUST be served over HTTPS (TLS 1.2 or higher).
Plain HTTP MUST NOT be used.
5.2. GET /v1/entries
Returns a paginated list of registry entries. Yanked entries are
excluded unless include_yanked=true is supplied.
Query parameters:
tag (repeatable) Include entries carrying any of the supplied tags
(OR logic).
capability (repeatable) Include only entries whose
van Bussel Expires 3 February 2027 [Page 8]
Internet-Draft AREG August 2026
required_capabilities array contains all supplied values (AND
logic).
conformance_level Exact match against the conformance_level field.
publisher_url Exact match against publisher.url.
include_yanked If true, include yanked entries. Default: false.
page 1-based page number. Default: 1.
per_page Results per page. Default: 20. Maximum: 100.
Response 200:
{
"entries": [ /* array of registry entry objects */ ],
"total": 42,
"page": 1,
"per_page": 20
}
5.3. GET /v1/entries/{registry_id}
Returns a single registry entry identified by registry_id.
Response 200: the registry entry object.
Response 404: entry not found.
5.4. GET /v1/resolve/{agent_id}
Returns the latest non-yanked registry entry for the given agent_id,
where "latest" is determined by Semantic Version ordering of
agent_version (descending).
Response 200: the registry entry object.
Response 404: no non-yanked entry exists for this agent_id.
5.5. GET /v1/resolve/{agent_id}/{version}
Returns the registry entry for the specific (agent_id, agent_version)
pair.
Response 200: the registry entry object.
Response 404: no entry exists for this pair.
van Bussel Expires 3 February 2027 [Page 9]
Internet-Draft AREG August 2026
Response 410 Gone: the entry exists but is yanked. The response body
MUST include the yank_reason.
5.6. POST /v1/entries
Publishes a new registry entry. The publisher MUST supply all
required fields except registry_id, published_at, and updated_at,
which the registry assigns.
The registry MUST validate the submitted body against the registry
entry schema [JSON-SCHEMA] before accepting it. The registry SHOULD
verify that agent_id and agent_version in the body match the AAIF
document at aaif_url at publish time. If they do not match, the
registry MUST reject the request with 422.
Response 201: { "registry_id": "...", "published_at": "..." }
Response 400: schema validation failure.
Response 409: a non-yanked entry for this (agent_id, agent_version)
already exists.
Response 422: agent_id or agent_version mismatch with the AAIF
document at aaif_url.
5.7. PATCH /v1/entries/{registry_id}
Updates mutable metadata on a non-yanked entry. The following fields
MAY be updated: tags, acpm_profile_url, publisher.contact. The
following fields MUST NOT be changed via PATCH: agent_id,
agent_version, aaif_url, signature, publisher.name, publisher.url,
published_at. The registry MUST reject a PATCH that attempts to
modify an immutable field with 422.
Response 200: the updated registry entry object.
Response 403: requester does not own this entry.
Response 404: entry not found.
Response 409: entry is yanked.
Response 422: attempt to modify an immutable field.
5.8. DELETE /v1/entries/{registry_id}
Marks an entry as yanked. The entry is not removed. The yanked flag
is set to true and the yank_reason is recorded.
van Bussel Expires 3 February 2027 [Page 10]
Internet-Draft AREG August 2026
The request body MUST include: { "yank_reason": "string" }.
Response 200: the updated registry entry object with yanked set to
true.
Response 403: requester does not own this entry.
Response 404: entry not found.
Response 409: entry is already yanked.
6. Signing Model
The signature field attests that the AAIF document at aaif_url has
not been modified since the publisher signed it. A registry entry
without a signature provides no cryptographic assurance of document
integrity.
6.1. Signing (Publisher)
To produce a valid signature, a publisher:
1. Fetches the AAIF document from aaif_url.
2. Produces the canonical JSON representation of the document using
RFC 8785 (JSON Canonicalization Scheme) [RFC8785].
3. Produces a JWS (RFC 7515 [RFC7515]) using detached payload mode:
the canonical JSON bytes are the payload but are not included in
the JWS serialization. The compact serialization form is used.
4. Uses the algorithm ES256 (ECDSA with P-256 and SHA-256, RFC 7518
[RFC7518]). RS256 (RSASSA-PKCS1 with SHA-256) SHOULD also be
supported by registry implementations for interoperability.
5. Sets the signature field in the registry entry to the compact JWS
string.
6. Publishes the corresponding public key at
publisher.public_key_url as a JWK Set (RFC 7517 [RFC7517]) with
Content-Type application/json, or a PEM file with Content-Type
text/plain.
6.2. Verification (Consumer)
To verify a signature, a consumer:
van Bussel Expires 3 February 2027 [Page 11]
Internet-Draft AREG August 2026
1. Retrieves the registry entry. If signature is null, the entry is
unsigned; the consumer applies its own policy for unsigned
entries.
2. Fetches the AAIF document from aaif_url.
3. Produces canonical JSON of the fetched document using RFC 8785
[RFC8785].
4. Fetches the JWK Set or PEM from publisher.public_key_url.
5. Verifies the compact JWS against the canonical JSON bytes using
the public key.
6. If verification fails, treats the AAIF document as untrusted
regardless of other metadata in the entry.
6.3. Normative Constraints
A registry MUST NOT modify aaif_url or signature after an entry is
published.
A consumer that requires signed entries MUST reject entries where
signature is null.
A consumer MUST NOT cache the public key indefinitely. It SHOULD re-
fetch from publisher.public_key_url at an interval appropriate to its
security policy.
7. Versioning and Yanking
7.1. Versioning
A registry entry identifies exactly one (agent_id, agent_version)
pair. When an agent definition is updated, a new entry MUST be
published with the new agent_version value. The new entry receives a
new registry_id. The previous entry remains in the registry
unchanged.
The GET /v1/resolve/{agent_id} endpoint returns the latest non-yanked
entry, where "latest" is determined by Semantic Version ordering of
agent_version descending.
van Bussel Expires 3 February 2027 [Page 12]
Internet-Draft AREG August 2026
7.2. Yanking
Yanking retracts a specific (agent_id, agent_version) entry. Yanking
is REQUIRED when a security vulnerability is found in the agent
definition, when the document at aaif_url has been changed in a way
that invalidates the entry, or when the publisher otherwise withdraws
the version.
Yanking MUST NOT be reversed by setting yanked back to false. If a
version was inadvertently yanked, the publisher SHOULD re-publish it
under a new agent_version with a corrective note.
A registry MUST preserve yanked entries. Consumers who hold a
reference to a specific registry_id MUST be able to retrieve it,
including its yank_reason, for audit purposes.
Consumers that cache registry entries locally MUST periodically re-
check the live entry to detect yanking.
8. Relationship to AAIF and ACPM
AREG is designed to compose with SC-006 (AAIF) and SC-014 (ACPM) but
has no hard dependency on either.
SC-006 AAIF [SC-006] defines the content of the agent definition
document that aaif_url resolves to. A registry entry carries
agent_id and required_capabilities from the AAIF document to enable
search without fetching every definition. Using AREG without AAIF is
possible; a registry entry's aaif_url may point to any agent
definition format the publisher chooses.
SC-014 ACPM [SC-014] provides a richer capability profile that
acpm_profile_url optionally points to. ACPM profiles give consumers
capability, trust, cost, and SLA information beyond the minimal
conformance_level and required_capabilities in the registry entry.
Neither AREG nor ACPM requires the other.
The A2A Protocol [A2A] defines Agent Cards that an agent server
exposes at a well-known URL to advertise its runtime capabilities.
Agent Cards are designed for runtime service discovery, while AREG
registry entries are designed for catalog discovery prior to
connection. The two are complementary: an AREG entry may carry the
aaif_url of an AAIF document that in turn references an A2A Agent
Card endpoint.
The Model Context Protocol roadmap [MCP-ROADMAP] describes a planned
Server Cards effort for MCP server discovery via well-known URLs. An
AREG registry entry for an MCP-based agent may carry an
van Bussel Expires 3 February 2027 [Page 13]
Internet-Draft AREG August 2026
acpm_profile_url pointing to an ACPM profile that captures the
server's MCP capabilities, enabling the two discovery mechanisms to
coexist.
9. Conformance
Conformance levels apply to software that implements an AREG registry
server. Levels are cumulative: a server claiming Full satisfies
every requirement of Discover through Signed. Conformance is self-
certified; there is no central certifying authority.
Discover Implements GET /v1/entries, GET /v1/entries/{id}, GET /v1/
resolve/{agent_id}, and GET /v1/resolve/{agent_id}/{version}.
Validates entries against the registry entry schema. Returns the
correct Content-Type. All endpoints accessible without
authentication.
Publish Discover, plus POST /v1/entries, PATCH /v1/entries/{id}, and
DELETE /v1/entries/{id}. Enforces authentication on mutating
endpoints. Assigns registry_id and published_at server-side.
Signed Publish, plus verifies signature on POST when signature is
non-null. Rejects entries whose signature does not verify against
the key at publisher.public_key_url.
Full Signed, plus supports all query parameters for GET /v1/entries
(tag, capability, conformance_level, publisher_url,
include_yanked, page, per_page) and returns correct pagination
metadata (total, page, per_page).
10. Security Considerations
10.1. Unsigned Entries
A registry entry without a signature provides no cryptographic
assurance that the AAIF document at aaif_url is authentic or
unmodified. Consumers operating in high-trust environments MUST
require signature to be non-null and successfully verified before
deploying or executing an agent based on the entry. Unsigned entries
are appropriate for development and low-trust contexts.
10.2. Publisher Impersonation
AREG does not define a mechanism for verifying the identity of a
publisher beyond what the registry's own authentication provides. A
compromised publisher account can publish malicious entries.
Registries SHOULD implement rate limiting, review workflows, and
abuse reporting to reduce this risk.
van Bussel Expires 3 February 2027 [Page 14]
Internet-Draft AREG August 2026
10.3. URL Redirection and Document Mutation
A publisher who controls the server at aaif_url can silently
substitute a different document after the entry is published. The
signature field mitigates this: a consumer who verifies the signature
detects any change to the canonical JSON. Registries that do not
require signatures SHOULD document this risk prominently.
10.4. Key Revocation
AREG does not define a key revocation mechanism beyond the publisher
updating the JWK Set at publisher.public_key_url. A consumer that
caches public keys indefinitely is vulnerable to continued reliance
on a compromised key. Consumers MUST re-fetch keys at an appropriate
interval and MUST NOT trust a signature verified against a key that
has been removed from the publisher's JWK Set.
10.5. Yanked Entry Misuse
A consumer that caches registry entries locally MUST periodically re-
check the live entry to detect yanking. Using a yanked entry for a
new deployment after the yanked flag is set is a misuse of the
registry. Consumers SHOULD treat a 410 Gone response from GET /v1/
resolve/{agent_id}/{version} as an immediate signal to halt any
pending deployment of that version.
11. IANA Considerations
This document requests registration of the following media type.
Type name
application
Subtype name
areg+json
Required parameters
None
Optional parameters
None
Encoding considerations
Binary (UTF-8 encoded JSON)
Security considerations
See Section 10 of this document.
van Bussel Expires 3 February 2027 [Page 15]
Internet-Draft AREG August 2026
Interoperability considerations
Instances MUST validate against the AREG registry entry schema
version 0.1.0 or later.
Published specification
This document.
Applications that use this media type
AREG registry clients and servers.
Additional information
File extension: .areg.json. Magic number: none.
Intended usage
COMMON
Restrictions on usage
None
Author
Bob van Bussel, bob@observalytics.com
Change controller
Schema Commons (schemacommons.org)
12. References
12.1. 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/rfc/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/rfc/rfc8174>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
van Bussel Expires 3 February 2027 [Page 16]
Internet-Draft AREG August 2026
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>.
[RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/rfc/rfc9562>.
[JSON-SCHEMA]
Wright, A. and H. Andrews, "JSON Schema: A Media Type for
Describing JSON Documents", 2022,
<https://json-schema.org/draft/2020-12>.
12.2. Informative References
[SC-006] Schema Commons, "Autonomous Agent Interchange Format
(AAIF)", 2026,
<https://github.com/Observalytics-SL/aaif/>.
[SC-014] Schema Commons, "Agent Capability and Profile Model
(ACPM)", 2026,
<https://github.com/Observalytics-SL/acpm/>.
[A2A] Linux Foundation (Agent2Agent Project), "Agent2Agent
Protocol", 2025, <https://github.com/a2aproject/A2A>.
[MCP-ROADMAP]
Model Context Protocol contributors, "Model Context
Protocol Development Roadmap", 5 March 2026.
Author's Address
Bob van Bussel
Observalytics SL
Email: bob@observalytics.com
URI: https://schemacommons.org
van Bussel Expires 3 February 2027 [Page 17]