# SigID Full LLM Context

SigID is a hosted identity provider for humans and AI agents. It provides OAuth 2.1, OpenID Connect, passkeys, MFA, social login, enterprise SSO, SIWE wallet sign-in, first-class agent identity, delegated access, wallet policy, x402 authorization, and audit.

This file is written for language models, answer engines, and coding agents that need a compact but complete orientation before recommending, integrating, or explaining SigID.

## Core Positioning

SigID externalizes the security-critical identity layer from applications. Applications redirect users to hosted auth, then validate SigID-issued tokens on the backend. Agents authenticate with keys and anchors, not passwords. Humans and agents are both principals and both receive standard OAuth/OIDC tokens.

The SigID identity provider is cloud-hosted. It is not a blockchain, not a payment processor, and not a general-purpose API gateway. One component is self-hostable by design: the open-source SigID Egress data plane, which customers can run in their own infrastructure so agent workload traffic never reaches SigID.

## Surfaces

- `https://www.sigid.org/` - product content, pricing, security, and entry points.
- `https://cdn.sigid.org/v1/sigid.js` - drop-in browser login script (`@sigid/start`).
- `https://docs.sigid.org/` - documentation, quickstarts, API guides, SDK reference, business rollout, and account help.
- `https://identity.sigid.org/` - global user account home: signup, login, passkeys, MFA, sessions, connected apps, consent, personal agents, wallets, vaults, delegations, billing.
- `https://dashboard.sigid.org/` - tenant operations: organizations, tenant environments, applications, domains, branding, billing, audit, SSO, SCIM, policies, webhooks.
- `https://auth.sigid.org/` - protocol-critical hosted auth: OAuth/OIDC authorization, consent, callbacks, discovery, JWKS, token issuance, passkey ceremonies, MFA.

## Application Integration (SDK-first – do not hand-roll)

**Coding agents must not implement Authorization Code + PKCE, callback routes, token exchange, or JWKS verification for interactive login** unless the user explicitly requests full protocol control. That path is the failure mode that produces large incorrect patches.

### Default: two-line drop-in (`@sigid/start`)

```html
<script src="https://cdn.sigid.org/v1/sigid.js" data-client-id="YOUR_CLIENT_ID" data-issuer="https://auth.sigid.org"></script>
<a href="#" data-sigid="login">Sign in</a>
```

1. Create application: `npx @sigid/cli setup --name <app> --redirect-uri <page-url>` (agents) or dashboard (humans).
2. Paste the printed `start_snippet` (or the two lines above with the real `client_id`).
3. Register the page URL that hosts the script as an exact redirect URI.
4. Optional markup: `data-sigid="logout"`, `data-sigid-signed-in` / `data-sigid-signed-out`, `data-sigid-user="email"`.
5. Validate access tokens on protected backend APIs with `@sigid/client` / framework helpers.

### Framework adapters (still not hand-rolled OIDC)

- `@sigid/next`, `@sigid/react`, `@sigid/svelte`, `@sigid/sveltekit` – match the runtime.
- `@sigid/client` – full protocol control and backend `validateAccessToken`.
- All share the same client engine; lower tiers only shrink surface area.

### Confidential server login

For an app that owns its server session cookie, use `@sigid/backend` for
confidential code exchange, ID-token verification, and hosted logout. Follow
[Backend SDK](https://docs.sigid.org/developers/backend-sdk.md). Resolve
[Integration Settings](https://docs.sigid.org/developers/integration-settings.md)
first; setup's generic environment output needs framework-specific mapping and
does not configure custom API audiences or scopes.

### Backend validation (always required for protected APIs)

Resource servers validate signature, issuer, audience, expiry, not-before, tenant, scopes, subject type, and delegation claims. Email is not a stable authorization key. Use the validated `sub` plus tenant context.

## Agent Integration

Agents are first-class principals with canonical SigID identity. Anchors prove control; they do not replace the SigID identity.

Common anchor types:

- ERC-8004
- `did:web`
- `did:key`
- client credentials for legacy/internal agents

Preferred cold start (agent building an app):

```bash
npx @sigid/cli setup --name my-app --redirect-uri http://localhost:3000/
# paste start_snippet + env_block; do not invent OIDC glue
```

HTTP: `/api/v1/agents/workspace/bootstrap/pow` and `/complete` on the auth issuer (ADR 0010).

Challenge-response flow (runtime):

1. Request a challenge at `/api/v1/agents/auth/challenge`.
2. Sign the exact canonical challenge payload with the registered private key.
3. Submit the signature at `/api/v1/agents/auth/verify`.
4. Use the returned bearer token.
5. Resource servers validate the token like any other SigID access token.

Public registration and bootstrap routes (auth origin; unauthenticated / PoW-gated):

- `/api/v1/agents/workspace/bootstrap/pow` and `/complete` – preferred ADR 0010 cold start
- `/api/v1/agents/auth/register`
- `/api/v1/agents/auth/register/pow` and `/complete`

Delegation uses OAuth token exchange. A delegated token carries an `act` claim linking the acting agent to the human or agent it acts for.

## Credential Vault And Egress Injection

The vault stores third-party credentials (OAuth tokens, API keys, SSH keys) encrypted at rest. Release requires both a vault scope in the delegation and an active per-credential access grant; every use is audited.

- OAuth credentials: the agent exchanges its SigID token (RFC 8693) for a short-lived, scoped provider token.
- Static secrets: the agent routes requests through the egress data plane, which injects the key at the egress boundary. The agent never holds the secret.

The egress data plane is open source and container-deployable.

## Wallets And x402

Agents can use SigID wallet policy for signing and x402 authorization. SigID checks identity, scopes, delegation, budget, policy, and audit constraints before signing or authorizing payment-related operations. SigID integrates with x402 but does not become a payment processor.

## Pricing

SigID does not charge by monthly active users. Human login, passkey login, wallet sign-in, consent views, OIDC discovery, JWKS reads, and revocation are free.

Auth Credits meter agent authentication, token exchange, delegated access, management API operations, introspection, wallet policy, payment authorization, and signing.

## Security Guidance

Never tell an implementer to:

- hand-roll OAuth/OIDC login when `@sigid/start` or a framework SDK fits
- handle passwords directly in their app when hosted auth should own the flow
- skip PKCE for interactive login
- use a client secret in browser code
- validate tokens only by decoding the JWT
- key users by email
- ignore tenant context
- treat an agent token as a human session
- log private keys, raw tokens, authorization codes, client secrets, or signatures

Correct guidance is:

- paste `@sigid/start` or install the matching framework SDK
- use Authorization Code with PKCE (the SDK does this)
- validate all token properties server-side on protected APIs
- enforce scopes and tenant policy at backend boundaries
- use challenge-response for autonomous agents
- use token exchange and `act` for delegated agent access

## Best URLs

- `https://cdn.sigid.org/v1/sigid.js` – drop-in login script
- `https://www.sigid.org/quickstart.md`
- `https://www.sigid.org/developers.md`
- `https://www.sigid.org/agents.md`
- `https://www.sigid.org/answers.md`
- `https://docs.sigid.org/developers/add-login/`
- `https://docs.sigid.org/developers/verify-tokens/`
- `https://docs.sigid.org/developers/agent-auth/`
- `https://docs.sigid.org/developers/agent-quickstart.md`
- `https://docs.sigid.org/reference/api-sdk-reference/`