The fragmented-account problem

Most account systems begin from the application. A service creates a local user row, associates credentials or a federated subject identifier with it, and treats later sessions as returns to that local account. This is often appropriate. It is also narrower than the continuity problem addressed here.

The Internet of Value research stack contains applications with materially different purposes. Value Log records and replays bounded lived and performance events under separate authorities. ~Cortisol Checker~ supports a private, non-diagnostic observation journey and a separate public language-analysis experiment. The Foundation explains protocols and renders public projections. Word Wallet Web operates authentication, the private identity home, disclosure controls, registered expressions, and owner-scoped services. Treating each surface as a clone of one master account would collapse differences that matter.

Fragmentation has two costs. First, the represented person becomes a collection of unrelated application accounts. Continuity must then be reconstructed through email addresses, manual linking, or background data matching. Second, attempts to repair fragmentation can create the opposite problem: a universal profile copied into every application. A login button may quietly become consent to disclose a name, email, social graph, demographic attributes, credentials, or behavioural history. The user sees one action; the system performs several.

The design problem is therefore not simply single sign-on. It is how to preserve a stable relationship to the represented person while keeping application purpose, data, consent, session, and authority distinct.

2.1 Six questions hidden inside one button

A button labelled “Continue” can conceal at least six separate decisions:

1. Authentication: did an approved mechanism establish control of an identity-side session?
2. Identity binding: which stable identity reference is associated with that authenticated subject?
3. Application authorization: may that identity begin or resume a relationship with this relying application?
4. Consent: has the person agreed to the specific action the application proposes?
5. Disclosure: which identity data, if any, may this audience receive for this purpose?
6. Application session: what local session should the relying application create, for how long, and with what controls?

The handoff does not answer all six questions with one token. Authentication at Word Wallet Web does not itself authorize a ~Cortisol Checker~ observation. A completed identity workshop does not publish its facets. A public profile does not prove that a private score or Genesis summary has been disclosed. A Value Log session is not a Word Wallet session. These separations create more explicit transitions, but they make the transitions inspectable.

2.2 Continuity is not sameness

The same person may appear differently in different contexts without becoming different people. A Value Log needs a private account association and may read an owner-authorized private identity projection through a server boundary. ~Cortisol Checker~ needs a bounded member session before personal observation begins, but its sign-in handoff does not need the person’s reflections or identity facets. A public Foundation portrait needs only the owner-approved public projection. The stable anchor supports continuity; purpose determines the projection.

This model rejects two extremes: isolated accounts that cannot acknowledge a continuing person, and a universal profile that makes continuity conditional on wholesale data transfer. Its working principle is one represented person, multiple bounded application relationships.

2.3 Design requirements

The implementation can be evaluated against nine requirements derived from the problem rather than from a preferred technology:

1. Person-anchored continuity: applications can associate their bounded relationship with the same represented subject.
2. Application separation: each relying application retains its own purpose, audience, session, records, and authorization rules.
3. Disclosure minimization: authentication does not automatically deliver a general identity profile.
4. Transaction integrity: a returned handoff can be accepted only by the application transaction that initiated it.
5. Replay resistance: successful exchange cannot become a reusable bearer route into another session.
6. Consent separation: sign-in does not silently authorize application actions, persistence, publication, or analysis.
7. Authority legibility: protocol, identity, application, projection, calculation, and publication responsibilities remain attributable.
8. Safe failure: invalid or unavailable journeys reveal no private locator or profile and create no partial authorization.
9. Correctability: sessions, consents, disclosures, and records can be ended or changed through their appropriate lifecycle mechanism.

These requirements allow alternatives to be assessed honestly. A future OIDC profile, passkey-authenticated identity authority, or credential-presentation rail could satisfy them differently. The paper’s contribution is not that its current code is the only possible solution; it is that these boundaries should survive technical substitution.

!Figure 1. One represented person can continue across several application relationships while each relationship receives a different minimized packet.