Abstract

Introduction

TODO: This section needs further development and refinement.

Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY and MUST 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

The Agent Identity component is defined by the following companion specifications. This split separates the DID-method-agnostic authentication protocol from DID method definitions and method-specific validation rules.

• Agent Identity and HTTP Authentication defines DID-based identity authentication over HTTP, including DID resolution, HTTP Message Signatures, Digest Fields, replay protection, access tokens, and the authentication/authorization boundary.
• DID Method Binding Profiles defines how did:wba, did:web, and did:webvh participate in the common Agent Identity protocol.
• did:wba DID Method Specification defines creation, resolution, update, deactivation, path-to-key binding, and DID Document proof processing for did:wba.

Agent Description

The core objective of the Agent Description module is to establish standardized agent description mechanisms, enabling agents to clearly publish their basic information, service capabilities, and interaction interfaces to other agents in the network, thereby achieving efficient capability discovery and collaboration matching:

• Basic Information Description: Agents can standardize the description of their name, version, affiliated organization, service scope, and other fundamental metadata.
• Capability Declaration: Agents can clearly declare the functions they can provide, service types, processing capabilities, and areas of expertise.
• Interaction Protocols: Agents can declare the communication protocols, message formats, and interaction modes they support.

Therefore, agent description protocols must possess good extensibility and semantic clarity, ensuring that different agents can accurately understand each other's capability boundaries.

The following example demonstrates an agent description document:

{
  "@context": {
    "@vocab": "https://schema.org/",
    "ad": "https://example.com/ad#"
  },
  "@type": "ad:AgentDescription",
  "name": "SmartAssistant",
  "did": "did:web:agent.example.com:agents:alice",
  "description": "An intelligent agent providing natural language processing capabilities",
  "version": "1.0.0",
  "interfaces": [
    {
      "@type": "ad:NaturalLanguageInterface",
      "protocol": "YAML",
      "url": "https://agent.example.com/alice/nl-interface.yaml"
    }
  ]
}

1. Core Concepts

This specification defines two core concepts for agent description: Information and Interface. These concepts provide a standardized framework for agents to publish information externally, ensuring that agents can effectively discover, understand, and interact with each other.

1.1 Information

Information represents data resources that an agent provides to external entities. These resources can be structured or unstructured data used to describe the agent's capabilities, status, products, or services.

Information resources include but are not limited to the following types:

• Structured data: JSON documents, XML files, database query results
• Media resources: Images, videos, audio files and their associated metadata
• Descriptive documents: Product specifications, service descriptions, usage guides
• Status information: Agent current status, availability information, configuration parameters

Information has the following key characteristics:

• Describability: Each Information resource must contain sufficient metadata to enable other agents to understand the resource's type, purpose, and access methods
• Discoverability: Information resources are exposed to external entities through unified description mechanisms, supporting automated discovery and indexing processes

1.2 Interface

Interface defines standardized entry points for agents to engage in dynamic interactions with external entities. Interfaces provide callable representations of agent functionality, allowing other agents or systems to interact with them programmatically.

Interfaces are divided into the following two main categories:

1.2.1 Natural Language Interface

Natural language interfaces provide agents with human language-based interaction capabilities. These interfaces allow the use of natural language queries and commands to access agent functionality.

Characteristics of natural language interfaces include:

• Language flexibility: Support for various natural language expressions, able to understand semantic variations and contextual information
• Personalized interaction: Ability to provide customized responses based on interaction history and user preferences
• Open-ended task processing: Suitable for task scenarios requiring creative thinking or complex reasoning
• Universality: It is recommended that all specification-compliant agents implement at least one natural language interface to ensure basic interoperability

1.2.2 Structured Interface

Structured interfaces provide programmatic interaction methods based on predefined protocols and data formats. These interfaces follow standardized API design principles, ensuring predictability and efficiency.

Characteristics of structured interfaces include:

