Back to Sign in with Wellbeing Identity

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 ·

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:

  1. register exact relying-application audience and return locations;
  2. generate fresh high-entropy state and PKCE verifier material for each attempt;
  3. store transaction material only for the bounded exchange window;
  4. authenticate at the identity authority without exposing the private locator;
  5. fail closed when no eligible identity binding exists;
  6. issue a signed, short-lived, audience-bound, return-bound, state-bound, challenge-bound handoff with a nonce;
  7. reject expired, malformed, wrong-audience, wrong-state, wrong-return, invalid-verifier, and replayed handoffs;
  8. create a relying-application session separate from the identity-authority session;
  9. require separate consent for application actions beyond sign-in;
  10. omit identity facets and application records unless a separately authorized projection requires them;
  11. retain only minimized audit evidence; and
  12. 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.

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

ScenarioExpected resultEvidence allowed
Valid journeyOne local session for intended audienceRoute, outcome, time, version
Expired continuationSafe restart; no sessionBounded expiry category
Replayed handoffRejected; existing session unaffectedReplay category, keyed code hash if required
Wrong audienceRejected before session creationAudience category
Wrong stateBrowser transaction cleared; restartState category
Invalid verifierRejected; code not acceptedVerifier category
Disallowed returnNo redirect to unregistered locationReturn-policy category
Identity unavailableGeneric safe failureNo email or membership enumeration
Revoked local sessionProtected route returns unauthorizedSession category
Separate action lacks consentSign-in remains valid; action deniedConsent 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.

~

End of signal.