OASF to handle schemas for other AGNTCY/external projects

[ramizpolic]

Context

Let there be a service Rating Service which defines its schema. The service is implemented inside Directory (but can similarly be implemented anywhere else). The service works by associating multiple UserRating with Record. The flow can be described in the following way:

• Schema UserRating: {record_cid, user_id, created_at} represents +1 like by user (how we define users is irrelevant)
• Service enables APIs such as POST /likes/{record_cid}, GET /likes/{record_cid}, GET /top_likes
• Service works by creating a referrer object that is attached to a record via OCI Referrer API in the directory, which we can sync across the network and confirm

The question: Where should such a schema live?
We have the same problem with Record Signatures, as this schema is not tied to the actual Record, but rather the signing and verification service.

What is OASF to AI Agents?

A way to register schemas to describe agent capabilities. It represents a set of embeddable objects that can be used to describe different aspects of an agent.

For example:

• Observability - how an agent can be monitored
• Capabilities - what features can the agent perform
• A2A - full description of the agent-to-agent contract

What is OASF to DIR?

OASF defines different agent interfaces (aka capabilities), while Directory manages the storage, announcement, and discovery
of agents and their capabilities. In addition, Directory can also manage attachable objects (and their schemas) that require dynamic associations to agents and their capabilities.

For example:

• Signature - Manages signing schema (sigstore-based) and its data associations to Records to enable signing and verification services
• Rating - Manages rating schema (internally defined) and its data associations to Records to enable rating services

Questions

1. How (and do we need) to represent schemas in OASF for:

• Embeddable Object (static) - objects that compose an AI agent - payment contract, observability, features, etc.
• Attachable Object (dynamic) - objects that provide additional functionality outside, but for, AI agent - record signatures, ratings, etc.

2. Where should the Dir Service Schemas (such as Record Signature/Rating) be defined?

• Within OASF?
• Within Dir?
• Both?

3. Do we want to allow other services which rely on attachable objects beyond DIR to register their schemas under OASF?

This would make OASF host schemas related to an AI Agent interface composition (what we have now), plus the schemas for services (like DIR) that provide additional functionality on top of Records.
For example, semantic search service, agent payment systems, etc.

4. How do we present this data on the OASF schema server UI?

• Where is the best place in OASF to host the schemas for
  • Embeddable Object -- core schema that we have now (modules, skills, domains)
  • Attachable Object -- external schema that creates associations to core schema data
• How do we categorize the schemas?