Verifiable identity · 2 of 3
Verify first, then connect
Verana inverts "connect first, verify later". A Verifiable Service is identified by a resolvable DID, not an opaque URL. Peers trust-resolve each other, recursively to the ecosystem root, and display a Proof-of-Trust before the first interaction.
A Verifiable Service's DID Document exposes a DIDComm bootstrap endpoint and, optionally, MCP, A2A, AG-UI, website, or any other service it chooses to expose. Its credentials are published as Linked Verifiable Presentations: one identifying the service, one identifying the organization or person behind it. Anyone can verify the full chain against the public registry before saying a word to the service. The same model covers three connection types, below.
The actors
Verifiable Services and User Agents
Two kinds of software meet in every connection: Verifiable Services (the Actors: services, AI agents, connected objects) and the Verifiable User Agents people operate. Both prove who stands behind them before anything else happens.
Verifiable Service
pattern 1 · combined · one DID
The Owner/operator and the Actor share one DID: the service holds ECS-Organization and self-issues its ECS-Service credential. Suits small deployments and one-entity-one-service setups.
Verifiable Service
pattern 2 · delegated · production
A dedicated Organization service holds ECS-Organization and issues an ECS-Service credential to each Actor it operates: a service, an AI agent, a connected object.
Verifiable User Agent
software operated by humans
The software provider (the product line) is the issuer of ECS-UserAgent: every instance of the app receives a credential proving its controller, name, and version. Human users operate VUAs.
Live from testnet
Resolve a real Proof-of-Trust
Pick a DID and watch trust resolution happen: the resolver verifies the service's credentials and their issuers, recursively, against the public registry. This is what every peer sees before connecting.
The three connection flows
One model, three connection types
Trust is mutual in all three, with no client/server asymmetry.
1. A person connects to a service
An AG-UI compatible frontend (a Verifiable User Agent) connects to an enterprise AI agent (a Verifiable Service). The frontend resolves the agent's DID, checks its ECS-Service and ECS-Org or ECS-Persona credentials and their issuers, and shows a Proof-of-Trust. After the user accepts, it opens a DIDComm session, presents an ECS-UserAgent credential (and optionally an ECS-Badge for the human), then the AG-UI session is bootstrapped over the DIDComm session.
2. A service connects to another service
An AI agent from Company A connects to an AI agent from Company B (both Verifiable Services). Each verifies the credentials the other presents in its DID Document (ECS-Service plus ECS-Org or ECS-Persona, as Linked Verifiable Presentations). If both agree, a DIDComm session starts and an A2A session is bootstrapped over it.
3. Two people open a private connection
Alice and Bob use a chat application (each a Verifiable User Agent) and want a private peer-to-peer DIDComm connection. Alice shows a QR code, an out-of-band DIDComm invitation, that Bob scans. Once connected, both agents present an ECS-UserAgent credential, and each verifies through the public registry that the credential's issuer is accredited, so each knows the other is a legitimate user agent. They can then optionally share more credentials over the channel.
Discovery