Network Working Group K. Kanojia Internet-Draft IDevSec Intended status: Standards Track 2 September 2026 Expires: 6 March 2027 The 'agent' Uniform Resource Identifier (URI) Scheme and Cryptographic Attestation Protocol draft-kanojia-creduent-agent-uri-00 Abstract This document specifies the 'agent' Uniform Resource Identifier (URI) scheme and its associated cryptographic attestation protocol. The 'agent' scheme defines a transport-agnostic, cryptographically verifiable addressing layer for identifying autonomous software agents, binding domain ownership via DNS TXT records, enforcing instruction integrity, and validating attenuated capability delegation tokens. 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 6 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Kanojia Expires 6 March 2027 [Page 1] Internet-Draft agent URI and Attestation September 2026 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 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Protocol Goals . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 3. URI Scheme Specification . . . . . . . . . . . . . . . . . . 4 3.1. ABNF Syntax Definition . . . . . . . . . . . . . . . . . 4 3.2. URI Normalization and Canonicalization . . . . . . . . . 4 3.3. Example URIs . . . . . . . . . . . . . . . . . . . . . . 4 4. Cryptographic Identity Document Format (agent.json) . . . . . 4 4.1. Field Definitions . . . . . . . . . . . . . . . . . . . . 5 4.2. JSON Canonicalization Scheme (JCS) Processing . . . . . . 5 4.3. Ed25519 Signature Generation and Validation . . . . . . . 5 4.4. Complete Example Document . . . . . . . . . . . . . . . . 6 5. Resolution and Verification Architecture . . . . . . . . . . 6 5.1. Resolution Algorithm . . . . . . . . . . . . . . . . . . 6 5.2. DNS TXT Ownership Verification . . . . . . . . . . . . . 7 5.3. Registry Attestation Verification . . . . . . . . . . . . 7 6. Delegation Tokens and Capability Attenuation (CDT) . . . . . 7 6.1. Token Payload Format . . . . . . . . . . . . . . . . . . 7 6.2. Recursive Delegation Chain Validation . . . . . . . . . . 7 7. Prompt Integrity and Action Reversibility (CREDUENT-006) . . 7 7.1. Instruction Hashing . . . . . . . . . . . . . . . . . . . 7 7.2. Reversibility Classifications (AISVS C9.2.3) . . . . . . 8 7.3. Ledger Hash-Chain Receipts . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8.1. URI Scheme Registration Template . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 8 9.2. Mitigation of Replay and Downgrade Attacks . . . . . . . 8 9.3. Key Revocation and Out-of-Band Recovery . . . . . . . . . 9 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 11. Informative References . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Kanojia Expires 6 March 2027 [Page 2] Internet-Draft agent URI and Attestation September 2026 1. Introduction 1.1. Problem Statement Autonomous software agents operating across distributed multi-cloud networks, model contexts, and tool environments require a unified, cryptographically secure identity layer. Existing network addressing schemes (HTTP URLs, gRPC endpoints) route traffic to server hosts, but fail to verify: 1. Whether the remote software process possesses a verified cryptographic key pair. 2. Whether the agent's domain identity matches DNS infrastructure ownership. 3. Whether active system prompts and tool capabilities have been tampered with. 4. Whether sub-agent tasks carry valid, scope-restricted delegation tokens. 1.2. Protocol Goals The Creduent protocol specifies the 'agent' URI scheme to establish a verifiable trust root for software agents. The protocol provides: * Deterministic resolution from 'agent://' URIs to signed identity documents. * Cryptographic key binding using Ed25519 digital signatures and JCS. * Domain-level ownership validation via DNS TXT records. * Attenuated capability delegation via Creduent Delegation Tokens (CDT). 2. Terminology and Conventions 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. * *Agent Identity:* An Ed25519 public key pair uniquely bound to an autonomous agent. Kanojia Expires 6 March 2027 [Page 3] Internet-Draft agent URI and Attestation September 2026 * *agent.json:* A JSON document canonicalized per RFC 8785 containing public keys, capabilities, and owner metadata. * *Authority:* The domain name or host portion of an 'agent' URI responsible for identity resolution. * *Attestation:* A cryptographically signed assertion issued by an authoritative registry validating DNS ownership. 3. URI Scheme Specification 3.1. ABNF Syntax Definition The 'agent' URI scheme is specified using Augmented Backus-Naur Form (ABNF) as defined in [RFC5234]. agent-URI = "agent://" agent-authority "/" agent-path [ "?" query ] [ "#" fragment ] agent-authority = host [ ":" port ] host = IP-literal / IPv4address / reg-name agent-path = segment-nz *( "/" segment ) segment-nz = 1*pchar segment = *pchar pchar = unreserved / pct-encoded / sub-delims / ":" / "@" unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 3.2. URI Normalization and Canonicalization Implementations MUST normalize 'agent' URIs prior to signature validation: * Scheme names MUST be converted to lowercase ("agent://"). * Hostnames MUST be converted to lowercase per Internationalized Domain Names rules. * Default ports (if specified) MUST be removed. 3.3. Example URIs agent://example.com/finance/payroll-bot agent://registry.idevsec.com/agents/audit-verifier agent://192.168.1.100:8443/local-agent 4. Cryptographic Identity Document Format (agent.json) Kanojia Expires 6 March 2027 [Page 4] Internet-Draft agent URI and Attestation September 2026 4.1. Field Definitions The identity payload MUST contain the following top-level JSON fields: * *version* (string, REQUIRED): Protocol version identifier (e.g. "2.0"). * *agent_id* (string, REQUIRED): The absolute 'agent://' URI of the agent. * *name* (string, REQUIRED): Human-readable name of the agent. * *owner* (string, REQUIRED): Contact URI or email of the controlling entity. * *keys* (array, REQUIRED): List of public key objects (id, type, publicKeyMultibase). * *capabilities* (array, OPTIONAL): List of declared tool and API permissions. * *signature* (object, REQUIRED): Signature envelope object (type, created, verificationMethod, proofValue). 4.2. JSON Canonicalization Scheme (JCS) Processing To generate or verify signatures, the document MUST be canonicalized using JCS [RFC8785]: 1. Remove the "signature" key-value pair from the document. 2. Sort object keys lexicographically by Unicode code point values. 3. Serialize strings using UTF-8 encoding without whitespace between elements. 4. Represent numbers according to IEEE 754 double precision without trailing zeroes. 4.3. Ed25519 Signature Generation and Validation Signatures MUST be generated using Ed25519 [RFC8032] over the UTF-8 bytes of the canonicalized JCS document: signature_bytes = Ed25519_Sign(private_key, JCS_Canonicalize(document)) Kanojia Expires 6 March 2027 [Page 5] Internet-Draft agent URI and Attestation September 2026 4.4. Complete Example Document { "version": "2.0", "agent_id": "agent://example.com/auditor", "name": "Financial Compliance Agent", "owner": "mailto:security@example.com", "keys": [ { "id": "agent://example.com/auditor#key-1", "type": "Ed25519VerificationKey2020", "publicKeyMultibase": "z6MkpTHR8VNsBxYAAWHuTnGd28N5Kjd8" } ], "capabilities": [ "ledger:read", "reports:generate" ], "signature": { "type": "Ed25519Signature2020", "created": "2026-08-09T12:00:00Z", "verificationMethod": "agent://example.com/auditor#key-1", "proofValue": "kB84j2...b9x0A==" } } 5. Resolution and Verification Architecture 5.1. Resolution Algorithm When resolving an 'agent' URI (e.g. "agent://example.com/auditor"), clients MUST: 1. Construct HTTP Endpoint: Issue an HTTPS GET request to https://example.com/.well-known/agent.json 2. Parse and Validate Schema: Parse the JSON response and confirm all required fields. 3. Verify JCS Signature: Execute the signature validation steps in Section 4.3. 4. Perform DNS Ownership Check: Verify domain key records per Section 5.2. Kanojia Expires 6 March 2027 [Page 6] Internet-Draft agent URI and Attestation September 2026 5.2. DNS TXT Ownership Verification To prevent identity spoofing, the domain owner MUST publish a DNS TXT record at _creduent.. _creduent.example.com. IN TXT "v=CRE1; k=ed25519; p=z6MkpTHR8VNsBxYAAWHuTnGd28N5Kjd8" Clients MUST match the public key in the DNS TXT record against the public key used to sign the agent.json document. 5.3. Registry Attestation Verification Registries acting as third-party identity checkers issue signed attestations containing agent_id, DNS TXT verification status (PASS/ FAIL), and expiration timestamps. 6. Delegation Tokens and Capability Attenuation (CDT) 6.1. Token Payload Format Parent agents delegating authority to child sub-agents MUST issue a Creduent Delegation Token (CDT / CREDUENT-007): { "iss": "agent://example.com/parent-agent", "sub": "agent://example.com/child-worker", "aud": "agent://target-service.com/api", "exp": 1786276800, "capabilities": [ "db:read:readonly_table" ], "depth_limit": 2 } 6.2. Recursive Delegation Chain Validation Verifying endpoints receiving a delegation chain MUST recursively validate Ed25519 signatures, capability subset constraints, and depth limit thresholds. 7. Prompt Integrity and Action Reversibility (CREDUENT-006) 7.1. Instruction Hashing Agents MAY publish an instruction hash in execution headers: X- Creduent-Instruction-Hash: SHA256(canonical_system_prompt) Kanojia Expires 6 March 2027 [Page 7] Internet-Draft agent URI and Attestation September 2026 7.2. Reversibility Classifications (AISVS C9.2.3) Actions MUST specify a reversibility classification aligned with OWASP AISVS C9.2.3: read-only, reversible, external-reversible, irreversible. 7.3. Ledger Hash-Chain Receipts Multi-step agent action chains MUST commit cryptographic step receipts to the registry ledger. 8. IANA Considerations 8.1. URI Scheme Registration Template The 'agent' URI scheme registration follows the guidelines defined in BCP 35 [RFC7595]. Scheme name: agent Status: Permanent Applications: Autonomous AI agent systems, MCP hosts, microservice swarms. Contact: Kashish Kanojia Change controller: IETF / Creduent Protocol Working Group References: draft-kanojia-creduent-agent-uri-00 9. Security Considerations 9.1. Threat Model The protocol protects against Identity Spoofing, Privilege Escalation, and Execution History Tampering. 9.2. Mitigation of Replay and Downgrade Attacks Verifying endpoints MUST reject attestations with expired timestamps. HTTP connections without TLS 1.3 MUST be refused. Kanojia Expires 6 March 2027 [Page 8] Internet-Draft agent URI and Attestation September 2026 9.3. Key Revocation and Out-of-Band Recovery In case of key compromise, domain owners MUST update the _creduent DNS TXT record with a new key hash. Registries MUST invalidate revoked public keys within 300 seconds. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, . [RFC7595] Thaler, D., Ed., "Guidelines and Procedures for Registration of URI Schemes", BCP 35, RFC 7595, June 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 11. Informative References [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (Ed25519)", RFC 8032, January 2017, . [RFC8785] Rundgren, A., "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . Author's Address Kashish Kanojia IDevSec Email: kashish@idevsec.com URI: https://idevsec.com Kanojia Expires 6 March 2027 [Page 9]