Grant temporary access

An external contractor should check inventory data for two weeks. They get no access to the corporate network, only to this one database, read-only, and after the two weeks nothing should be left that still works.

The contractor becomes a person with their own rule and a time-limited key. If they should work only at agreed times, the key rests and is activated on demand.

1. Create the person (Persons, name with company) and have the second factor set up (enroll-totp with "delivery": "mail").
2. Assign a rule, read-only and only on the necessary views (see rights per object).

3. Issue the key, time-limited and resting if wanted:

   { "person": "Contractor – Company X", "label": "Inventory check", "expiresAt": "2026-11-06T00:00:00Z",
     "readOnly": true, "databases": [ "lager" ], "onDemand": true, "delivery": "mail" }

4. Activate for a working day: activate-key with { "id": "k…", "hours": 8 }; end early with deactivate-key.
5. Check: explain-sign-in for the person shows the key outside an activation as rests; PersonalKeys shows Status “ruht” (rests) or “frei bis …” (active until …).
6. At the end, disable the person (Enabled = false). Once a person has left traces they can't be deleted; that keeps the log traceable as to who did what.

Result: The contractor reaches only the inventory data, read-only, only in activated hours, and at the latest until November 6.

• Expiry without action. An expired key opens nothing, even if nobody revokes it.
• Maximum lifetime. No key can be issued for longer than Gateway:Store:MaxKeyLifetimeDays.
• Sign-in rules apply to the contractor too; if a rule names countries or networks, check their origin with explain-sign-in.

• HTTP: sign-in—on-demand keys
• Respond to a lost device
• Zero Trust and private devices