AgIS: An Agent Identity System for DNS-Backed Verification of AI and Software Agents
draft-ayoub-agis-agent-identity-system-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 | Rizkallah Ayoub | ||
| Last updated | 2026-06-29 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Related Implementations Related Implementations |
||
| 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-ayoub-agis-agent-identity-system-00
Internet Engineering Task Force R. Ayoub
Internet-Draft EPICORTEK Technologies Inc.
Intended status: Informational 29 June 2026
Expires: 31 December 2026
AgIS: An Agent Identity System for DNS-Backed Verification of AI and
Software Agents
draft-ayoub-agis-agent-identity-system-00
Abstract
This document specifies AgIS, the Agent Identity System, a DNS-backed
identity and verification profile for AI agents, autonomous software
agents, and agentic services operating on the existing web.
AgIS defines an agent identifier form, DNS TXT bindings, Agent Cards,
key thumbprints, status and revocation documents, signed HTTP request
verification, replay protection, delegation tokens, and delegation
chains. The design intentionally reuses existing Internet
mechanisms, including DNS, HTTPS well-known resources, JSON Web Keys,
JSON canonicalization, HTTP Message Signatures, and HTTP digest
fields.
This document describes the AgIS 0.2.2 wire/profile format and the
behavior exercised by the AgIS v0.3.0-alpha.3 reference
implementation and its 23 deterministic test vectors. That
implementation includes signed Agent Cards, HTTP Message Signature
verification, two-phase replay protection, delegation signer-key
binding enforced by default, and signed agent status document
support. It does not define a global trust authority, a production
trust network, or a new public-key infrastructure.
This is an individual Internet-Draft and a work in progress. It has
not been approved by the IETF, does not represent an IETF standard or
RFC, and has not been adopted by any IETF working group.
AgIS is designed to be compatible with agent naming services such as
Linux Foundation ANS and similar systems. AgIS is not affiliated
with, endorsed by, or a replacement for Linux Foundation ANS or any
global naming authority. AgIS defines verification, governance, and
request-signing behavior that operates over identity evidence that
may originate from ANS or any comparable naming layer.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Ayoub Expires 31 December 2026 [Page 1]
Internet-Draft AgIS Agent Identity June 2026
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 31 December 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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Agent Identifier . . . . . . . . . . . . . . . . . . . . . . 7
6. HTTPS Equivalent Identifier . . . . . . . . . . . . . . . . . 7
7. Agent Card Location . . . . . . . . . . . . . . . . . . . . . 7
8. DNS TXT Binding . . . . . . . . . . . . . . . . . . . . . . . 8
9. Agent Card . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Agent Card Canonicalization and Hashing . . . . . . . . . . . 11
11. Agent Keys and JWK Thumbprints . . . . . . . . . . . . . . . 11
12. Signed Agent Cards . . . . . . . . . . . . . . . . . . . . . 12
13. Agent Status . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Signed Status Documents . . . . . . . . . . . . . . . . 14
14. Offline Identity Verification . . . . . . . . . . . . . . . . 14
15. HTTP Request Signing Profile . . . . . . . . . . . . . . . . 15
16. High-Assurance Requests, Freshness, and Replay Protection . . 16
17. Delegation Tokens . . . . . . . . . . . . . . . . . . . . . . 17
18. Delegated Signed Requests . . . . . . . . . . . . . . . . . . 18
19. Delegation Chains . . . . . . . . . . . . . . . . . . . . . . 19
Ayoub Expires 31 December 2026 [Page 2]
Internet-Draft AgIS Agent Identity June 2026
20. Trust Levels . . . . . . . . . . . . . . . . . . . . . . . . 21
21. Error Model . . . . . . . . . . . . . . . . . . . . . . . . . 21
22. Deterministic Test Vectors . . . . . . . . . . . . . . . . . 22
23. Security Considerations . . . . . . . . . . . . . . . . . . . 24
23.1. DNS Control and Domain Compromise . . . . . . . . . . . 24
23.2. HTTPS Publication Security . . . . . . . . . . . . . . . 24
23.3. Canonicalization Attacks . . . . . . . . . . . . . . . . 25
23.4. Key Compromise . . . . . . . . . . . . . . . . . . . . . 25
23.5. Revocation Caching . . . . . . . . . . . . . . . . . . . 25
23.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 25
23.7. Clock Skew . . . . . . . . . . . . . . . . . . . . . . . 25
23.8. Signature Confusion . . . . . . . . . . . . . . . . . . 25
23.9. Delegation Confusion and Signer-Key Binding . . . . . . 26
23.10. Status Document Integrity . . . . . . . . . . . . . . . 26
23.11. Test Keys . . . . . . . . . . . . . . . . . . . . . . . 27
23.12. Local Authorization . . . . . . . . . . . . . . . . . . 27
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
26. Implementation Status . . . . . . . . . . . . . . . . . . . . 28
27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
28. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
28.1. Normative References . . . . . . . . . . . . . . . . . . 30
28.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Example Agent Identifier . . . . . . . . . . . . . . 31
Appendix B. Example DNS TXT Binding . . . . . . . . . . . . . . 31
Appendix C. Example Agent Card Hash . . . . . . . . . . . . . . 31
Appendix D. Example JWK Thumbprint . . . . . . . . . . . . . . . 31
Appendix E. Example Content-Digest . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
Software agents are increasingly used to perform actions across
organizational, application, and network boundaries. These agents
may call APIs, retrieve data, initiate workflows, delegate tasks, and
act on behalf of organizations, users, or other agents.
Existing web identity mechanisms are generally designed for human
users, applications, domains, or service accounts. They do not
provide a compact, DNS-backed, agent-specific verification profile
that allows a verifier to answer the following questions in a
deterministic manner:
* What agent is making this request?
* Which domain is responsible for publishing that agent's identity
information?
Ayoub Expires 31 December 2026 [Page 3]
Internet-Draft AgIS Agent Identity June 2026
* Which Agent Card describes the agent?
* Which public key is bound to that agent?
* Has the Agent Card been tampered with?
* Is the agent active, suspended, revoked, deprecated, or
compromised?
* Was this HTTP request signed by the expected agent key?
* Is the request fresh, or is it a replay?
* Is the acting agent using a valid delegation from another agent?
* Has a delegation chain attempted to escalate scope?
AgIS addresses these questions by defining a narrow identity and
verification profile that can be deployed using ordinary DNS records
and HTTPS resources. It is intended to be small enough for developer
tooling and deterministic enough for independent test-vector
validation.
AgIS is not an authorization framework by itself. A verifier MAY use
AgIS verification results as input to a local authorization policy,
but final authorization decisions remain local to the relying party.
This document is an individual Internet-Draft submitted for community
review. It is a work in progress, has not been approved by the IETF,
does not represent an IETF standard, and has not been adopted by any
IETF working group. The reference implementation is experimental
alpha software.
AgIS is not a global naming service. Agent naming, discovery, and
identity evidence MAY be provided by external naming systems such as
Linux Foundation ANS or similar agent name services. AgIS defines
the verification, governance, signed request, delegation, and replay
protection behavior that operates over such identity evidence once it
is available to a verifier. AgIS is not affiliated with, endorsed
by, or a replacement for any such naming authority.
AgIS is also not a claim that an agent is safe, truthful, lawful,
beneficial, or aligned. It verifies identity bindings, key material,
request signatures, freshness signals, revocation status, and
delegation constraints. It does not certify the behavior or intent
of the agent.
Ayoub Expires 31 December 2026 [Page 4]
Internet-Draft AgIS Agent Identity June 2026
2. Goals
AgIS has the following design goals:
1. Reuse existing web infrastructure.
2. Make agent identity independently verifiable.
3. Bind an agent identifier to a domain-controlled publication
point.
4. Support deterministic offline verification.
5. Support signed HTTP requests using an existing HTTP signature
framework.
6. Support revocation and status checks.
7. Support scoped delegation and delegation chains.
8. Avoid requiring a global AgIS root authority.
9. Avoid requiring blockchain, new DNS infrastructure, or new
transport protocols.
10. Provide deterministic test vectors for independent
implementations.
3. Non-Goals
This version of AgIS does not define:
* a global trust registry;
* a certificate authority;
* a legal identity framework;
* a reputation system;
* a payment system;
* a production authorization policy language;
* a live DNS and HTTPS resolver profile;
* a mandatory hosted verification service;
Ayoub Expires 31 December 2026 [Page 5]
Internet-Draft AgIS Agent Identity June 2026
* a registry for the agent URI scheme;
* an IANA registry for AgIS parameters.
Future documents may define live resolver behavior, additional
transport bindings, registries, discovery mechanisms, or production
policy profiles.
4. 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.
Agent: A software actor that can make requests, receive requests, or
perform tasks using an identity described by this specification.
Agent Identifier: A URI-like identifier beginning with agent:// that
names an agent under a domain.
Agent Card: A JSON document describing an agent, its identifier,
owner metadata, capabilities, endpoints, public keys, cache
information, and status.
Agent Card Hash: A SHA-256 digest of the JSON Canonicalization
Scheme representation of the Agent Card, excluding the signature
member.
DNS Binding: A DNS TXT record under the agent publisher's domain
that binds an Agent Identifier to an Agent Card URL, and
optionally to a JWK thumbprint and Agent Card hash.
Verifier: A party that evaluates AgIS identity material, request
signatures, freshness, status, or delegation information.
Issuer: An agent that issues a delegation token.
Subject: An agent to which a delegation token is issued.
Acting Agent: The agent identified by the AgIS-Agent HTTP field in a
signed request.
Delegation Chain: An ordered list of delegation tokens in which each
token delegates from one agent to the next.
Ayoub Expires 31 December 2026 [Page 6]
Internet-Draft AgIS Agent Identity June 2026
5. Agent Identifier
An AgIS Agent Identifier has the following form:
agent://{domain}/{agent-name}
For example:
agent://example.com/support-agent
The domain component identifies the DNS domain responsible for
publishing the agent binding. The agent-name component identifies
the agent under that domain.
The following ABNF defines the v0.2.2 Agent Identifier profile:
agent-id = "agent://" domain "/" agent-name
domain = 1*(ALPHA / DIGIT / "-" / ".")
agent-name = 1*(ALPHA / DIGIT / "-" / "_" / ".")
Implementations MUST compare the scheme component case-insensitively.
Implementations MUST compare the domain component using the normal
DNS case-insensitive comparison rules. Implementations MUST compare
the agent-name component byte-for-byte after URI parsing.
An Agent Identifier MUST NOT contain a query component. An Agent
Identifier MUST NOT contain a fragment component. An Agent
Identifier MUST NOT contain userinfo.
This document does not request registration of the agent URI scheme
at this time.
6. HTTPS Equivalent Identifier
An Agent Identifier maps to a default HTTPS publication location:
https://{domain}/.well-known/agis/id/{agent-name}
This HTTPS equivalent identifier is intended for human inspection,
linking, debugging, and future resolver behavior. The v0.2.2 profile
does not require live fetching of this location for offline
verification.
7. Agent Card Location
The default Agent Card location is:
https://{domain}/.well-known/agis/agents/{agent-name}.json
Ayoub Expires 31 December 2026 [Page 7]
Internet-Draft AgIS Agent Identity June 2026
A DNS Binding MAY specify a different Agent Card URL using the card
parameter. If the card parameter is present, verifiers MUST use that
value for the binding under evaluation.
Agent Card URLs MUST use HTTPS. Verifiers MUST reject non-HTTPS
Agent Card URLs except in explicitly configured local development
environments.
8. DNS TXT Binding
The default DNS TXT owner name for an agent is:
_agis.{agent-name}.{domain}
For the Agent Identifier:
agent://example.com/support-agent
the default DNS TXT owner name is:
_agis.support-agent.example.com
A minimal DNS TXT binding has the following form:
agis=0.2.2; agent=agent://example.com/support-agent; card=https://example.com/.well-known/agis/agents/support-agent.json
A recommended DNS TXT binding additionally includes a JWK thumbprint
and Agent Card hash:
agis=0.2.2; agent=agent://example.com/support-agent; card=https://example.com/.well-known/agis/agents/support-agent.json; jkt=dXBQ4ZkgA3nTvwrFeLAKYokanVfetC0fzXUiSFkYg08; card_sha256=842dbbbf1c807d020ceafe7fd8b51502cf7ae94314238e293a36c736463a3122
The following parameters are defined:
agis: The AgIS profile version. For this document the value is
0.2.2.
agent: The Agent Identifier.
card: The HTTPS URL of the Agent Card.
jkt: The JWK thumbprint of the signing key, encoded using base64url
without padding.
card_sha256: The lowercase hexadecimal SHA-256 digest of the
canonical Agent Card, excluding the signature member.
Ayoub Expires 31 December 2026 [Page 8]
Internet-Draft AgIS Agent Identity June 2026
A verifier MUST reject a DNS Binding if the agis, agent, or card
parameter is missing. A verifier SHOULD reject a DNS Binding if jkt
or card_sha256 is present but does not match the Agent Card under
evaluation.
The order of DNS Binding parameters is not significant. Parameter
names are case-sensitive. Parameter values MUST NOT be interpreted
as shell expressions, templates, or executable content.
9. Agent Card
An Agent Card is a JSON document describing an agent. The v0.2.2
profile defines the following required members:
Ayoub Expires 31 December 2026 [Page 9]
Internet-Draft AgIS Agent Identity June 2026
{
"agis_version": "0.2.2",
"agent_id": "agent://example.com/support-agent",
"name": "support-agent",
"owner": {
"name": "Example Organization",
"domain": "example.com"
},
"status": "active",
"issued_at": "2026-06-23T00:00:00Z",
"updated_at": "2026-06-23T00:00:00Z",
"capabilities": [
"signed_requests",
"agent_identity"
],
"endpoints": {
"jwks": "https://example.com/.well-known/agis/agents/support-agent/jwks.json",
"status": "https://example.com/.well-known/agis/agents/support-agent/status.json"
},
"public_keys": [
{
"id": "key-2026-01",
"type": "OKP",
"use": "sig",
"alg": "EdDSA",
"crv": "Ed25519",
"status": "active",
"created_at": "2026-06-23T00:00:00Z",
"public_key_jwk": {
"kty": "OKP",
"crv": "Ed25519",
"x": "ARcMgvwCLxMm4lHCAF5GfiC2N6D2w4tM7Mcrv-h81pg"
},
"jwk_thumbprint": "dXBQ4ZkgA3nTvwrFeLAKYokanVfetC0fzXUiSFkYg08"
}
],
"cache": {
"agent_card_ttl_seconds": 86400,
"status_ttl_seconds": 60
}
}
An Agent Card MAY contain additional members. Verifiers MUST ignore
unknown members unless local policy requires otherwise. However,
unknown members are included in the canonical hash unless explicitly
excluded by this specification.
Ayoub Expires 31 December 2026 [Page 10]
Internet-Draft AgIS Agent Identity June 2026
The signature member, if present, MUST be excluded from Agent Card
canonicalization and hashing.
10. Agent Card Canonicalization and Hashing
Agent Card canonicalization uses the JSON Canonicalization Scheme
defined by [RFC8785].
To compute the Agent Card hash, a verifier MUST:
1. Parse the Agent Card as JSON.
2. Remove the top-level signature member if it is present.
3. Canonicalize the resulting JSON object using JCS.
4. Compute SHA-256 over the UTF-8 bytes of the canonicalized JSON.
5. Represent the digest as lowercase hexadecimal.
For the v0.2.2 test vector Agent Card, the expected SHA-256 digest
is:
842dbbbf1c807d020ceafe7fd8b51502cf7ae94314238e293a36c736463a3122
A verifier MUST compare the computed Agent Card hash with the DNS
Binding card_sha256 parameter if that parameter is present.
11. Agent Keys and JWK Thumbprints
Agent public keys are represented as JSON Web Keys using [RFC7517].
The preferred v0.2.2 signing key type is Ed25519 represented as an
OKP JWK. Ed25519 JWK representation follows [RFC8037].
A verifier MUST compute JWK thumbprints according to [RFC7638]. For
the v0.2.2 test vector public key:
{
"crv": "Ed25519",
"kty": "OKP",
"x": "ARcMgvwCLxMm4lHCAF5GfiC2N6D2w4tM7Mcrv-h81pg"
}
the expected JWK thumbprint is:
dXBQ4ZkgA3nTvwrFeLAKYokanVfetC0fzXUiSFkYg08
Ayoub Expires 31 December 2026 [Page 11]
Internet-Draft AgIS Agent Identity June 2026
A verifier MUST reject an Agent Card if a key's declared
jwk_thumbprint does not match the computed thumbprint for the
corresponding public_key_jwk.
A verifier SHOULD reject a DNS Binding if the jkt parameter is
present and does not match at least one active signing key in the
Agent Card.
12. Signed Agent Cards
An Agent Card MAY include a top-level signature member containing a
detached or embedded signature over the canonical Agent Card
representation. The v0.3.0-alpha.3 reference implementation uses a
compact JWS form with the following protected header:
{
"alg": "EdDSA",
"kid": "key-2026-01",
"typ": "agis-agent-card+jcs"
}
A verifier of a signed Agent Card MUST:
1. Remove the top-level signature member.
2. Canonicalize the remaining Agent Card using JCS.
3. Verify that the signed payload equals the canonical
representation.
4. Locate the signing key by kid.
5. Verify the signature using the key's public JWK.
6. Verify that the Agent Card hash remains stable after excluding
the signature member.
A verifier MUST reject a signed Agent Card if the signed payload does
not match the canonical Agent Card representation.
13. Agent Status
An Agent Status document describes the current status of an agent.
The default status endpoint is listed in the Agent Card under
endpoints.status.
The following status values are defined:
Ayoub Expires 31 December 2026 [Page 12]
Internet-Draft AgIS Agent Identity June 2026
active: The agent is active.
revoked: The agent has been revoked and MUST NOT be allowed to act.
suspended: The agent is temporarily suspended and SHOULD NOT be
allowed to act unless local policy explicitly permits it.
deprecated: The agent remains resolvable for compatibility or audit
purposes, but new integrations SHOULD NOT depend on it.
compromised: The agent or its key material is believed to be
compromised and MUST NOT be allowed to act.
unknown: The publisher cannot currently assert a stronger status.
Verifiers SHOULD treat this status conservatively.
An example active status document is:
{
"agent_id": "agent://example.com/support-agent",
"status": "active",
"updated_at": "2026-06-23T00:00:00Z",
"cache": {
"ttl_seconds": 60
}
}
An example revoked status document is:
{
"agent_id": "agent://example.com/support-agent",
"status": "revoked",
"revoked": true,
"revoked_at": "2026-06-23T00:00:00Z",
"reason": "key_compromise",
"updated_at": "2026-06-23T00:00:00Z",
"cache": {
"ttl_seconds": 30
}
}
A verifier MUST reject a status document if the agent_id does not
match the Agent Identifier under evaluation.
A verifier MUST treat revoked and compromised as denial states.
A revoked agent SHOULD remain resolvable for auditability, incident
response, and historical verification.
Ayoub Expires 31 December 2026 [Page 13]
Internet-Draft AgIS Agent Identity June 2026
13.1. Signed Status Documents
A status document MAY include a top-level signature member. When
present, the signature covers the JCS-canonicalized status document
with the signature field excluded. The reference implementation uses
EdDSA/JWS with the following structure:
{
"type": "jws",
"alg": "EdDSA",
"key_id": "key-2026-01",
"value": "<compact-jws>"
}
High-assurance deployments SHOULD require a valid status signature
before trusting a status decision. Live status fetching without
signature verification is not sufficient for high-assurance
revocation enforcement.
A verifier that requires signed status SHOULD treat an unsigned or
unverifiable status document as equivalent to an unknown status for
purposes of the policy decision. A verified signature on a revoked
status document remains a denial.
This feature is currently defined for offline deterministic use.
Production live-fetching behavior with signed status is not defined
in this version of the profile.
14. Offline Identity Verification
The v0.2.2 offline identity verification procedure takes as input:
* an Agent Identifier;
* a DNS Binding;
* an Agent Card;
* optionally, an Agent Status document.
A verifier performs the following checks:
1. The DNS Binding is syntactically valid.
2. The DNS Binding agent value matches the Agent Identifier.
3. The DNS Binding card value identifies the Agent Card URL under
evaluation.
Ayoub Expires 31 December 2026 [Page 14]
Internet-Draft AgIS Agent Identity June 2026
4. The Agent Card agent_id matches the Agent Identifier.
5. The Agent Card canonical hash matches card_sha256, if present.
6. At least one active Agent Card signing key matches jkt, if
present.
7. Each declared JWK thumbprint matches its public JWK.
8. The Agent Card signature is valid, if present.
9. The status document is valid, if present.
10. Revocation or compromise status is enforced.
A verifier MUST NOT allow a revoked or compromised agent merely
because its cryptographic signature is valid.
15. HTTP Request Signing Profile
AgIS signed requests use HTTP Message Signatures [RFC9421].
The following HTTP fields are defined by this profile:
AgIS-Agent: The Agent Identifier of the acting agent.
AgIS-Nonce: A nonce used for replay protection in high-assurance
requests.
AgIS-Delegation: A single compact delegation token.
AgIS-Delegation-Chain: A comma-separated ordered list of delegation
tokens.
AgIS request signatures use the signature label agis.
A basic signed AgIS request MUST cover at least the following
components:
"agis-agent"
"@method"
"@target-uri"
"content-digest"
"date"
The corresponding Signature-Input value has the following form:
agis=("agis-agent" "@method" "@target-uri" "content-digest" "date");created=1782249000;keyid="key-2026-01";alg="ed25519"
Ayoub Expires 31 December 2026 [Page 15]
Internet-Draft AgIS Agent Identity June 2026
The request MUST include both Signature-Input and Signature fields as
required by HTTP Message Signatures.
The request body digest MUST be represented using Content-Digest as
defined by [RFC9530]. For the v0.2.2 request-body test vector, the
expected value is:
sha-256=:EElbeZnbXXnH5AMO46WOKBIN6fvWcuBFv/qlOLFgSYk=:
A verifier MUST reject a request if the message body does not match
the Content-Digest field.
A verifier MUST reject a request if any covered signature component
has been changed after signing.
16. High-Assurance Requests, Freshness, and Replay Protection
A high-assurance AgIS request includes AgIS-Nonce and signs it.
A high-assurance request MUST cover at least the following
components:
"agis-agent"
"agis-nonce"
"@method"
"@target-uri"
"content-digest"
"date"
Example:
agis=("agis-agent" "agis-nonce" "@method" "@target-uri" "content-digest" "date");created=1782249000;keyid="key-2026-01";alg="ed25519"
A verifier of high-assurance requests MUST enforce freshness. The
verifier SHOULD reject requests whose Date field falls outside a
locally configured freshness window. A default freshness window of
300 seconds is RECOMMENDED for deployments that do not have stronger
time synchronization or policy requirements.
A verifier of high-assurance requests MUST enforce replay protection.
The tuple used for replay detection SHOULD include:
* the Agent Identifier;
* the nonce;
* the HTTP method;
Ayoub Expires 31 December 2026 [Page 16]
Internet-Draft AgIS Agent Identity June 2026
* the target URI;
* the signature key identifier;
* a freshness-window identifier or expiration time.
A verifier MUST reject a high-assurance request if the nonce is
missing.
A verifier MUST reject a high-assurance request if the nonce has
already been observed within the replay-protection window.
A verifier MUST NOT commit a nonce to the replay-protection cache
until all cryptographic checks — including the HTTP message signature
— have passed. Committing a nonce before signature verification
would allow an attacker to deny service by burning valid nonces using
forged or malformed requests. The two-phase approach — checking
replay state before cryptographic verification, but committing only
after all checks succeed — is REQUIRED for high-assurance replay
protection.
17. Delegation Tokens
AgIS delegation tokens allow one agent to delegate a constrained
capability to another agent.
A v0.2.2 delegation token is a compact signed token whose payload
contains at least the following members:
{
"type": "agis-delegation",
"version": "0.2.2",
"issuer": "agent://example.com/support-agent",
"subject": "agent://example.com/invoice-worker",
"audience": "https://api.service.example",
"scope": [
"resource:read",
"invoice:read"
],
"constraints": {
"max_requests": 10,
"purpose": "invoice-processing"
},
"issued_at": "2026-06-23T18:30:00Z",
"expires_at": "2026-06-23T18:45:00Z",
"jti": "delegation-2026-06-23-001"
}
Ayoub Expires 31 December 2026 [Page 17]
Internet-Draft AgIS Agent Identity June 2026
The protected header for a v0.2.2 delegation token uses:
{
"alg": "EdDSA",
"kid": "key-2026-01",
"typ": "agis-delegation+jwt"
}
A verifier MUST reject a delegation token if:
* the signature is invalid;
* the token is expired;
* the token is not yet valid;
* the audience does not match the expected relying party;
* the required scope is not included in the delegated scope;
* the acting agent does not match the token subject;
* the jti member is missing;
* local policy rejects any declared constraint.
A delegation token MUST NOT be interpreted as an unrestricted bearer
credential. It is a signed, scoped, time-bounded statement whose
validity depends on signature verification, subject matching,
audience matching, scope checking, time validation, and local policy.
18. Delegated Signed Requests
A delegated signed request includes:
* AgIS-Agent, identifying the acting agent;
* AgIS-Delegation, carrying the delegation token;
* Content-Digest;
* Signature-Input;
* Signature.
A delegated signed request MUST sign the AgIS-Delegation field.
Ayoub Expires 31 December 2026 [Page 18]
Internet-Draft AgIS Agent Identity June 2026
The following signature components are REQUIRED for a single-
delegation request:
"agis-agent"
"agis-delegation"
"@method"
"@target-uri"
"content-digest"
"date"
A verifier MUST reject the request if the AgIS-Agent value does not
match the delegation token subject.
A verifier MUST reject the request if the delegation token is changed
after the HTTP signature is produced.
A verifier MUST reject a delegated signed request unless the HTTP
message signature key is bound to the delegation subject, as
established by that subject's verified Agent Card key set or
equivalent verified identity evidence.
A verifier MUST NOT accept a delegated signed request merely because
both of the following are true:
* the delegation token is cryptographically valid, and
* the HTTP request signature is cryptographically valid under some
caller-supplied key.
The HTTP message signer key and the delegation subject MUST be
verifiably bound to the same identity. A valid delegation token and
a valid request signature that were checked independently, without
confirming that both refer to the same acting agent's key material,
do not together constitute a valid delegated request.
19. Delegation Chains
A delegation chain is an ordered sequence of delegation tokens. Each
token delegates from one agent to the next.
For a valid chain:
* the first token's issuer is the root issuer;
* the first token's subject is the second token's issuer;
* each subsequent token's subject is the next token's issuer;
Ayoub Expires 31 December 2026 [Page 19]
Internet-Draft AgIS Agent Identity June 2026
* the final token's subject is the acting agent;
* the acting agent matches AgIS-Agent;
* the audience is valid for each token;
* the required scope is included in the effective scope;
* each token is within its validity interval;
* each token has a valid signature;
* each token contains a jti.
The effective scope of a delegation chain MUST NOT exceed the scope
granted upstream. Implementations SHOULD compute effective scope as
the intersection of scopes across the chain unless local policy
defines a stricter rule.
A delegation chain signed request includes AgIS-Delegation-Chain.
The signature MUST cover that field.
The following signature components are REQUIRED for a delegation-
chain request:
"agis-agent"
"agis-delegation-chain"
"@method"
"@target-uri"
"content-digest"
"date"
A verifier MUST reject a delegation-chain signed request unless the
HTTP message signature key is bound to the final subject of the
delegation chain, as established by that final subject's verified
Agent Card key set or equivalent verified identity evidence. The
final subject is the agent that acts on the delegated authority.
A verifier MUST NOT accept a chained delegated request merely because
the delegation chain verifies and the HTTP request signature is
cryptographically valid under some caller-supplied key. Both the
chain and the request signer MUST be traceable to the same final
subject's verified key material.
A verifier MUST reject a delegation chain if:
* the chain order is reversed;
Ayoub Expires 31 December 2026 [Page 20]
Internet-Draft AgIS Agent Identity June 2026
* any link is broken;
* a downstream token attempts scope escalation;
* the acting agent does not match the final subject;
* the required scope is not in the effective scope;
* any token is expired;
* the chain field is modified after signing;
* the HTTP message signature key is not bound to the final subject's
verified key set.
20. Trust Levels
AgIS defines the following non-normative trust levels for reporting
verification strength:
Level 0: No usable AgIS identity evidence is available.
Level 1: The Agent Identifier and Agent Card are syntactically
valid.
Level 2: A DNS Binding exists and links the Agent Identifier to an
Agent Card URL.
Level 3: The Agent Card hash and JWK thumbprint are consistent with
the DNS Binding and Agent Card.
Level 4: The Agent Card signature and status checks are valid, and
the agent is active.
Level 5: A signed request is valid with freshness and replay
protection enforced, and local policy accepts the result.
The v0.2.2 offline reference identity verification test vectors reach
Level 4. High-assurance signed request verification can reach Level
5 when freshness and replay protection are enforced by the verifier.
Trust levels are advisory. Implementations MUST NOT treat a trust
level as a replacement for local authorization policy.
21. Error Model
AgIS implementations SHOULD expose deterministic error codes suitable
for test-vector validation and debugging.
Ayoub Expires 31 December 2026 [Page 21]
Internet-Draft AgIS Agent Identity June 2026
The following error categories are RECOMMENDED:
* DNS binding errors;
* Agent Card hash errors;
* JWK thumbprint errors;
* Agent Card signature errors;
* status and revocation errors;
* Content-Digest errors;
* HTTP signature errors;
* freshness errors;
* replay-detection errors;
* delegation token errors;
* delegation chain errors;
* local policy denial.
Error messages SHOULD be safe to log. Error messages MUST NOT
include private keys, secret tokens, bearer credentials, or
unredacted sensitive request bodies.
22. Deterministic Test Vectors
The v0.3.0-alpha.3 reference implementation includes 23 deterministic
test vectors for:
* Agent Card canonical hash (TV001);
* JWK thumbprint (TV002);
* DNS TXT Binding (TV003);
* signed Agent Card (TV004);
* Agent Card tampering — negative (TV004-tamper);
* Agent Status and revocation (TV005);
* invalid status documents — negative (TV005-negative);
Ayoub Expires 31 December 2026 [Page 22]
Internet-Draft AgIS Agent Identity June 2026
* offline composite identity verification (TV006);
* invalid composite verification cases — negative (TV006-negative);
* Content-Digest (TV007);
* invalid Content-Digest cases — negative (TV007-negative);
* HTTP Message Signatures (TV008);
* invalid HTTP signature cases — negative (TV008-negative);
* offline signed request verification (TV009);
* invalid signed request cases — negative (TV009-negative);
* freshness and replay protection (TV010);
* invalid freshness and replay cases — negative (TV010-negative);
* single delegation token (TV011);
* invalid delegation token cases — negative (TV011-negative);
* delegated signed request with signer-key binding (TV012);
* invalid delegated request cases — negative (TV012-negative);
* delegation chain signed request with final-subject key binding
(TV013);
* invalid delegation chain request cases — negative
(TV013-negative);
* status decision policy across all six status values (TV014);
* delegated request with attacker key — negative (TV015-negative);
* chain delegated request with attacker key — negative
(TV016-negative);
* replay nonce not committed on invalid signature — negative
(TV017-negative);
* deprecated unbound signer key, deny by default — negative
(TV018-negative);
Ayoub Expires 31 December 2026 [Page 23]
Internet-Draft AgIS Agent Identity June 2026
* deprecated unbound signer key, explicit opt-in allows with warning
(TV019);
* signed active status document: valid signature, decision allow
(TV020);
* tampered signed status document: signature fails, decision deny
(TV021-negative);
* signed revoked status document: valid signature, decision deny —
status policy (TV022-negative);
* unsigned status document with required signature: decision deny
(TV023-negative).
Independent implementations SHOULD validate against the deterministic
test vectors before claiming compatibility with this profile.
23. Security Considerations
AgIS is a security-sensitive identity and request-verification
profile. Implementations and deployments need to consider at least
the following threats.
23.1. DNS Control and Domain Compromise
AgIS binds agent identity to DNS names. If an attacker controls the
DNS zone, registrar account, authoritative DNS provider account, or
DNS publication pipeline, the attacker can publish malicious Agent
Bindings.
Deployments SHOULD protect registrar and DNS provider accounts with
strong authentication and operational controls. DNSSEC MAY be used
where available, but this document does not require DNSSEC.
23.2. HTTPS Publication Security
Agent Cards and status documents are expected to be published over
HTTPS. If HTTPS publication infrastructure is compromised, an
attacker may publish altered Agent Cards or status documents.
Verifiers SHOULD prefer DNS Binding values that include card_sha256
and jkt, because these allow detection of Agent Card or key
substitution when the DNS Binding remains trustworthy.
Ayoub Expires 31 December 2026 [Page 24]
Internet-Draft AgIS Agent Identity June 2026
23.3. Canonicalization Attacks
Incorrect JSON canonicalization can cause implementations to compute
different hashes or verify different payloads. Implementations MUST
use JCS as specified by this document and MUST exclude only the top-
level signature member from Agent Card hashing.
Implementations MUST NOT canonicalize by using ordinary pretty-
printing, unstable object key ordering, locale-sensitive ordering, or
runtime-specific serialization behavior.
23.4. Key Compromise
If an agent signing key is compromised, an attacker may produce valid
signatures until the key is revoked or removed from the Agent Card
and status information is updated.
Publishers SHOULD provide short status TTLs for higher-risk agents.
Verifiers SHOULD respect revocation and compromised states even when
signatures remain cryptographically valid.
23.5. Revocation Caching
Caching improves availability but can delay enforcement of
revocation. Publishers SHOULD use conservative status TTLs.
Verifiers SHOULD bound cache lifetime and MAY re-check status for
high-risk operations.
23.6. Replay Attacks
Signed requests without freshness and replay protection can be
captured and replayed. High-assurance deployments MUST require
freshness checking and nonce-based replay protection.
23.7. Clock Skew
Freshness checks depend on clocks. Verifiers SHOULD define an
acceptable clock-skew window. Deployments SHOULD maintain reliable
time synchronization.
23.8. Signature Confusion
Implementations MUST verify the expected signature label and covered
components. A signature over one set of components MUST NOT be
accepted as proof over a different set of components.
Ayoub Expires 31 December 2026 [Page 25]
Internet-Draft AgIS Agent Identity June 2026
23.9. Delegation Confusion and Signer-Key Binding
Delegation tokens MUST be checked for issuer, subject, audience,
scope, time validity, and jti. A delegation token MUST NOT be
treated as an unrestricted bearer credential.
Delegation chains MUST preserve order and MUST prevent downstream
scope escalation.
A critical class of delegation confusion arises when a verifier
checks the delegation token and the HTTP request signature
independently without confirming that both are associated with the
same acting agent's key material. In such a case, an attacker may
present a legitimate delegation token alongside an HTTP request
signed by a different key — a key that the attacker controls — and
thereby act on delegated authority without possessing the legitimate
agent's signing key.
To prevent this, implementations MUST bind:
* the delegation token signature key to the delegation issuer's
verified identity; and
* the HTTP request signature key to the delegation subject's (or
chain final subject's) verified identity.
The HTTP message signer key MUST be resolved from the delegation
subject's verified key set. A verifier MUST NOT derive an allow
decision from the combination of a valid delegation token and a valid
HTTP request signature unless both keys are bound to the
corresponding agents' verified identity evidence.
Failure to enforce this binding allows confused-deputy behavior,
where the delegation grants authority over one agent and the request
signature is produced by a different, potentially malicious party.
23.10. Status Document Integrity
Status document values directly control the trust decision for an
agent: active produces allow; revoked, suspended, and compromised
produce deny; unknown and deprecated produce review. An attacker who
can modify a status document in transit or at rest can therefore
elevate a revoked agent to active, or deny service to a legitimate
agent.
Ayoub Expires 31 December 2026 [Page 26]
Internet-Draft AgIS Agent Identity June 2026
The v0.3.0-alpha.3 reference implementation supports optional and
required EdDSA/JWS signatures over status documents. The signature
covers the JCS-canonicalized status document excluding the signature
field. Verifiers can require a valid status signature before
accepting a status decision.
For live status retrieval, implementations MUST protect status
endpoint access using authenticated transport (HTTPS with valid
certificates). Live status fetching without signature verification
is not sufficient for high-assurance revocation enforcement; an
unsigned status document served over plain HTTPS is susceptible to
modification by an adversary who controls the status endpoint or a
network path to it.
Production deployments SHOULD use signed status documents.
Implementations SHOULD verify the status document signature before
trusting a status decision in any high-assurance context. The status
signature key SHOULD be the same key declared in the Agent Card, or a
key verifiably associated with the same agent identity.
Implementations MUST NOT treat the current alpha signed status
document support as a complete production mechanism. Live DNS and
HTTPS resolver behavior and long-term key management for status
signing remain out of scope for this profile version.
23.11. Test Keys
The deterministic test keys included with the reference
implementation are public test material. They MUST NOT be used in
production.
23.12. Local Authorization
AgIS verification does not authorize an action by itself. A relying
party MUST apply local authorization policy after identity, request,
freshness, status, and delegation checks.
24. Privacy Considerations
AgIS identifiers, DNS Binding names, Agent Card URLs, and status
endpoints may reveal information about an organization's internal
agent naming, capabilities, deployment structure, or operational
status.
Publishers SHOULD avoid embedding sensitive internal project names,
customer names, incident information, or confidential workflow
details in public Agent Identifiers or Agent Cards.
Ayoub Expires 31 December 2026 [Page 27]
Internet-Draft AgIS Agent Identity June 2026
Verifiers SHOULD avoid logging sensitive request bodies, delegation
tokens, or identifiers beyond operational necessity.
Delegation chains can reveal workflow structure. Deployments SHOULD
minimize delegated scope, token lifetime, and exposed constraints.
25. IANA Considerations
This document makes no IANA requests at this time.
Future versions may request registration of:
* the agent URI scheme;
* an AgIS well-known URI;
* AgIS-specific HTTP field names;
* AgIS parameter registries.
No such registrations are requested by this version of the document.
26. Implementation Status
This section records implementation status for informational purposes
and is expected to be removed or updated before publication as an
RFC.
The AgIS v0.3.0-alpha.3 reference implementation includes:
* a TypeScript SDK (@epicortek/agis-sdk-ts);
* a CLI named agis (@epicortek/agis-cli);
* 23 deterministic test vectors covering all features and selected
negative cases;
* offline identity verification;
* Agent Card canonical hashing;
* JWK thumbprint verification;
* DNS Binding parsing;
* signed Agent Card verification with explicit EdDSA algorithm
verification;
Ayoub Expires 31 December 2026 [Page 28]
Internet-Draft AgIS Agent Identity June 2026
* status and revocation validation with a status decision policy
(active → allow, revoked/suspended/compromised → deny, unknown/
deprecated → review);
* signed agent status document support: EdDSA/JWS signature
generation and verification over JCS-canonicalized status
documents; optional or required signature verification with
requireSignature option;
* Content-Digest validation;
* HTTP Message Signature verification;
* freshness and two-phase replay protection (check then commit only
on allow);
* single delegation token verification;
* delegated signed request verification with signer-key binding
enforced by default;
* delegation chain verification with final-subject signer-key
binding enforced by default.
The implementation enforces that delegated request verification
produces an allow decision only when the HTTP message signature key
is demonstrably bound to the delegation subject's verified identity.
A deprecated compatibility path (requestSignerPublicJwk without
actingSubjectPublicKeys) requires an explicit caller opt-in flag
(allowUnboundDeprecatedSignerKey: true) and produces a warning;
without the opt-in, the decision is deny.
The implementation is positioned as an ANS-compatible verification
and governance layer. It is not affiliated with or endorsed by Linux
Foundation ANS.
The implementation does not yet define production live DNS or HTTPS
resolver behavior, DNSSEC validation requirements, automatic binding
of status signing keys to live resolver trust anchors, a production
trust network, or a global trust root.
27. Acknowledgements
The author thanks the broader Internet standards community whose
existing specifications make it possible to define AgIS as a narrow
profile over deployed web infrastructure rather than as a new stack.
28. References
Ayoub Expires 31 December 2026 [Page 29]
Internet-Draft AgIS Agent Identity June 2026
28.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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/rfc/rfc7638>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/rfc/rfc8037>.
[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>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[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>.
[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/rfc/rfc9110>.
Ayoub Expires 31 December 2026 [Page 30]
Internet-Draft AgIS Agent Identity June 2026
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/rfc/rfc9530>.
28.2. Informative References
[AGIS-CLI] EPICORTEK Technologies Inc., "AgIS CLI", 2026,
<https://www.npmjs.com/package/@epicortek/agis-cli>.
[AGIS-IMPL]
EPICORTEK Technologies Inc., "AgIS v0.3.0-alpha.3
Reference Implementation, CLI, and Deterministic Test
Vectors", 2026, <https://github.com/epicortek/agis>.
[AGIS-SDK] EPICORTEK Technologies Inc., "AgIS TypeScript SDK", 2026,
<https://www.npmjs.com/package/@epicortek/agis-sdk-ts>.
Appendix A. Example Agent Identifier
agent://example.com/support-agent
Appendix B. Example DNS TXT Binding
agis=0.2.2; agent=agent://example.com/support-agent; card=https://example.com/.well-known/agis/agents/support-agent.json; jkt=dXBQ4ZkgA3nTvwrFeLAKYokanVfetC0fzXUiSFkYg08; card_sha256=842dbbbf1c807d020ceafe7fd8b51502cf7ae94314238e293a36c736463a3122
Appendix C. Example Agent Card Hash
842dbbbf1c807d020ceafe7fd8b51502cf7ae94314238e293a36c736463a3122
Appendix D. Example JWK Thumbprint
dXBQ4ZkgA3nTvwrFeLAKYokanVfetC0fzXUiSFkYg08
Appendix E. Example Content-Digest
sha-256=:EElbeZnbXXnH5AMO46WOKBIN6fvWcuBFv/qlOLFgSYk=:
Author's Address
Rizkallah Ayoub
EPICORTEK Technologies Inc.
Email: rizk.ayoub@epicortek.com
Ayoub Expires 31 December 2026 [Page 31]