• Protocol standardization: Support for widely adopted protocol standards such as OpenAPI, JSON-RPC, GraphQL, WebRTC, etc.
• Type safety: Ensuring interaction correctness through explicit data type definitions and validation mechanisms
• Performance optimization: Compared to natural language interfaces, structured interfaces typically have lower latency and higher throughput
• Functional specialization: Each structured interface can be optimized for specific functional domains

1.3 Interface Selection and Priority

Agents implementing the protocol should follow the following priority and selection strategies when choosing interaction interfaces:

1. Structured interface priority principle: When there are structured interfaces that meet functional requirements, they should be prioritized for interaction to achieve optimal performance and reliability
2. Functional completeness assessment: Before selecting an interface, it is necessary to evaluate whether the target interface can fully meet the functional requirements of the current task
3. Fallback mechanism: When structured interfaces cannot meet complex or non-standardized requirements, fallback to natural language interfaces is acceptable
4. Context-aware selection: Interface selection should consider task complexity, real-time requirements, and the degree of personalization needed

2. Interaction Model

The protocol adopts a linked data-based interaction model that allows agents to organize their Information and Interfaces into a navigable data network through Uniform Resource Locators (URLs). This approach is similar to the hyperlink structure of the World Wide Web, enabling agents to construct their public data into a data network, where all data networks can be connected into an AI-accessible data network.

2.1 Networked Data Organization

The core principle of the interaction model is based on the following architectural design:

2.1.1 URL Link Network

Agents must use URLs as a unified addressing mechanism to organize their Information and Interface resources. Each URL points to a specific resource or interface definition, forming a traversable link graph. This design ensures:

• Global uniqueness: Each resource has a unique network address
• Dereferencability: URLs can be directly used to access corresponding resources
• Link integrity: Relationships between resources are explicitly expressed through URL links

2.1.2 Entry Point Mechanism

It is recommended that each agent provide a primary entry point, typically manifested as an Agent Description Document. This document functions similarly to a website's homepage and contains:

• Basic metadata and identification information of the agent
• Links and descriptions of all available Information resources
• Links and specification references for all available Interfaces
• Necessary access control and security policy information

2.2 Interaction Process

The interaction process between agents is similar to how web crawlers work, starting from an entry point and proceeding with recursive navigation. The client agent first obtains the target agent's description document URL, retrieves the document through an HTTP request, and then parses the Information resource links and Interface definition links contained within. Based on task requirements, the client agent selectively accesses relevant URL links. If the retrieved resources contain further links, it continues recursive retrieval until sufficient information needed to complete the task is collected.

While gathering information, the client agent integrates this data in its local environment, formulates execution strategies, and selects appropriate Interfaces for invocation. The entire process emphasizes local decision processing, with sensitive information not passed to third parties but analyzed and processed locally at the client. Finally, the client agent executes specific operations through discovered Interfaces, processes return results, and completes tasks. This model ensures both privacy security and flexible on-demand information retrieval.

2.3 Architectural Advantages of the Interaction Model

2.3.1 Compatibility with Existing Web Infrastructure

Fully leverages existing web technology stacks and infrastructure:

• Protocol reuse: Based on HTTP/HTTPS protocols, compatible with existing network equipment and middleware
• Caching mechanisms: Supports standard web caching strategies, improving performance and scalability
• Search engine friendly: Information resources can be indexed by traditional search engines, enhancing agent discoverability

2.3.2 Privacy Protection and Data Sovereignty

The local decision-making model provides important privacy protection advantages:

• Data localization: Sensitive information is processed locally, reducing the risk of data leakage
• Selective sharing: Client agents can precisely control the scope of information shared with other agents

Note: This section is being continuously refined. We sincerely invite community members to contribute and jointly improve the technical specifications and implementation solutions for agent description standards.

Agent Discovery

The core objective of the Agent Discovery module is to establish efficient agent discovery mechanisms, enabling agents to be conveniently found and accessed by other agents in different network environments, thereby building dynamic and open agent collaboration networks:

