Account surface
A user-facing view of profile authority, session activity, and redirect history across Ronova-owned apps.
This surface is where a person checks what is signed in, which app received access, and how to tighten their own posture.
Account surface
The account surface sits between the overall identity map and the heavier administrative controls.
Live access
The public passkey-first sign-in flow is not enabled yet. For the initial owner bootstrap, Ronova ID can derive a temporary elevated session from an existing Ronova private admin session.
This bridge is intentionally narrow: it requires the existing private admin session and never creates a shared cookie for other domains.
Account
The account surface turns identity into something the person can inspect, not only something the application consumes behind the curtain.
Core account data stays consistent while recovery paths remain explicit and reviewable.
No hidden fallback identities.
People can inspect current sessions by application, recent activity, and trust level to spot stale devices or unexpected access.
Especially useful when an elevated role exists on the same identity.
Every redirect can show the requesting client, requested scope, and return path that will resume after approval.
The account view doubles as a readable receipt.
Review loop
The account view should make it easy to notice what is active, what was approved, and what needs to be revoked.
The person arrives from an app or from the central overview and lands in a readable account context.
Current sessions are grouped by application so the person can quickly understand where they are signed in.
Unexpected scopes, stale devices, or elevated sessions can be revoked without disturbing unrelated low-risk access.
If something still looks wrong, the redirect history and audit receipts provide enough context for support without guessing.
Session catalog
A person may appear across several Ronova-owned surfaces, but each surface can hold a different session profile and risk level.
Used for identity overview, support routing, and low-risk profile checks where the user only needs calm self-service access.
Public-facing context.
Used for project-facing features such as profile presence, support history, or save-related account work inside a Ronova app.
Application-specific context.
Used when a person holds an elevated role and performs sensitive work that should be visibly separated from everyday browsing.
Shorter lifetime, stronger review.
Governance
The account view is where permissions become understandable from the user's side instead of only the operator's side.
Permissions should be described in plain language so a person can see what an app is allowed to do on their behalf.
Readable grants support real consent.
If an identity holds support or admin roles, the elevated context should be clearly separated from ordinary browsing.
Role awareness prevents silent overreach.
Recent approvals, revocations, and sign-in outcomes remain visible for self-review and for grounded support conversations.
Audit becomes useful before there is a crisis.