The 'agent' Uniform Resource Identifier (URI) Scheme and Cryptographic Attestation Protocol

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

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

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

5.2. DNS TXT Ownership Verification

To prevent identity spoofing, the domain owner MUST publish a DNS TXT record at _creduent.<authority>.¶

_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.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.1. Instruction Hashing

Agents MAY publish an instruction hash in execution headers: X-Creduent-Instruction-Hash: SHA256(canonical_system_prompt)¶

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.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 <kashish@idevsec.com>

Change controller:
   IETF / Creduent Protocol Working Group

References:
   draft-kanojia-creduent-agent-uri-00

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

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