# SigID Product Architecture

SigID is organized around explicit surface ownership. Each public or first-party surface carries one job and one security boundary.

## Surfaces

| Surface | Role | Owns |
|---|---|---|
| `www.sigid.org` | Public content | landing pages, product pages, pricing, security, docs entry points |
| `identity.sigid.org` | User account home | signup, login, profile, passkeys, MFA, sessions, connected apps, consent, personal agents |
| `dashboard.sigid.org` | Tenant operations | organizations, tenant environments, applications, domains, branding, billing, audit |
| `auth.sigid.org` | Hosted auth | OAuth/OIDC authorization, consent, callbacks, passkey ceremonies, token issuance, discovery, JWKS |

The public site owns no account session and no tenant session. Hosted auth remains protocol-focused. Identity owns the person. Dashboard owns tenant operations.

## Product Boundary

SigID is:

- a hosted multi-tenant IDP
- an OAuth 2.1 authorization server
- an OpenID Connect provider
- an identity system for humans and agents
- an agent wallet infrastructure provider
- a credential vault for third-party service tokens
- a tenant authorization system
- an identity-mediated access layer for agent and LLM traffic

SigID is not:

- self-hosted software
- a blockchain platform
- a payment processor
- a general-purpose API gateway

## Recommended Integration Model

Applications should:

1. redirect users to hosted auth
2. handle callback and token exchange
3. validate tokens server-side
4. enforce tenant, scope, and subject policy at API boundaries
5. use SigID dashboard controls for application configuration
6. use SigID agent flows for autonomous agents and delegated access

## Why The Surface Split Matters

The split keeps cookie scope, redirect targets, logout behavior, tenant branding, and protocol-critical OAuth state easier to review. It also prevents product content, account settings, tenant operations, and hosted auth from becoming one ambiguous browser application.