Servesys Labs

contact@servsys.com

Internet Independent Submission AI agents semantic routing decentralized identity intent exchange negotiation protocol This document specifies the AI-Native Network Protocol (AINP) version 0.1, a semantic communication protocol designed for intent exchange between AI agents. AINP replaces location-based routing with semantic routing, byte-stream delivery with intent delivery, and simple handshakes with multi-round negotiation. AINP enables agents to discover each other by capability rather than network location, negotiate terms autonomously, and exchange structured intents with cryptographic security.

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 . 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 28 May 2026.

Copyright Notice Copyright (c) 2025 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 () 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

• .  Introduction
  • .  Terminology
    • .  Definitions
• .  Architecture Overview
• .  Wire Format
  • .  Encoding
  • .  Message Envelope
    • .  Envelope Fields
  • .  Message Types
  • .  Quality of Service Parameters
  • .  Capability Query
  • .  Signature Format
• .  Semantic Addresses
  • .  Decentralized Identifiers (DIDs)
  • .  Semantic Address Structure
• .  Intent Schemas
  • .  REQUEST_MEETING Intent
  • .  APPROVAL_REQUEST Intent
  • .  SUBMIT_INFO Intent
  • .  INVOICE Intent
  • .  FREEFORM_NOTE Intent
  • .  REQUEST_SERVICE Intent
• .  Negotiation Protocol
  • .  Negotiation Flow
  • .  Negotiation Message Structure
  • .  Negotiation Convergence
  • .  Timeout Behavior
  • .  Multi-Party Negotiation
• .  Protocol Handshake Sequence
  • .  Five-Step Handshake
  • .  ADVERTISE Phase
  • .  DISCOVER Phase
  • .  ERROR Phase
  • .  Offline Intent Queueing
• .  Security Considerations
  • .  Authentication
  • .  Identity
  • .  Rate Limiting
  • .  Replay Protection
  • .  DoS Protection
  • .  Replay Protection and Delivery Semantics
  • .  Capability Attestations
  • .  Timeouts
  • .  Outlier Detection
  • . Discovery Scalability
  • . Lite Mode for Resource-Constrained Agents
• .  CBOR Encoding (Optional)
• . Extensibility
  • .  Custom Intent Types
  • .  Custom Negotiation Terms
  • .  Versioning
  • .  Lite Profile (Trusted Networks)
• . Success Metrics
  • .  Route Success Rate
  • .  Latency (p95)
  • .  Negotiation Completion Rate
  • .  False Route Rate
  • .  Abuse Resilience
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Author's Address

Introduction Traditional network protocols (TCP/IP, HTTP, SMTP) were designed for reliable byte stream delivery between machines. AINP represents a paradigm shift: it is designed for semantic intent delivery between AI agents, with built-in understanding, negotiation, and adaptation. AINP Phase 0.1 provides: - Wire format specification (JSON-LD + CBOR) - Message envelope structure with cryptographic signatures - Intent schemas for common agent interactions - Semantic address format with Decentralized Identifiers (DIDs) - Negotiation protocol for multi-agent consensus - Discovery and routing mechanisms

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Definitions Agent: An autonomous software entity capable of semantic understanding and intent exchange Intent: A semantic representation of an agent's goal, including embeddings and structured semantics Semantic Address: An identity-based address using DIDs and capability descriptors Negotiation: Multi-round protocol for establishing consensus on resources, terms, and capabilities Capability: A semantic description of what an agent can do, including natural language and embeddings Trust Vector: Multi-dimensional reputation score tracking reliability, honesty, competence, and timeliness

Architecture Overview AINP consists of four layers: +-----------------------------+ | Intent Layer | Semantic exchange (intents) +-----------------------------+ | Negotiation Layer | Multi-agent consensus +-----------------------------+ | Routing Layer | Semantic routing +-----------------------------+ | Substrate Layer | Physical transport (TCP/IP, etc.) +-----------------------------+ Phase 0.1 runs as an overlay network on TCP/IP with WebSocket or HTTP/3 transport.

Wire Format

Encoding AINP messages MUST support both: - JSON-LD: Human-readable, linked data format with @context for semantic interoperability - CBOR: Binary encoding () for efficient transmission Implementations SHOULD negotiate encoding during handshake. JSON-LD is the default for Phase 0.1.

