PUL-014 · VERIFIED IDENTITY FOUNDATION
Trust the identity. Not just the name.
A community member's identity must be verified by a trusted provider, tied to the right Pocket Universe account, and kept separate from staff administration. This lab shows what the existing provider can support—and what is not ready for real residents.
RESEARCHED EXISTING INFRASTRUCTURE
Provider compatible. Product integration still gated.
We inspected the public OpenID Connect discovery endpoint. It advertises authorization-code flow, PKCE S256 and RS256 ID-token signing. Compatibility alone does not create a registered app or establish permission to use an administrator directory for consumer accounts.
✓Authorization code + PKCE S256 supported
✓Signed ID tokens can be verified server-side
×No Pocket Universe OAuth client configured
×No decision to onboard consumers through EIP
SERVER-SIDE POLICY EXERCISE
Try a provider that breaks the rules.
Pick a fixed situation. The Pocket Universe server checks the discovery settings and refuses unsafe endpoints or missing PKCE. No actual token is exchanged.
THE SERVER'S DECISIONCHECKING
Select a scenario
The server returns the result of its pinned provider-policy check.
Why this mattersA provider's metadata is only the starting point. A future login must exchange a one-time code using PKCE, validate a signed ID token, enforce exact issuer, client audience and nonce, then mint a separate revocable Pocket session.
No identity or business access granted by this result.
One verified identity, independently scoped rights.
Register Pocket Universe's own client ID and exact HTTPS callback. Keep EIP staff administration separate.
Generate per-login state, nonce, S256 challenge and a browser-bound transaction. No tokens in URLs.
Check the provider's pinned signing key, issuer, audience, validity window and replay-resistant nonce.
Issue a revocable server session and separately determine Orbit membership. Never import EIP staff privileges.