Governance surface
Administrative governance for registered clients, roles, permissions, and audit review.
This surface is for deliberate operations: defining what apps may request, who may approve it, and how every sensitive change is recorded.
Governance surface
Admin governance sits on top of the same identity foundation and the same account-facing review model.
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.
Governance
The admin surface is where Ronova ID stops being abstract architecture and becomes an operational control plane.
Every application or console is registered before it can request identity, with known redirect targets and known permission boundaries.
Nothing high-trust should appear as an unnamed client.
Permissions are bundled into roles so repeated work can be assigned without hand-crafted privilege every time.
Bundles simplify both grant and review.
The audit stream should connect identity events to the client, the actor, and the change that was made.
Useful for both governance and incident response.
Governance loop
Sensitive identity changes should move through a deliberate sequence instead of appearing as one-click magic.
Register the application, define its return routes, and keep its purpose legible to future reviewers.
Attach only the permissions the client needs and bundle recurring work into named roles.
Grant or deny elevated access with a clear actor, reason, and target identity in view.
Review the resulting audit chain to confirm the change behaved the way governance expected.
Administrative catalog
The admin surface should feel like a controlled ledger of identity operations, not like a hidden back room.
Maintain the allowlisted applications, their return destinations, and the permissions they may request.
The catalog begins with the client registry.
Define named roles that bundle permissions into predictable responsibility sets for operators, reviewers, and owners.
Bundles reduce ad hoc privilege decisions.
Inspect sign-ins, grants, revocations, redirect outcomes, and sensitive mutations through one review surface.
The audit view keeps identity governance legible.
Principles
Administration is not only about power. It is about proving that power was bounded, reviewed, and correctly attached to the right client.
New clients and new roles should start narrower than comfortable and expand only when the real workload proves the need.
Least privilege is a starting posture, not an afterthought.
High-impact changes should ask for stronger confirmation or a visibly separate elevated session before they proceed.
Step-up keeps sensitive work distinct.
Identity and application teams need enough shared visibility that a redirect issue, grant issue, or abuse report can be traced across both sides.
Governance works better when the boundary is visible, not opaque.