Chapter 11 of 12 · 4 min read
Nonnormative relying-application profile
Proposed integration roles, controls, permitted data, prohibited data, errors, and conformance scenarios.
Sign in with Wellbeing Identity · v0.1 · edition history · Moses Sam Paul
This profile draws from the two integrations. It is proposed implementation guidance and does not change the canonical Spec.
11.1 Roles
- Identity holder: the represented person who controls participation and disclosure.
- Identity authority: Word Wallet Web or a future conforming authority that authenticates the holder and resolves the eligible identity binding.
- Relying application: an application requesting a bounded local relationship.
- Projection authority: the component authorized to construct a particular purpose-specific identity reading; it may be distinct from the relying application.
- Protocol authority: the IoV Spec for canonical paths and invariants.
- Evidence operator: the service retaining minimized security and conformance evidence.
11.2 Required handoff properties
A conforming profile implementation should:
- register exact relying-application audience and return locations;
- generate fresh high-entropy state and PKCE verifier material for each attempt;
- store transaction material only for the bounded exchange window;
- authenticate at the identity authority without exposing the private locator;
- fail closed when no eligible identity binding exists;
- issue a signed, short-lived, audience-bound, return-bound, state-bound, challenge-bound handoff with a nonce;
- reject expired, malformed, wrong-audience, wrong-state, wrong-return, invalid-verifier, and replayed handoffs;
- create a relying-application session separate from the identity-authority session;
- require separate consent for application actions beyond sign-in;
- omit identity facets and application records unless a separately authorized projection requires them;
- retain only minimized audit evidence; and
- provide safe restart and logout behavior without account enumeration.
11.3 Permitted minimum data
The handoff may contain version, audience, verified identity reference, approved return binding, transaction binding, verifier challenge, issue time, expiry time, and nonce. An implementation may replace the stable reference with a pairwise reference if its identity-binding and recovery model supports it.
11.4 Prohibited default data
The default sign-in handoff should not contain:
- email, phone, national identifier, birth information, caste, religion, genetics, or social handles;
- skills, values, story, credentials, WellbeingScore, score history, or Genesis material;
- Value Log activities, narratives, performance evidence, calculations, or replay data;
~Cortisol Checker~reflection text, observations, patterns, or inferred state;- public-profile sharing settings or publication consent;
- access tokens or credentials belonging to another application; or
- secrets, raw authentication links, or reusable bearer artifacts.
If a future application requires any identity claim, it should use a separately declared projection or credential-presentation contract with a named purpose, audience, data set, retention rule, revocation behavior, and reviewable necessity argument.
11.5 Consent separation
Sign-in consent means “continue to this application.” It does not imply consent to analyze content, store an observation, publish a profile, synchronize a score, validate performance, share a credential, receive marketing, or move money. Each action requires its own contract where applicable.
11.6 Error categories
The relying application should map detailed internal failures to bounded user-facing categories without revealing private account existence:
- transaction missing or expired;
- state mismatch;
- return location rejected;
- identity authentication incomplete;
- eligible identity unavailable;
- handoff invalid or expired;
- verifier proof failed;
- handoff already used;
- local session unavailable;
- service temporarily unavailable; and
- consent or authorization required after sign-in.
11.7 Conformance scenarios
| Scenario | Expected result | Evidence allowed |
|---|---|---|
| Valid journey | One local session for intended audience | Route, outcome, time, version |
| Expired continuation | Safe restart; no session | Bounded expiry category |
| Replayed handoff | Rejected; existing session unaffected | Replay category, keyed code hash if required |
| Wrong audience | Rejected before session creation | Audience category |
| Wrong state | Browser transaction cleared; restart | State category |
| Invalid verifier | Rejected; code not accepted | Verifier category |
| Disallowed return | No redirect to unregistered location | Return-policy category |
| Identity unavailable | Generic safe failure | No email or membership enumeration |
| Revoked local session | Protected route returns unauthorized | Session category |
| Separate action lacks consent | Sign-in remains valid; action denied | Consent category only |
The profile should be implemented as shared, reviewed code before being advertised as a reusable module. Documentation alone cannot prevent two integrations from drifting.