Accounts and access

This policy sets how people sign in to GOpenCDR, how long they stay signed in, and what they must confirm again before sensitive actions.

A password has at least 15 charactersfloor, counted by code point after NFKC normalisation, with no rules about kinds of characters. It is stored only as an argon2id hash.

After 5 wrong passwordsfloor in a row, an account is locked for 15 minutesfloor.

Anyone may sign in with a passkey alone, since a passkey with user verification is both factors. Root and TLD people who sign in with a password finish with a passkey.

Rule signin.passkey_for_roles.

A root person keeps at least 2 passkeysfloor and a TLD operator at least 1 passkeyfloor, so that losing one device never locks the root out.

A registrant verifies an address with a 6-digit code valid for 15 minutesfloor, or with a link valid for 24 hoursfloor; root and TLD people verify with the link only. An address gets at most 5 wrong codes per 24 hoursfloor, counted by its keyed hash whether or not an account has it. A password reset link is valid for 1 hourfloor.

A registrant's session ends after 7 daysfloor without use and after 30 daysfloor at most. A session of anyone holding a root or TLD role ends after 30 minutesfloor without use and after 12 hoursfloor at most.

Every root change, from a proposal or an invitation to an approval or a role grant, needs a passkey confirmation from the last 5 minutesfloor, and so do rollovers, new API keys, votes, emergencies, and nameserver and DS changes made in a browser. An API key cannot confirm with a passkey, so it never carries any of these but nameserver and DS changes.

An API key names what it may do and lives at most 400 daysfloor. Its secret is shown once and stored only as a keyed hash.

An API key never carries a root permission, never decides an approval and never manages keys.

Rule api_key.no_root. Limits: A non-negotiable.

Every action names the permission it needs, and each permission names the roles that grant it, whether the address must be verified first, whether an API key may carry it and whether it needs a passkey confirmation. Code sets the widest and the narrowest grant each permission may ever have; the grants in force sit between them.

Rule access.grants.

A policy may define a role made of existing permissions, never more than its author's scope may grant, and may ask for a passkey confirmation on more actions, never on fewer.