Protocol Registry
Understand how MCP-I registries manage service discovery, credential linkage, and delegation chain resolution
Protocol Registry
Key Takeaways
- Tracks delegation relationships and credential linkage for resolution and revocation - Serves as a trust anchor across services and verifiers - Enables indexed discovery of delegation chains and entity relationships - Supports central or federated implementation patterns
What Is the Protocol Registry?
In MCP-I, the protocol registry acts as a central resolver and index for:
- Issued credentials (VCs, DelegationCredentials)
- Delegation chains
- Trust relationships
- Service discovery
It enables verifiers and services to validate where a credential was issued, who is trusted, and which chains exist between entities.
Registry Types
| Registry | Purpose |
|---|---|
| Delegation Registry | Stores, indexes, and resolves chained delegation relationships |
| Credential Registry | Associates delegation with verifiable credentials |
| Service Registry | Tracks participating MCP-I services and their capabilities |
| Trust Registry | Maintains allow/block/score-based trust data for DIDs or domains |
Delegation Chain Resolution
Registries support walking a delegation chain, resolving each link by:
- Subject → Issuer relationships
- Credential status (revoked, expired)
- Scope and timestamp
{
"issuer": "did:web:user.vouched.dev",
"subject": "did:web:agent.vouched.dev",
"credentialId": "urn:vc:abc123",
"scope": ["read:email"],
"created": "2025-01-01T00:00:00Z"
}
Credential ↔ Delegation Linking
Every DelegationCredential may be:
- Linked forward to the delegation registry
- Linked backward from a credential to its original issuer or chain
This ensures that even stateless agents can be verified via registry resolution.
Example SDK APIs
await kyaOsClient.registry.delegation.resolveChain({
subjectDid: "did:web:agent.vouched.dev",
});
await kyaOsClient.registry.trust.lookup("did:web:user.vouched.dev");
Privacy and Query Filters
Registries may be scoped or filtered:
- By
scopeor action - By issuer/subject DID
- By revocation status
- By delegation depth or TTL
Access controls may apply (e.g. public vs. private graph query access).
Deployment Patterns
| Pattern | Description |
|---|---|
| Centralized | Single internal registry used by all components |
| Federated | Each service maintains a syncable registry |
| Public | Shared registry, e.g. knowthat.ai |
| Embedded | Registry lives inside Credential Service or Core orchestrator |