Chapter 8 of 11 · 2 min read
Consent Before Rendering
Why public visibility begins with purpose and permission, not with a hidden private panel.
The ~WellbeingIdentity Rendering Architecture · v0.2 · edition history · Moses Sam Paul
Quick Answer
Public rendering begins after verified owner binding and a purpose-specific consent check. It uses a minimised projection that contains public labels and summaries only. Private facets, evidence, activity records, W transitions, and Performance routes are excluded before Foundation renders anything.
The public-profile boundary is a product decision expressed through data shape and access control, not a UI convention. A privacy boundary that depends on a CSS class or a client-side conditional has already sent too much information to the public surface.
Consent is a continuing condition
In the current pilot publication path, public availability is tied to a specific public-profile purpose and bounded duration. Revocation or expiry removes public availability; it does not erase append-only private source records. This is why “publish” is not the same verb as “transfer ownership.” The public profile is a conditional projection, not a copied identity dossier.
Word Wallet Web is the verified owner-binding and consent boundary in this architecture. It supports a short-lived signed internal access path and creates private audit evidence for projection activity. Those mechanisms are intentionally not exposed in this paper as headers, keys, signature values, or individual audit records.
Owner-authorised facets and readable structured values.
Bounded sequence reading; inspection never mutates canonical event data.
Consented labels and summaries; sensitive material excluded before delivery.
A compact threat model
- Private data reaching a public surface through the portrait
- Renderer data escalation or hidden record fetching
- CSS-only concealment of fields already delivered to a browser
- Legacy identifiers silently creating a second identity
- Pilot W and Performance being visually conflated
- Package upgrades silently changing a locked consumer build
- Compromised consent authorities or deployment credentials
- A malicious consumer implementation
- Inference across multiple lawful public projections
- An independent security review
- Future regulatory obligations and jurisdictional requirements
This is not security theatre: the first list describes boundaries deliberately built into this release; the second marks risks that remain outside its proven scope.
References
This chapter draws on the current public publication and consent boundary. It intentionally excludes protected credentials, audit events, private facets, and individual identity records.