• Internet Discovery: Agents can register their services across the global internet and be found by other agents through standardized discovery protocols.
• Local Network Discovery: Agents can automatically broadcast and discover each other within local area networks, supporting agent collaboration within enterprises and private networks.

This specification defines the Agent Discovery Service Protocol (ADSP), a standardized protocol for discovering agents. Based on the JSON-LD format, it provides two discovery mechanisms: active discovery and passive discovery, aimed at enabling agents to be effectively discovered and accessed by other agents or search engines in the network.

The core elements of the protocol include:

1. Using JSON-LD as the foundational data format, supporting linked data and semantic web features
2. Defining an active discovery mechanism, using .well-known URI paths as agent discovery entry points
3. Providing a passive discovery mechanism, allowing agents to submit their descriptions to search services
4. Supporting pagination and linking of agent descriptions, facilitating the management of large numbers of agent information

https://{domain}/.well-known/agent-descriptions

{
  "@context": {
    "@vocab": "https://schema.org/",
    "did": "https://w3id.org/did#",
    "ad": "https://example.com/ns/agent-description#"
  },
  "@type": "CollectionPage",
  "url": "https://example.com/.well-known/agent-descriptions",
  "items": [
    {
      "@type": "ad:AgentDescription",
      "name": "Smart Assistant",
      "@id": "https://example.com/agents/smartassistant/ad.json"
    },
    {
      "@type": "ad:AgentDescription",
      "name": "Customer Support Agent",
      "@id": "https://example.com/agents/customersupport/ad.json"
    }
  ],
  "next": "https://example.com/.well-known/agent-descriptions?page=2"
}

sequenceDiagram
    participant Agent as Agent
    participant Search as Search Service Agent
    
    Agent->>Search: Get agent description document
    Search-->>Agent: Return description document (including registration API info)
    Note over Agent: Parse registration API from description document
    Agent->>Search: Send registration request (including own description URL)
    Note over Search: Verify request
    Search-->>Agent: Confirm registration
    Note over Search: Crawl agent description document and index

Note: This section is being continuously refined. We sincerely invite community members to contribute and jointly improve the technical specifications and implementation solutions for agent discovery standards.

Security Considerations

The core objective of the Security Considerations module is to ensure the security of agents during interactions, establish multi-layered security protection systems, and maximize defense against various security threats and malicious attacks:

• Authentication and Authorization: Ensure that agents participating in interactions have authentic and trustworthy identities, establish fine-grained permission control mechanisms, and prevent identity forgery and unauthorized access.
• Communication Encryption: Apply end-to-end encryption to all communication data between agents, ensuring that data transmission is not subject to eavesdropping, tampering, or replay attacks.
• Data Integrity Protection: Use technologies such as digital signatures and message authentication codes to ensure the integrity and authenticity of interaction data, preventing malicious data modification.

Therefore, agent security protocols must adopt defense-in-depth strategies, establishing corresponding security protection measures at the network layer, application layer, and data layer.

Note: This section is being continuously refined. We sincerely invite community members to contribute and jointly improve the technical specifications and implementation solutions for agent security standards.

Privacy Considerations

The core objective of the Privacy Considerations module is to maximize the protection of personal privacy during agent interactions, ensuring that users' sensitive information is not improperly transmitted or leaked between agents, and establishing privacy-first interaction mechanisms:

• Data Minimization Principle: Agents only transmit the minimum information necessary to complete tasks during interactions, avoiding unnecessary personal data sharing.
• Data Desensitization and Anonymization: When transmitting information between agents, personal privacy data undergoes desensitization, anonymization, or pseudonymization processing to protect users' real identities.
• User Authorization Control: Establish clear user authorization mechanisms, ensuring that any cross-agent transmission of personal data requires explicit user consent and authorization.

Therefore, agent privacy protocols must make privacy protection a fundamental design principle, ensuring that technological progress does not come at the expense of user privacy.

Note: This section is being continuously refined. We sincerely invite community members to contribute and jointly improve the technical specifications and implementation solutions for agent privacy protection standards.

References

1. [RFC2119] Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
2. [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174