Skip to main content
AIR sits between the issuer, the user, and storage. It identifies users, routes requests, and stores encrypted credentials, but it does not create, sign, or read them. This page goes through each stage describing what AIR does there.

​
Stage by stage

​
What AIR holds

​
What AIR cannot do

  • Issue on an issuer’s behalf. It has no issuer keys, so it cannot produce a credential that a verifier would accept.
  • Change a credential. Any change breaks the issuer’s signature.
  • Read a stored credential. It is encrypted to the user’s key.
  • Revoke a credential. Revocation runs on the issuer’s own service.

​
Where trust sits

The trust boundary is the issuer, not AIR. A verifier decides whether to accept a credential by checking the issuer’s signature against keys the issuer publishes on its own domain. Nothing a verifier checks depends on trusting AIR’s word, except when a verifier chooses to rely only on the unsigned result status instead of checking the presentation.

​
Agent verification

When an AI agent verifies a user’s credentials, the agent’s backend calls AIR’s Credential API instead of AIR Kit. AIR runs the verification program on the user’s behalf, within the scopes the user granted to that agent, and returns the result and the disclosed claims. See How agentic commerce works.