Technologies Search

Product

Identity and Access

Accounts, sign-in factors, sessions, API keys, invitations and directory provisioning, with every grant checked on each operation.

On this page
  1. What it does
  2. What exists now
  3. Who may do what
  4. Data handling
  5. Operating needs
  6. Limits
  7. Availability
  8. Evidence

What it does

Identity and Access decides who a caller is and what that caller may do. It holds accounts for people, organisations and registered agents, authenticates them, and checks a stored capability grant before each operation. Without a matching grant the answer is deny.

What exists now

CapabilityWhat it doesWhere to use it
Sign-inPassword sign-in with a time-based authenticator code (TOTP) as the second factor, and passkeys (WebAuthn) where the deployment configures them.Sign in
SessionsLists a signed-in account's sessions, ends one, or ends every other session.Sessions
API keysCreates, rotates and revokes keys for the account's own use; a revoked key stops working.API keys
InvitationsAn organisation invites a person by address; the person accepts with a one-time code, and an existing verified account can join instead of creating a second one.Invitations
Agent identitiesAn account holder registers an agent identity and can end it. An agent can never issue or self-authorise a grant.Agents
Directory provisioningSCIM 2.0 Users: list, read and provision principals from a directory with a provisioning token.API reference

Who may do what

Authority comes from grants: a principal, a resource, a permitted effect and a time window, under a pinned policy version. A grant that has expired, been revoked or been issued by the requester itself does not authorise anything, and each refusal carries a stable reason code. Operations that change state record the decision in the audit chain.

Data handling

Credentials are stored as bcrypt hashes, authenticator secrets are stored encrypted, and one-time codes are derived rather than stored. An account's contact address is erased through the data request process. The privacy notice states what is collected and for how long.

Operating needs

  • One PostgreSQL database; the runtime role is a least-privilege role, never the schema owner.
  • An outbound mail relay if verification, reset and invitation codes are to be delivered by email. Without one the platform records that delivery was not possible.
  • Passkeys need the deployment's relying-party domain to be configured.

Limits

  • SCIM deprovisioning and the active flag are refused on purpose: suspension and erasure are decided on the platform, and erasure belongs to the data request process.
  • There is no single sign-on through an external identity provider; sign-in is by the factors above.
  • Nothing here is a certified identity service, and no certification is claimed.

Availability

Identity and Access is running on RJV's own platform. RJV does not sell a licence for it as a separate product today: the commercial terms state what is on sale. It can be part of the result of an engineering engagement, where the written proposal names it, its licence terms and what you would hold at the end. To discuss it, use Work with Us.

Evidence

The sign-in, grant, session, API key and provisioning behaviour is exercised by the platform's own tests against a real database, and the operations are described in the API reference. The evidence register lists the claims RJV has graded.

  • Advisory Engagement Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Appointment Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Asset Tracker: Required by. An account signs in and holds the grant that lets it use the register.
  • Billing Ledger: Required by. Invoices and subscriptions belong to an account.
  • Board Resolutions: Required by. An account signs in and holds the grant that lets it use the register.
  • Case Record: Required by. An account signs in and holds the grant that lets it use the register.
  • Clinical Audit Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Clinical Trial Registry: Required by. An account signs in and holds the grant that lets it use the register.
  • Configuration Change Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Consent Record Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Cost Tracker: Required by. An account signs in and holds the grant that lets it use the register.
  • Customer Due Diligence Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Customer Segment Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Data Subject Requests: Required by. A request is made by an account and acts on that account's data.
  • Dataset Lineage Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Decision Log: Required by. An account signs in and holds the grant that lets it use the register.
  • Document Search: Required by. An account signs in and holds the grant that lets it use its documents.
  • Document Vault: Required by. An account signs in and holds the grant that lets it keep documents.
  • Endpoint Alerts: Required by. An account signs in and holds the grant that lets it use the register.
  • Evidence Register: Required by. Staff recording a claim must hold the grant and a second factor.
  • Governed Workflows: Required by. Every step is authorised against the requesting principal.
  • Grid Asset Registry: Required by. An account signs in and holds the grant that lets it use the register.
  • Incident Timeline: Required by. An account signs in and holds the grant that lets it use the register.
  • Information Request Tracker: Required by. An account signs in and holds the grant that lets it use the register.
  • Invention Disclosure: Required by. An account signs in and holds the grant that lets it use the register.
  • Inventory Tracker: Required by. An account signs in and holds the grant that lets it use the register.
  • Licensing Registry: Required by. An account signs in and holds the grant that lets it use the register.
  • Loyalty Engine: Required by. An account signs in and holds the grant that lets it run a programme.
  • Maintenance Scheduler: Required by. An account signs in and holds the grant that lets it use the register.
  • Outage Coordination: Required by. An account signs in and holds the grant that lets it use the register.
  • Patent Tracker: Required by. An account signs in and holds the grant that lets it use the register.
  • Production Line Registry: Required by. An account signs in and holds the grant that lets it use the register.
  • Publishing and Discovery: Required by. Only staff with the publishing grant may change public text.
  • Quality Nonconformance Tracker: Required by. An account signs in and holds the grant that lets it use the register.
  • Research Log: Required by. An account signs in and holds the grant that lets it use the register.
  • Review Moderation Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Risk Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Sentinel: Required by. An account signs in and holds the grants that let it state rules and screen snapshots.
  • Storefront Content Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Supplier Quality Register: Required by. An account signs in and holds the grant that lets it use the register.
  • Trade Surveillance Case Review: Required by. An account signs in and holds the grant that lets it use the register.
  • Transaction Alert Review: Required by. An account signs in and holds the grant that lets it use the register.
  • Workforce Register: Required by. An account signs in and holds the grant that lets it use the register.

Where it runs

Supported targetA customer-controlled Linux host on x86-64 with PostgreSQL 18 (linux-x86_64-customer-controlled).
Not yet supportedWindows, macOS, phones and tablets, and Linux on other architectures. Each needs its own installation, update and recovery evidence before it is supported.
Check a deviceRun rjv2 preflight on it. It reads the operating system, architecture, memory, disk, listen address, configuration, database, database role and schema, changes nothing, and exits non-zero if release 2.0.0-alpha.1 cannot run there.
Installed asOne application and a PostgreSQL database. Installing release 2.0.0-alpha.1 (schema 100) installs every system on this site, including Identity and Access.
DataIt stays in the PostgreSQL database you run. The only outside service the release can use is an outbound mail relay that you configure.
UpdatingA release is a numbered build. The schema is applied by a separate owner step (rjv2 migrate), and the application refuses to serve a schema it was not built for.
Backup and restorerjv2 backup writes a checksummed dump. rjv2 restore restores it into an empty database and checks the checksum, the schema version and the audit chain of every account.
LeavingThe data is in your own database and can be dumped at any time. What you may do with the release is set by the terms on deployment and ownership.
Published
29 October 2026
Revision
1

Last reviewed 29 October 2026.