Privacy, security, and lifecycle control

The design goal is not “privacy by login.” It is to narrow what sign-in can authorize and to surround the handoff with independent controls. Each control answers a different threat.

9.1 Data minimization

The handoff should contain only what is required to complete the bounded relationship: protocol version, intended audience, verified identity reference, approved return binding, transaction binding, verifier challenge, issue and expiry times, and replay-resistant nonce. It should not become a compressed profile. In particular, the current sign-in use cases do not require email, human-readable name, identity facets, private state, scores, activity records, reflection narratives, credential dossiers, or publication settings.

Minimization applies to logs as well as payloads. Request identifiers and failure categories can support operation without copying the handoff, verifier, identity details, or participant content. The canary evidence format records route, outcome, time, public slug where relevant, source-update time, and version. It forbids record content and secrets.

9.2 Redirect and transaction integrity

An attacker who can substitute a return location can redirect sensitive artifacts to an untrusted site. The current services therefore validate exact canonical origins and approved paths. Request-host or Origin headers are not treated as authority for where an identity callback may complete.

State binds the returning browser to the transaction the relying application initiated. PKCE binds code exchange to possession of the original verifier. Short expiry narrows the useful interception window. Audience prevents a handoff issued for one relying application from being accepted by another. One-use redemption prevents replay after successful exchange. These controls overlap intentionally; none is a substitute for the others.

9.3 Session and CSRF boundaries

The identity authority and relying applications retain separate sessions. Protected state-changing requests require application-appropriate CSRF controls. Cookies use scoped paths, secure transport in production, and same-site behavior appropriate to the redirect journey. A relying application must clear abandoned transaction material after success or failure.

A local session should not outlive the risk assumptions under which it was created. Current applications retain their own logout and expiry behavior. The paper does not claim coordinated single logout. A future coordination mechanism would need to specify propagation, offline applications, partial failure, and the difference between ending a session and revoking consent.

9.4 Owner isolation and service authority

Row Level Security provides an application database boundary for member-owned records. Service-role credentials remain server-side. A browser cannot gain direct table access merely by holding an authenticated session. For ~Cortisol Checker~ V2, protected endpoints validate the strict structured schema before persistence and restrict reads and mutations to the owner.

RLS is necessary but insufficient. Server routes that use elevated credentials must recreate purpose and ownership checks. Signing secrets need rotation. Error logs need redaction. Backups and derived stores need compatible deletion and retention policies. Dependency and infrastructure vulnerabilities remain possible.

9.5 Revocation, correction, and deletion

Four lifecycle actions must not be collapsed:

• Logout ends or invalidates a session.
• Consent revocation withdraws permission for a declared action and may trigger contract-specific deletion.
• Disclosure withdrawal changes what a projection makes visible to an audience.
• Correction or deletion changes or removes application records according to their governing ledger and retention model.

Value Log uses append-only correction and replay for governed event history. ~Cortisol Checker~ V2 appends observation revisions and supports group deletion. Word Wallet disclosure settings can remove a facet from future public projections. These mechanisms serve different truth and privacy requirements.

9.6 Residual threats

The architecture does not remove phishing, compromised browsers, stolen sessions, malicious insiders, dependency vulnerabilities, email-account compromise, traffic analysis, denial of service, confusing consent copy, coercion, or inappropriate institutional requirements. A stable cross-application reference can itself become sensitive if broadly exposed. Pairwise or audience-specific identifiers may reduce correlation in future designs, but the current implementation uses one internal document anchor and relies on not disclosing it unnecessarily.

The system has not received independent penetration testing, privacy impact certification, legal opinion, accessibility certification, or standards certification. These absences are release facts, not footnotes.