]> EPICORTEK Technologies Inc.

rizk.ayoub@epicortek.com

Security Internet Engineering Task Force agent identity AI agents DNS HTTP message signatures delegation verification 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.

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

Goals AgIS has the following design goals: Reuse existing web infrastructure. Make agent identity independently verifiable. Bind an agent identifier to a domain-controlled publication point. Support deterministic offline verification. Support signed HTTP requests using an existing HTTP signature framework. Support revocation and status checks. Support scoped delegation and delegation chains. Avoid requiring a global AgIS root authority. Avoid requiring blockchain, new DNS infrastructure, or new transport protocols. Provide deterministic test vectors for independent implementations.

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

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

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.

Agent Identifier An AgIS Agent Identifier has the following form:

For example:

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:

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.

HTTPS Equivalent Identifier An Agent Identifier maps to a default HTTPS publication location:

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.

Agent Card Location The default Agent Card location is:

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.

DNS TXT Binding The default DNS TXT owner name for an agent is:

For the Agent Identifier:

the default DNS TXT owner name is:

A minimal DNS TXT binding has the following form:

A recommended DNS TXT binding additionally includes a JWK thumbprint and Agent Card hash:

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.

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.

Agent Card An Agent Card is a JSON document describing an agent. The v0.2.2 profile defines the following required members:

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. The signature member, if present, MUST be excluded from Agent Card canonicalization and hashing.

Agent Card Canonicalization and Hashing Agent Card canonicalization uses the JSON Canonicalization Scheme defined by . To compute the Agent Card hash, a verifier MUST: Parse the Agent Card as JSON. Remove the top-level signature member if it is present. Canonicalize the resulting JSON object using JCS. Compute SHA-256 over the UTF-8 bytes of the canonicalized JSON. Represent the digest as lowercase hexadecimal. For the v0.2.2 test vector Agent Card, the expected SHA-256 digest is:

A verifier MUST compare the computed Agent Card hash with the DNS Binding card_sha256 parameter if that parameter is present.

Agent Keys and JWK Thumbprints Agent public keys are represented as JSON Web Keys using . The preferred v0.2.2 signing key type is Ed25519 represented as an OKP JWK. Ed25519 JWK representation follows . A verifier MUST compute JWK thumbprints according to . For the v0.2.2 test vector public key:

the expected JWK thumbprint is:

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.

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:

A verifier of a signed Agent Card MUST: Remove the top-level signature member. Canonicalize the remaining Agent Card using JCS. Verify that the signed payload equals the canonical representation. Locate the signing key by kid. Verify the signature using the key's public JWK. 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.

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:

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:

An example revoked status document is:

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.

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:

" } ]]>

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.

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: The DNS Binding is syntactically valid. The DNS Binding agent value matches the Agent Identifier. The DNS Binding card value identifies the Agent Card URL under evaluation. The Agent Card agent_id matches the Agent Identifier. The Agent Card canonical hash matches card_sha256, if present. At least one active Agent Card signing key matches jkt, if present. Each declared JWK thumbprint matches its public JWK. The Agent Card signature is valid, if present. The status document is valid, if present. Revocation or compromise status is enforced. A verifier MUST NOT allow a revoked or compromised agent merely because its cryptographic signature is valid.

HTTP Request Signing Profile AgIS signed requests use HTTP Message Signatures . 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:

The corresponding Signature-Input value has the following form:

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 . For the v0.2.2 request-body test vector, the expected value is:

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.

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:

Example:

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

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:

The protected header for a v0.2.2 delegation token uses:

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.

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. The following signature components are REQUIRED for a single-delegation request:

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.

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; 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:

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

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.

Error Model AgIS implementations SHOULD expose deterministic error codes suitable for test-vector validation and debugging. 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.

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

Security Considerations AgIS is a security-sensitive identity and request-verification profile. Implementations and deployments need to consider at least the following threats.

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.

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.

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.

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.

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.

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.

Clock Skew Freshness checks depend on clocks. Verifiers SHOULD define an acceptable clock-skew window. Deployments SHOULD maintain reliable time synchronization.

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.

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.

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

Test Keys The deterministic test keys included with the reference implementation are public test material. They MUST NOT be used in production.

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.

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

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.

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

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.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. EPICORTEK Technologies Inc. EPICORTEK Technologies Inc. EPICORTEK Technologies Inc.

Example Agent Identifier

Example DNS TXT Binding

Example Agent Card Hash

Example JWK Thumbprint

Example Content-Digest