Agent Directory Service

3.1. OASF Attributes

The protocol uses OASF to define attribute taxonomies that describe agent capabilities. These attributes fall into categories such as:¶

• Skills and competencies¶

• Domain knowledge¶

• Interaction patterns¶

• Security propertion Attributes are organized hierarchically and can be extended to support new capabilities.¶

3.2. Network

The Directory network MUST use a cryptographically strong identity. A "dir node" is a program that can publish, find, and replicate objects across the network. Its identity is defined by a private key.¶

The node MAY be allowed to work in one of the following modes of operation: - client -- The node can interact with the public network, but it does not expose any interfaces to it. The interfaces can be exposed only to the local network. - swarm -- The node exposes all its interfaces to a subset of nodes on the network. - server -- The node exposes all its interfaces to the public network.¶

All interfaces and operations on the network MUST be provided and performed by the node itself.¶

3.3. DHT-based Directory

Agent directory records are stored in a DHT with the following properties:¶

• Records are indexed by attribute combinations¶

• Support for partial and wildcard attribute matching¶

• Built-in replication and fault tolerance¶

• Decentralized operation with no single point of failure¶

        +------+
        | Node |
        +------+
         /    \
        /      \
  +--------+  +--------+
  | Agents |  | Skills |
  +--------+  +--------+
       |           |
       |           |
  +---------+  +-------------+
  |  Alice  |  |  TextSummary|
  +---------+  +-------------+
       |           |
       |           |
  +-------------+  +-------------+
  | /dir/CID-   |  | /dir/CID-   |
  | Alice-v1    |  | Bob-v1      |
  +-------------+  +-------------+
       |
       |
  +-------------+
  |  Bob        |
  +-------------+
       |
       |
  +-------------+
  | /dir/CID-   |
  | Bob-v2      |
  +-------------+

3.4. Routing

Implementations MUST expose a routing interface that allows the announcement and discovery of agent records across the network. The routing layer serves two important purposes:¶

• peer routing -- to find and connect with other nodes on the network¶

• content routing -- to find the data published across the network¶

The routing system can be satisfied with various kinds of implementations. The current implementation of the Directory uses DHT (distributed hash table) for routing. See more in the libp2p specs. The interface currently used across the system is defined in api/routing.¶

4.1. Record Signatures

All agent directory records MUST be digitally signed by the producing agent. The signature covers:¶

• The complete set of OASF attributes¶

• The agent's capabilities description¶

• Any additional metadata¶

Signatures enable consumers to verify the authenticity and integrity of records independent of their location in the DHT.¶

4.2. Location Independence

Agent directory records are location-independent - their trust is derived from cryptographic signatures rather than network location. This means:¶

• Records can be cached and replicated across the DHT¶

• Consumers can verify records regardless of the serving node¶

• Man-in-the-middle attacks are prevented through signature verification¶

4.3. Key Management

Agents MUST generate and maintain cryptographic key pairs following these requirements:¶

• Use of asymmetric cryptography (e.g., Ed25519)¶

• Private keys MUST be properly secured by agents¶

• Public keys are distributed as part of agent records¶

• Key rotation procedures MUST be supported¶

4.4. DHT Security

The DHT implementation MUST provide:¶

• Node authentication to prevent Sybil attacks¶

• Secure routing to prevent record tampering¶

• Replication policies to ensure availability¶

• Access controls for record updates¶

4.5. Transport Security

All protocol interactions MUST use secure transport with:¶

• Mutual authentication between nodes¶

• Perfect forward secrecy¶

Implementations MUST NOT support plaintext communications.¶