Message Envelope All AINP messages MUST be wrapped in an envelope structure: json { "version": "0.1.0", "msg_type": "INTENT", "id": "550e8400-e29b-41d4-a716-446655440000", "timestamp": 1728259400000, "ttl": 30000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...", "to_did": "did:key:z6Mk...", "schema": "https://ainp.dev/schemas/intents/request-meeting/v1", "qos": { "urgency": 0.7, "importance": 0.8, "novelty": 0.1, "ethicalWeight": 0.5, "bid": 5 }, "payload": { ... }, "sig": "base64signature..." }

Envelope Fields

• version (string, REQUIRED): Protocol version, MUST be "0.1.0"
• msg_type (string, REQUIRED): Message type (see )
• id (string, REQUIRED): UUID v4 for message identification
• timestamp (number, REQUIRED): Unix epoch milliseconds
• ttl (number, REQUIRED): Time-to-live in milliseconds
• trace_id (string, REQUIRED): Distributed tracing UUID for thread tracking
• from_did (string, REQUIRED): Sender DID ()
• to_did (string, OPTIONAL): Recipient DID (for direct addressing)
• to_query (object, OPTIONAL): Semantic query (alternative to to_did, see )
• schema (string, REQUIRED): JSON-LD context URI
• qos (object, REQUIRED): Quality of Service parameters (see )
• payload (object, OPTIONAL): Application payload (intent, negotiation, etc.)
• sig (string, REQUIRED): Ed25519 signature in base64 encoding

Message Types AINP defines the following message types:

• ADVERTISE: Publish capabilities to discovery index
• DISCOVER: Query for agents by capability
• DISCOVER_RESULT: Discovery results
• NEGOTIATE: Multi-round negotiation
• INTENT: Send intent payload
• RESULT: Response with optional proof
• ERROR: Error response

Quality of Service Parameters QoS parameters enable priority-based routing and resource allocation: json { "urgency": 0.7, // 0-1, time sensitivity "importance": 0.8, // 0-1, impact magnitude "novelty": 0.1, // 0-1, information gain "ethicalWeight": 0.5, // 0-1, moral importance "bid": 5 // Token amount or credits (non-negative) } Priority Calculation: Implementations SHOULD calculate message priority as: priority = (urgency * w_urgency) + (importance * w_importance) + (novelty * w_novelty) + (ethicalWeight * w_ethical) adjusted_priority = priority + 0.5 * tanh(bid / bid_scale) Where bid_scale is node-configurable (RECOMMENDED default: 10 credits). Default Weights: - w_urgency = 0.3 - w_importance = 0.3 - w_novelty = 0.2 - w_ethical = 0.2

Capability Query For semantic discovery, agents use capability queries: json { "description": "Find agents who can schedule meetings", "embedding": "base64-encoded Float32Array[1536]", "tags": ["scheduling", "calendar"], "min_trust": 0.7, "max_latency_ms": 5000, "max_cost": 10 }

Signature Format Messages MUST be signed using Ed25519 () with detached signatures in base64 encoding. Signing Process: 1. Serialize envelope fields (excluding sig) to canonical JSON () 2. Compute SHA-256 hash of canonical JSON 3. Sign hash with Ed25519 private key 4. Encode signature as base64 5. Add sig field to envelope Verification Process: 1. Extract sig field 2. Remove sig from envelope 3. Serialize remaining fields to canonical JSON () 4. Compute SHA-256 hash 5. Verify signature using Ed25519 public key from from_did

Semantic Addresses

Decentralized Identifiers (DIDs) Agents MUST have a DID conforming to . Supported DID Methods (Phase 0.1): - did:key: - Self-certified cryptographic keys - did:web: - Web-based identifiers

Semantic Address Structure json { "did": "did:key:z6Mk...", "capabilities": [ { "description": "Schedule meetings with calendar integration", "embedding": { "b64": "base64-encoded float32 array", "dim": 1536, "dtype": "f32", "model": "openai:text-embedding-3-small" }, "tags": ["scheduling", "calendar"], "version": "1.0.0", "evidence": "https://credentials.example.com/vc/scheduling" } ], "trust": { "score": 0.85, "dimensions": { "reliability": 0.9, "honesty": 0.85, "competence": 0.8, "timeliness": 0.85 }, "decay_rate": 0.977, "last_updated": 1728259200000 }, "credentials": ["https://credentials.example.com/vc/scheduling"] }

Intent Schemas AINP defines six core intent types for Phase 0.1. All intents MUST include: - JSON-LD @context for semantic interoperability - Embedding (Embedding object; base64 Float32Array inside b64) - Budget constraints - Semantic payload

REQUEST_MEETING Intent Schema URI: https://ainp.dev/schemas/intents/request-meeting/v1 json { "@context": "https://ainp.dev/contexts/meeting/v1", "@type": "RequestMeeting", "version": "1.0.0", "embedding": { "b64": "base64-encoded Float32Array", "dim": 1536, "dtype": "f32", "model": "openai:text-embedding-3-small" }, "semantics": { "participants": ["did:key:..."], "duration_minutes": 30, "preferred_times": ["2025-10-07T14:00:00Z"], "location": "virtual", "constraints": { "timezone": "America/Los_Angeles", "max_latency_ms": 5000, "min_notice_hours": 24 } }, "budget": { "max_credits": 10, "max_rounds": 5, "timeout_ms": 30000 } }

APPROVAL_REQUEST Intent Schema URI: https://ainp.dev/schemas/intents/approval-request/v1 json { "@context": "https://ainp.dev/contexts/approval/v1", "@type": "ApprovalRequest", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "request_type": "purchase", "description": "Purchase office supplies", "amount": 500, "currency": "USD", "justification": "Quarterly restock", "deadline": "2025-10-10T00:00:00Z", "approvers": ["did:key:..."], "threshold": 1, "constraints": { "requires_attestation": true, "max_latency_ms": 5000 } }, "budget": { "max_credits": 10, "max_rounds": 5, "timeout_ms": 30000 } }

SUBMIT_INFO Intent Schema URI: https://ainp.dev/schemas/intents/submit-info/v1 json { "@context": "https://ainp.dev/contexts/submit-info/v1", "@type": "SubmitInfo", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "data_type": "form", "payload": { "field1": "value1" }, "schema_ref": "https://example.com/schema.json", "privacy_level": "encrypted", "retention_policy": { "duration_days": 90, "delete_after": true }, "constraints": { "requires_acknowledgment": true, "max_latency_ms": 5000 } }, "budget": { "max_credits": 5, "max_rounds": 3, "timeout_ms": 15000 } }

INVOICE Intent Schema URI: https://ainp.dev/schemas/intents/invoice/v1 json { "@context": "https://ainp.dev/contexts/invoice/v1", "@type": "Invoice", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "invoice_id": "INV-2025-001", "from": "did:key:...", "to": "did:key:...", "amount": "1000.00", "currency": "USD", "line_items": [ { "description": "Service fee", "quantity": 1, "unit_price": "1000.00", "total": "1000.00" } ], "due_date": "2025-11-01T00:00:00Z", "payment_methods": ["crypto", "wire"], "constraints": { "requires_escrow": true, "max_latency_ms": 10000 } }, "budget": { "max_credits": 5, "max_rounds": 3, "timeout_ms": 30000 } }

FREEFORM_NOTE Intent Schema URI: https://ainp.dev/schemas/intents/freeform-note/v1 json { "@context": "https://ainp.dev/contexts/freeform/v1", "@type": "FreeformNote", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "subject": "Meeting notes", "body": "Discussion summary...", "format": "markdown", "attachments": [ { "url": "https://example.com/doc.pdf", "mime_type": "application/pdf", "size_bytes": 102400, "hash": "sha256:abc123..." } ], "thread_id": "thread-123", "in_reply_to": "msg-456", "constraints": { "max_latency_ms": 5000 } }, "budget": { "max_credits": 1, "max_rounds": 1, "timeout_ms": 10000 } }

REQUEST_SERVICE Intent Schema URI: https://ainp.dev/schemas/intents/request-service/v1 json { "@context": "https://ainp.dev/contexts/service/v1", "@type": "RequestService", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "service_type": "plumbing.leak.fix", "geo": { "lat": 37.7749, "lon": -122.4194, "radiusKm": 10, "zip": "94102" }, "time_window": { "earliest": "2025-10-08T09:00:00Z", "latest": "2025-10-08T17:00:00Z" }, "constraints": { "eco": true, "access_notes": "Ring doorbell", "evidence_required": ["photo_before_after"] }, "details": { "urgency": "high", "description": "Kitchen sink leak" } }, "budget": { "max_credits": 20, "max_total": 200, "escrow_required": true, "max_rounds": 10, "timeout_ms": 60000 } }

Negotiation Protocol

Negotiation Flow Negotiation MUST follow this state machine: START -> OFFER -> COUNTER <-> COUNTER -> ACCEPT | | ABORT TIMEOUT | | REJECT REJECT

Negotiation Message Structure json { "negotiation_id": "uuid", "round": 1, "phase": "OFFER", "proposal": { "price": 100, "latency_ms": 500, "confidence": 0.9, "privacy": "encrypted", "terms": {} }, "constraints": { "max_rounds": 10, "timeout_per_round_ms": 5000, "convergence_threshold": 0.9 } } Negotiation Phases: - OFFER: Initial offer - COUNTER: Counter-offer - ACCEPT: Accept proposal - REJECT: Reject and end - ABORT: Abort negotiation - TIMEOUT: Timeout occurred

Negotiation Convergence Implementations MAY auto-accept proposals when convergence threshold is met: ``` convergence_score = 1 - (abs(offer.price - counter.price) / max(offer.price, counter.price)) if convergence_score >= convergence_threshold: auto_accept() ```

Timeout Behavior

• Per-round timeout: If no response within timeout_per_round_ms, sender MAY send TIMEOUT message
• Overall timeout: If negotiation exceeds max_rounds * timeout_per_round_ms, MUST terminate with TIMEOUT

Multi-Party Negotiation For intents involving multiple agents (e.g., scheduling a meeting with 5 participants, multi-signature approvals), negotiation MUST support group consensus mechanisms. Group Proposal Structure: json { "negotiation_id": "multi-abc123", "phase": "OFFER", "proposal": { "participants": ["did:key:agent-a", "did:key:agent-b", "did:key:agent-c"], "voting_mechanism": "majority", "convergence_threshold": 0.75, "terms": { "preferred_times": ["2025-10-07T14:00:00Z", "2025-10-07T15:00:00Z"], "duration_minutes": 30 } } } Voting Mechanisms: 1. Unanimous: All agents must ACCEPT (default for high-stakes) 2. Majority: More than 50% must ACCEPT 3. Weighted: Votes weighted by trust scores Multi-Party Flow: 1. Fan-out: Send NEGOTIATE(OFFER) to all participants 2. Collection: Each agent responds with individual proposal 3. Aggregation: Broker aggregates and computes consensus score 4. Convergence Check: Compare score to threshold 5. Auto-accept if converged, else synthesize counter-proposal and repeat 6. Termination: ABORT after max_rounds or timeout if no consensus

Protocol Handshake Sequence

Five-Step Handshake

1. ADVERTISE: Agent publishes capabilities to discovery index
2. DISCOVER: Agent queries for matching capabilities
3. NEGOTIATE: Agents negotiate terms (OFFER → COUNTER → ACCEPT)
4. INTENT: Agent sends intent after successful negotiation
5. RESULT: Recipient responds with result

ADVERTISE Phase Agent publishes capabilities to discovery index: json { "version": "0.1.0", "msg_type": "ADVERTISE", "id": "550e8400-e29b-41d4-a716-446655440000", "timestamp": 1728259200000, "ttl": 86400000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...", "schema": "https://ainp.dev/schemas/advertise/v1", "qos": { "urgency": 0.1, "importance": 0.5, "novelty": 0.3, "ethicalWeight": 0.5, "bid": 0 }, "sig": "base64signature...", "payload": { "capabilities": [ { "description": "Schedule meetings with calendar integration", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "tags": ["scheduling", "calendar"], "version": "1.0.0", "evidence": "https://credentials.example.com/vc/scheduling" } ], "trust": { "score": 0.85, "dimensions": { "reliability": 0.9, "honesty": 0.85, "competence": 0.8, "timeliness": 0.85 }, "decay_rate": 0.977, "last_updated": 1728259200000 }, "credentials": ["https://credentials.example.com/vc/scheduling"] } }

DISCOVER Phase Agent queries for capabilities: json { "version": "0.1.0", "msg_type": "DISCOVER", "id": "660e8400-e29b-41d4-a716-446655440001", "timestamp": 1728259300000, "ttl": 10000, "trace_id": "trace-def456", "from_did": "did:key:z6Mk...", "to_query": { "description": "Find agents who can schedule meetings", "embedding": "base64...", "tags": ["scheduling", "calendar"], "min_trust": 0.7, "max_latency_ms": 5000, "max_cost": 10 }, "schema": "https://ainp.dev/schemas/discover/v1", "qos": { "urgency": 0.5, "importance": 0.7, "novelty": 0.2, "ethicalWeight": 0.5, "bid": 1 }, "sig": "base64signature..." } Discovery index responds with DISCOVER_RESULT containing matching agents with similarity scores, trust ratings, and estimated latency.

ERROR Phase On error, agent MUST respond with ERROR message: json { "msg_type": "ERROR", "error_code": "TIMEOUT", "error_message": "Negotiation timed out", "intent_id": "770e8400-e29b-41d4-a716-446655440002", "retry_after_ms": 5000 } Standard Error Codes: - INVALID_SIGNATURE - UNAUTHORIZED - UNSUPPORTED_SCHEMA - TIMEOUT - RATE_LIMIT_EXCEEDED - INSUFFICIENT_CREDITS - NEGOTIATION_FAILED - ESCROW_REQUIRED - EVIDENCE_INSUFFICIENT - DUPLICATE_INTENT - AGENT_OFFLINE - INTERNAL_ERROR

Offline Intent Queueing When recipient agent is offline or unreachable, broker MAY queue intents for later delivery instead of immediately failing. Queue Behavior: - TTL enforcement: Intent expires after ttl milliseconds from original timestamp - Broker SHOULD send ERROR to sender immediately: error_code: "AGENT_OFFLINE" - ERROR response SHOULD include retry_after_ms field - Broker MUST NOT queue intents indefinitely (maximum queue time = ttl) Queue Delivery Protocol: 1. Agent Offline Detection: Broker detects agent offline 2. Queue Intent: Insert into queue with expires_at = timestamp + ttl 3. Send ERROR: Notify sender with AGENT_OFFLINE and retry_after_ms 4. Agent Reconnect: When agent comes online, broker delivers queued intents in priority order 5. Delivery Ordering: Process queue as FIFO within each priority level 6. Retry Logic: If delivery fails, increment retry_count and retry after exponential backoff 7. Expiration Cleanup: Periodically purge expired intents

Security Considerations

Authentication

• All messages MUST be signed with Ed25519
• Signatures MUST be verifiable using public key from from_did
• Unsigned messages MUST be rejected

Identity

• Agents MUST have a valid
• DIDs MUST be resolvable to DID documents containing public keys

Rate Limiting Implementations MUST enforce rate limits: - Default: 100 intents per minute per agent - Burst: Up to 200 intents in 10-second window - Discovery queries: 10 per minute per agent

Replay Protection Recipients MUST reject duplicate messages with the same (from_did, id) seen within ttl + 60000ms.

DoS Protection Implementations MUST: - Validate message signatures before processing - Enforce TTL (drop expired messages) - Limit negotiation rounds (max 10) - Reject messages exceeding 1MB payload size - Require attachments by reference (URLs) rather than inlining large binaries

Replay Protection and Delivery Semantics

• Recipients MUST reject duplicate messages with the same (from_did, id) seen within ttl + 60000ms
• Implementations MUST allow a clock skew of +/-60000ms when validating timestamp
• At-least-once delivery is RECOMMENDED; senders MUST use UUID v4 ids and recipients MUST make intent handling idempotent with respect to id

Capability Attestations

• Agents advertising capabilities SHOULD provide Verifiable Credentials (VCs)
• VCs MUST conform to
• Discovery indices MAY reject advertisements without VCs

Timeouts

• Intent delivery: 60 seconds default TTL
• Negotiation per round: 5 seconds default
• Overall negotiation: 30 seconds default
• Discovery query: 10 seconds default

Outlier Detection Discovery indices SHOULD flag agents with: - Trust score < 0.3 - Capability embeddings >3 standard deviations from cluster mean (potential false advertising) - Success rate < 50% over last 100 intents

Discovery Scalability Phase 0.1 Architecture: Centralized discovery index using PostgreSQL with pgvector extension for semantic search. Vector Indexing: Discovery indices SHOULD use Approximate Nearest Neighbor (ANN) indexing for efficient semantic search at scale. Recommended Algorithm: HNSW (Hierarchical Navigable Small World) - Structure: Multi-layer graph with hierarchical routing - Parameters: m = 16, ef_construction = 64, ef_search = 40 - Distance Metric: Cosine similarity - Performance: ~10ms search latency for 1M agents, ~99% recall Scaling Strategies: 1. Vertical Scaling: Increase HNSW parameters, use NVMe SSDs, scale PostgreSQL memory 2. Horizontal Scaling: Read replicas, connection pooling (PgBouncer), Redis caching 3. Partitioning: Capability sharding, tag-based routing, geographic partitioning 4. Query Optimization: Pre-filtering, batch queries, approximate search Performance Benchmarks (Phase 0.1 targets):

Agent Count	Index Size	Build Time	Query Latency (p95)	Recall@10
1K	2 MB	5s	2ms	99.5%
10K	20 MB	45s	5ms	99.2%
100K	200 MB	8 min	12ms	98.8%
1M	2 GB	90 min	25ms	98.0%

Lite Mode for Resource-Constrained Agents For lightweight agents (e.g., IoT devices, mobile, embedded systems), implementations MAY use a minimal envelope to reduce payload size and processing overhead. Required Fields: version, msg_type, id, timestamp, from_did, to_did, sig Optional Fields (MAY be omitted): - ttl (default: 60000ms) - trace_id (no distributed tracing) - to_query (explicit addressing only) - capabilities_ref (no VC attestations) - attestations (trust by DID only) - qos (default: all 0.5, bid 0) Lite Mode Constraints: - Lite mode SHOULD NOT be used for high-stakes intents - Agents using lite mode MUST still provide valid Ed25519 signatures - Discovery indices MAY reject lite mode advertisements - Brokers MAY apply lower trust scores to lite mode agents by default

CBOR Encoding (Optional) For efficiency, implementations MAY use CBOR () encoding: Key Map (v0.1): - 1: version - 2: msg_type - 3: id - 4: timestamp - 5: ttl - 6: trace_id - 7: from_did - 8: to_did - 9: to_query - 10: schema - 11: qos - 12: capabilities_ref - 13: attestations - 14: payload - 15: sig CBOR encoding SHOULD be negotiated during ADVERTISE or DISCOVER phase.

Extensibility

Custom Intent Types Agents MAY define custom intent types beyond the core set. Custom intents MUST: - Include @context with unique URI - Include version field - Include embedding field - Include budget constraints - Register schema URI in public registry (future)

Custom Negotiation Terms Proposal.terms field allows extensible negotiation parameters. Common extensions: - privacy_guarantees: ZK proof requirements - sla_guarantees: Service level agreements - data_retention: Data retention policies

Versioning AINP uses semantic versioning. Breaking changes MUST increment major version. Phase 0.1 is backwards-compatible within 0.x series.

Lite Profile (Trusted Networks) In trusted or closed-network deployments, the following simplifications are PERMITTED: - Omit capabilities_ref and attestations if peers are pre-authorized - Prefer JSON-LD for small payloads; negotiate CBOR for payloads > 4KB - Allow to_query-only routing within a single administrative domain Nodes MUST still sign messages, enforce TTLs, and implement replay protection.

Success Metrics

Route Success Rate route_success_rate = (intents_delivered_correctly / total_intents_sent) × 100% Target (Phase 0.1): >=95%

Latency (p95) 95th percentile time from INTENT sent to RESULT received. Target (Phase 0.1): <=2000ms

Negotiation Completion Rate negotiation_completion_rate = (negotiations_accepted / total_negotiations) * 100 Target (Phase 0.1): >=80%

False Route Rate false_route_rate = (intents_misrouted / total_intents_sent) * 100 Target (Phase 0.1): <=5%

Abuse Resilience Detection rate of: - DoS attacks (>1000 requests/min from single agent) - Sybil attacks (multiple DIDs from same source) - False capability advertising (capability mismatch >0.5 cosine distance) Target (Phase 0.1): >=90% detection rate

IANA Considerations This document has no IANA actions.

References Normative References 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. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. W3C W3C Informative References 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 using deterministic property sorting.

Author's Address Servesys Labs

contact@servsys.com