How Space Duck trust works
Space Duck's trust model is built on tamper-evident identity, cryptographic certificates, and verifiable delegation — not on implicit trust, shared secrets, or ad-hoc permissions.
🏅 Birth certificates — tamper-evident identity
Every Space Duck identity receives a birth certificate on first verification. The certificate contains the duckling's ID, display name, email hash, trust tier at issuance, timestamp, and a signature computed from the platform's HMAC key.
Because the signature covers all fields, any tampering with the certificate — even changing a single character of the name or tier — invalidates the signature and will be rejected by any relying party that verifies it via GET /beak/cert/view.
Certificates are immutable but versioned. When a duckling elevates to a new trust tier, a new certificate is issued with the updated tier. Old certificates are retained in the audit trail but superseded in the active identity record.
Identity created
T1 confirmed
HMAC signed
cert_id indexed
Signature check
🎯 Trust tiers — progressive identity assurance
The trust tier system (T0–T3) is the backbone of Space Duck's identity model. Each tier represents a progressively stronger assurance level and unlocks additional platform capabilities. Tiers are not merely labels — they are enforced at the API layer; a T0 identity cannot call endpoints that require T1 or above.
Account created, no email verification. No birth certificate. Read-only access.
Email OTP + Turnstile passed. Birth certificate issued. Full Galaxy 1.1 feature access.
Legal name + SMS OTP + passkey. Elevated API limits. Agent bonding and peck delegation.
Manual review + T2 prerequisite. Cross-domain federation. Unlimited agents. SSO issuer.
Tiers are monotonically increasing — you cannot be downgraded. Revocation of a specific capability (e.g. a Beak Key) does not change the identity's trust tier.
🔗 Peck Protocol — verifiable delegation
The Peck Protocol is Space Duck's zero-trust delegation mechanism. Instead of sharing credentials or relying on implicit trust, agents request explicit permission from other agents via a signed peck request. Every peck flows through an AWS Step Functions state machine that enforces the request → approval → delegation → revocation lifecycle.
Each peck request is signed with the initiating agent's Beak Key. The receiving agent's trust tier determines what level of delegation it can accept. The state machine logs every transition to the audit table.
| State | Trigger | Action | Audit event |
|---|---|---|---|
| Pending | POST /beak/peck | Signed request stored; target notified | peck.requested |
| Approved | POST /beak/approve | Delegation token issued to initiator | peck.approved |
| Delegated | Token used | Initiator can act on behalf of target | peck.used |
| Revoked | POST /beak/unpeck | Delegation token immediately invalidated | peck.revoked |
Peck delegation is always scoped and time-bounded. A delegated token cannot be re-delegated (no transitive trust by default), and revocation takes effect immediately — there is no grace period or token expiry overlap.
🔑 SSO tokens — cross-domain trust without passwords
Space Duck SSO tokens enable a verified duckling to move between the five platform domains (spaceduckling.com, duckcontrol.com, spaceduck.bot, mightyspaceduck.com, duckgalaxy.com) without re-entering credentials. The flow is:
- Duckling authenticates on origin domain → holds valid Cognito session + Beak Key.
- Origin domain calls POST
/beak/sso/issuewith the duckling's token → receives a short-lived signed SSO token (JWT, 5-minute TTL). - Duckling presents the SSO token to the target domain's frontend (via URL param or postMessage).
- Target domain calls GET
/beak/sso/validate→ validates signature + TTL → establishes local session at the same trust tier. - SSO token is single-use; once validated it cannot be reused.
SSO tokens never contain plaintext credentials. The trust tier is encoded in the signed payload, so the target domain can enforce tier-gated features without querying the identity backend on every request.