An identity for every participant
Know who is
behind the agent.
Give agents a portable identity, bind actions to a signer, and connect their authority to the people and organizations behind them.
- 01 Human root
The person.
A human-controlled root is one way to establish control.
- 02 Parent agent
The keeper.
An agent has its own identity and a relationship to its root.
- 03 Child agent
The next agent.
A child’s claimed authority needs a verifiable lineage.
A name you can verify.
An agent can change models, move between services, and work with new partners. Its identity should travel with it. Sigil anchors OAS identities so applications can connect a signed action to a recognizable participant and inspect the authority behind it.
OAS uses decentralized identifiers to describe agents, people, organizations, tools, and other participants. The identity belongs in the interaction, wherever the application runs.
A record to read.
A signer to verify.
Transactions bind an action to a signer, a network, and a nonce. Applications can attribute a payment, published artifact, or contract call to the identity that submitted it.
Identity establishes attribution. Trust needs context.
An explanation of the concepts, not an API response or a verified live identity.
Which identity is this?
A subject you can resolve.
A DID identifies the participant. Resolve its document and check the relevant commitments; a display name alone does not establish who signed an action.
Read the identity reference- 01
Check revocation.
Inspect the subject and its ancestors before accepting their authority.
- 02
Verify the document.
Compare the retrieved document with its anchor and cryptographic commitment.
- 03
Verify the relationship.
Check the parent signature and any required organizational inclusion proof.
Cryptographic underneath.
Human on the surface.
Attach an @-handle, resolve a .sigil name, and configure a recovery ceremony. Human-readable interfaces can sit on top of cryptographic identifiers.
An identity has
a lifecycle.
Build against the supported path on your selected network.
- 01
Create an OAS identity
Choose the appropriate identity kind and establish its controlling key and document.
- 02
Register and resolve
Anchor the identity on the selected network, then resolve the document and verify the relevant commitments.
- 03
Sign the work
Use the identity for supported transactions and carry its provenance through the application.
Identity, explained.
Does an identity prove that an agent is trustworthy?
It establishes attribution and can expose authority relationships. Whether to trust an action still depends on permissions, revocation, evidence, and your application’s policy.
Can I manage every identity operation on-chain?
Registration and the dedicated recovery ceremony have concrete transaction paths. Generic identity updates, delegation, and the broader root-and-agent lifecycle are not all enabled in the current release; check the supported transaction surface before integrating.