LIMEDocs

Resources

Frequently asked questions

Short answers about the LIME model: how a passport differs from a token, which credential goes where, how agent sign-in differs from binding, and what LIME does not do. For AI agents: /docs/all.en.md.

The model#

  • How is an agent different from its passport? An agent is a permanent agent_id; the passport is a short-lived RS256 JWT that proves it to one service — see passport claims.
  • Who issues passports? Core alone; it signs with RS256 and publishes the public keys as JWKS — see discovery.
  • What does the `aud` claim name? The passport's purpose — mcp, lime-site-login, or lime-binding — with each lifetime in the lifetimes reference.
  • Where does `agent_id` live in a passport? In the sub claim, read only after local verification — see passport claims.
  • Does a service verify a passport through LIME? No; it verifies the signature locally against JWKS — see local verification.

Credentials#

  • Where does the Agent Token go? Only to LIME; it authenticates the agent and never reaches a service — see credentials.
  • Where does the Site Token go? Only to LIME, from the site's server side; it is not a JWT — see credentials.
  • Which credential does a service see? Only the passport in Authorization: Bearer — see credentials.
  • Is a Site Token needed on an MCP server? No; only the public JWKS and a verifier are needed — see credentials.
  • Can an agent get a client keypair? No; only Core signs, and the keys stay with LIME — see credentials.

Flows#

  • What is the MCP passport? The agent trades its Agent Token for an aud=mcp passport and presents it to a server as Bearer — see the lifetimes reference.
  • What is agent site login? The backend creates a request, the agent approves it, and the aud=lime-site-login passport opens the site's own session — see the lifetimes reference.
  • What is binding? Proof of ownership: a person picks an agent, and the service keeps the agent_id ↔ user_id link itself — see binding.
  • How does binding differ from agent site login? Sign-in opens a session; binding confirms whose agent it is, with separate audiences — see the lifetimes reference.
  • Does the agent complete binding? No; binding is carried out by a person in the browser — see binding.

Boundaries#

  • Is LIME an MCP host? No; it attests identity, and the service decides access — see boundary.
  • Is LIME a proxy? No; agent↔service traffic does not route through LIME — see boundary.
  • Is LIME a human IdP? No; its subjects are agents — see boundary.
  • Is LIME an authorization engine? No; access rules are yours — see boundary.
  • Does LIME see your databases or tool data? No; it stores identity, issuance, and audit records only — see boundary.

Rotation and revocation#

  • What happens to a passport when an agent is revoked? New passports stop; the issued ones expire within their lifetime — see lifetimes.
  • What happens to keys during rotation? JWKS publishes one active signing key plus, while it is configured, one rollover verification key; there is no state machine and no fixed rotation window — see the key reference.
  • Is there an overlap window for key rotation? Yes — while a rollover key is configured (there is no fixed window); credential rotation has none — see the key reference.
  • Can LIME revoke a binding? No; the service stores and ends the link itself — see binding.

Errors#

  • Why does minting sometimes return `429`? Expensive operations are rate-limited; back off with jitter (the mint's OAuth 429 carries no Retry-After) — see error codes.
  • Why did a valid passport get `401`? Usually expiry, a stale JWKS cache, or the wrong aud — see error codes.
  • Why did minting return `400`? The body failed validation, usually domain with a scheme or path — see error codes.
  • Where can I see all the codes? In the error code reference.

Next steps#

Was this page helpful?

Frequently asked questions · LIME