Custodia · Renkan ID
Identity only when it matters.
Renkan ID is the sole persistent identity layer used by Triluna services, Ronova, and other relying projects. It provides identity and authentication while each project keeps its own authorisation and private data.
Progressive access
Three levels, chosen by the service.
- Level 0 · Zero-account
- A high-entropy capability link, QR code, or code is enough for actions such as receiving a Drop, checking a verification result, or revealing a Secret. Opening it does not create an account.
- Level 1 · Light identity
- Temporary proof of control for a verified recipient, sensitive receipt, or short-lived permission. Confirmation does not silently become a persistent profile.
- Level 2 · Full Renkan ID
- A persistent identity for ownership, history, authentication, account security, long-term authorisations, billing, and developer access. Passkey-first remains the intended direction.
UID continuity
- Current presentation
- UID: 120 12345 67890
- Canonical value
- The same thirteen ASCII digits, retained unchanged across Renkan ID and every relying project.
- Authority
- A UID identifies a subject. It never grants a project role, permission, entitlement, or access decision by itself.
Full account control
More continuity, not artificial restriction.
A full Renkan ID is structured to give its owner clear control without exposing secrets or importing project-private data.
- Identity
- Display name, masked UID, issue date, identity class when available, account status, and standing.
- Security
- Passkeys, active sessions and devices, and recent security events.
- Authorised applications
- Application names, granted identity scopes, authorisation and last-use dates, and revocable access—never project roles, balances, saves, or billing records.
- Developer access
- API-key names, prefixes, scopes, dates, and revocation state. Raw API secrets are shown once at creation and never revealed later.
Capability first
Drop and Secret recipients start without an account.
A sender may deliberately choose a PIN, verified recipient, specified Renkan ID, or future device-bound policy. Those are alternatives for a particular risk—not a forced progression through registration.
Capability access creates no shadow account and collects no email address merely for convenience. Ownership, history, revocation, persistent permissions, and API access are benefits of a full Renkan ID when the service genuinely needs them.