Why verifiable credentials matter for agents
When agent A calls agent B, how does B know what A is allowed to do? Today, most systems answer this with a network call back to a central auth server. That works inside one organization, but falls apart when agents cross trust boundaries. W3C Verifiable Credentials solve this. A credential is a signed JSON document that says “agent X has permissions Y, issued by authority Z.” The agent carries the credential and presents it directly. The verifier checks the cryptographic signature and reads the permissions. No network call needed. This matters for three reasons:- Offline verification — an agent can prove its identity and permissions without the issuing server being reachable
- Cross-organization trust — if you trust the issuer’s DID, you trust the credential, regardless of where the agent lives
- Delegation chains — a credential can encode a chain of delegations, so a sub-agent can prove it was authorized by its parent
VCs build on top of KavachOS DID support. If you have not set up DIDs yet, see the DID identity page first.
Issuing credentials
Create an issuer bound to a DID keypair. The issuer can produce credentials in JWT or JSON-LD format.Agent identity credential
Encodes who the agent is, what it can do, and how much you trust it.- JWT
- JSON-LD
Permission credential
Grants specific permissions to an agent without encoding the full identity.Delegation credential
Encodes a chain of delegations so a sub-agent can prove it was authorized by its parent, which was authorized by its parent, and so on.Verifying credentials
Create a verifier to check credentials from any source. The verifier validates the signature, checks expiry, and optionally checks revocation status.Verify a JWT credential
Verify a JSON-LD credential
Verify a presentation (multiple credentials)
An agent might present several credentials at once to prove both identity and permissions.Extract permissions
After verification, pull out the KavachOS-specific permissions.Portable identity
The key advantage of VCs is portability. An agent issued a credential by KavachOS instance A can present it to service B without B ever talking to A.Integration with DID support
VCs work with bothdid:key and did:web identifiers. The issuer DID is embedded in the credential’s issuer field. When verifying, the verifier resolves the DID to get the public key.
For did:key, resolution is local (the key is embedded in the identifier). For did:web, the verifier fetches the DID document from the well-known URL.