Launch on 01/01/2027Licenses available from 01/01/2027
PreviewThis page documents the release that launches on 01/01/2027. Packages, images and sign-up open then, and details may change before it.
Docs / Guides / Manage RPs & users

Manage RPs & users

Ready
TL;DR

Management has two planes. As the operator you create relying parties, sign their certificates, and watch deployment-wide health and usage. As a relying party you manage your own opaque users and their devices over the API — create, lock, delete; revoke or ban a device. Everything is audit-logged, and nothing bypasses the server.

Who this is for: the operator running the deployment, and the RP engineer managing users in code. Each plane is scoped and separate — an operator provisions tenants; a relying party never sees another’s users.

Two planes#

Who does what is split cleanly by the certificate on the connection.

Sixteen calls, in four bandsWhat an operator may do, ordered by what it costs them to do it.LOOKwhat it costs the operator:no reason requiredListRelyingPartiesGetRelyingPartyDetailsListUsersForRPGetUserDetailsGetDeploymentHealthGetLicenseHeadroomMEASUREwhat it costs the operator:no reason requiredGetStorageFootprintCHANGEwhat it costs the operator:a written reason, loggedAdminResetUserQuotasCreateRelyingPartyUpdateRelyingPartySuspendRelyingPartyReinstateRelyingPartyProvisionRPCertIRREVERSIBLEwhat it costs the operator:a reason, and an explicit confirmationAdminDeactivateDeviceAdminDeleteUserDeleteRelyingPartyEvery call on this port is made with an operator certificate, and every change is written downThe reason is the operator’s own words, up to 1024 bytes, written verbatim into the call’s log line.The confirmation is a separate field that must be set. It exists to survive a mistyped command, not an attacker.
Four bands of admin calls — look, measure, change, irreversible — and what each one reaches.
Operator — the deployment owner
  • Create, update, and delete relying parties.
  • Provision each RP’s mTLS certificate (sign its CSR).
  • See deployment-wide health, usage, storage, and license headroom.
  • Administer users or devices across tenants when you must.

Via the operator CLI on the admin listener.

Relying party — each tenant, in code
  • Create and bulk-create opaque users.
  • Lock, unlock, and delete its own users.
  • List a user’s devices; revoke, ban, or unban them.
  • Read and export its own users.

Via the IdentityService over its own mTLS certificate.

Operator: relying parties#

Onboarding a tenant is two steps — register it, then sign the certificate it authenticates with (the RP generates its own key and CSR, so its private key never reaches you):

Keeping one customer out of another’s dataTwo ways to write the same lookup. Only one of them cannot be forgotten.FETCH, THEN CHECKrow = find(user_id)if row.owner != caller:refusereturn rowOne forgotten line away from a leakThe row is in memory before anybody asks whetherthe caller should have it. Every call has toremember the second step.SCOPE THE LOOKUProw = find(user_id,owner = caller)return rowThe wrong row is never loadedThe caller’s identity is part of the question. Arow belonging to somebody else does not comeback to be checked.And the answer is always the same oneA user that never existed→not foundA user belonging to another customer→not foundA user that existed and was deleted→not foundAnswering “not allowed” would confirm the identifier belongs to somebody — which is the question an attacker was asking.
Two ways of writing a lookup: fetch then check, or scope the lookup. Only one of them cannot be got wrong.
# operator: onboard a relying party, then sign the certificate it will use
$ ydfi admin create-rp acme --max-users 5000
$ ydfi admin provision-rp-cert acme --csr acme.csr
$ ydfi admin list-rps

From there, list-rps, update-rp, and delete-rp manage the roster; every change is audit-logged. See Certificates & PKI for the cert side. The seats you split across relying parties come from your plan — the bands are on Pricing.

Relying party: your users#

Each relying party manages its own users over the API. The calls, and when to reach for them:

Do thisCall
Create a user — one opaque identity per real person (keep the mapping).CreateUser
Onboard at scale — many identities in one server-streamed call, for a migration or a large signup.BulkCreateUsers
Lock or unlock — freeze a user without deleting them.UpdateUserStatus
Delete — remove a user and their bindings for good.DeleteUser
Read / export — look one up, or stream them all out.GetUser · ExportUsers
Clear a rate-limit lock — lift a user’s anti-abuse quarantine after you’ve resolved it. Last resort, not a routine action.UnlockUserRequestLimits
⚠ Critical gotcha

Keep one opaque identity per real individual for their lifetime. To Ydentifi these are faceless records; it cannot detect or merge duplicates, and a second identity fragments a person’s devices and history across unrelated tokens. De-duplicate on your side before CreateUser. See CreateUser.

Devices: revoke vs ban#

ListDevicesForUser shows a user’s enrolled devices. Removing one comes in two flavours, and the difference matters:

  • Revoke (RevokeDevice) — a voluntary deactivation. The user swapped phones, or you’re tidying up. The device can no longer sign; nothing is blocklisted. Revoking does not replace the user’s TOTP secret: the device’s copy keeps giving valid codes until IssueUserTotpEnrollment with reuse_existing false replaces it.
  • Ban (BanDevice) — persistent denial for a compromised or stolen device. It adds the device’s hardware-bound permanent_id to your blocklist and deactivates the active enrollment on that hardware, if there is one (at most one per relying party). UnbanDevice lifts the block, but does not resurrect the old enrollments — the user must re-enroll. A ban does not replace the user’s TOTP secret; if the phone may be in someone else’s hands, call IssueUserTotpEnrollment with reuse_existing false too.

Operator: visibility & usage#

Deployment-wide, the operator plane answers “how is this doing?” without touching any tenant’s data: GetDeploymentHealth for the live snapshot, usage time-series, hour-of-day and action-breakdown analytics, a storage footprint, and license headroom against your caps. All of it reads aggregates — there is no personal data to expose.

ⓘ Everything through the server

Every operation here is audit-logged and enforces its safeguards in the server. Do not reach into the database to add, change, or remove a user or device — use these calls, which keep the audit chain, tenant isolation, and license caps intact. See Operate & maintain.

Relates to
← Previous
Authorize an action
Next →
Deploy
Certificates & PKIEnroll & link devicesAPI referenceOperate & maintain
Opens on 01/01/2027

Available at launch

Until then, you can try the whole ceremony on your own phone.

Try the live demo