An organisation's administrator
Give an organisation its administrator safely: the role goes to exactly the person it is meant for, proved by their mailbox, a code handed over in person, and a record on the organisation's domain.
An organisation’s administrator can change everything about it, so the role is given only to the person it is meant for, and nobody else can take it on their way: not the server’s operator, and not someone who reads one message. The person proves three things at once, then chooses their own password and adds a passkey before the role is theirs.
The three proofs
| Proof | What it shows |
|---|---|
| A one-time link, emailed to the address named | They receive that address’s mail. |
| A short code, handed to them by whoever set the claim up, in person or by phone | The person setting it up chose them. The code is never in the email. |
A TXT record on the organisation’s domain, _versealx-admin-claim. and the domain | They control the organisation’s domain. |
All three are needed, within 24 hours. A wrong answer never says which proof was wrong, and five wrong answers end the claim. One claim is open at a time.
Setting one up
When you make a new organisation, name its domain and its administrator’s address, and the claim starts with it:
versealx-server admin post tenants name="Example Ltd" domain=example.com admin=ada@example.com
Or start one later, for an organisation that has its domain:
vsx admin admin-claim start ada@example.com
vsx admin admin-claim show
vsx admin admin-claim revoke
The answer shows the code and the DNS record once. Give the code to the person yourself, and either publish the record or ask them to publish it. The link goes to their address on its own; you never see it.
On the console: Access › Set up the administrator.
Once an organisation has an administrator, a claim for another one made by anybody else, the operator included, waits for an existing administrator to approve it.
Taking it
The person opens the link from the email, which brings them to the server’s page /account/admin-claim, and types the code. The server looks the record up on the domain itself. Then:
- A new account: they choose their own password (the organisation’s rules and the leaked-password check apply), type it once more, and add a passkey with their fingerprint, face or device PIN.
- An account that already exists: they sign in with their own password and second step, then add a passkey if they have none. Their password is never replaced.
The administrator role is granted the moment the passkey is added, and the page says so; the first console sign-in is already a passkey sign-in. Each step is in the audit log, with no secret in it.
Administrators sign in with a passkey by default (see Administrators sign in with a passkey). Where an organisation lets its administrators use an authenticator app instead, the page also offers Use an authenticator app instead; where it allows no passkeys at all, the page asks for an authenticator app.
Over the API
| Method | Path | Purpose |
|---|---|---|
POST | /api/v1/tenants | With domain and admin, also starts the claim; administratorClaim in the answer carries the code and record, once. |
GET, POST, DELETE | /api/v1/tenants/{tenant}/administrator-claim | Where a claim stands; start one with address; take it back. |
POST | /api/v1/tenants/{tenant}/administrator-claim/secrets | The code and record again, once, for a claim an approval let through. |
Something unclear or out of date on this page? Tell us.