Documentation embedded in this build.

How policy and missions fit together

The console shows the authorization map from two directions, and they meet at exactly one point. Policy (/ui/policy) asks "what does this operation demand of a caller?" Missions (/ui/missions) asks "what does this mission mean, and who can reach it?" Both are toured page by page in The console, page by page. The point where the two meet is a requirement's mission clause — one line on a policy page, an entire record on the missions page, the same fact both times.

An operation's requirement is an AND of clauses

Every operation this server enforces from carries a requirement — x-authbox in the shipped OpenAPI document — and a requirement is a small AND of up to four clauses, checked in this order:

1. public — any subject whose certificate this deployment accepts. Short-circuits the rest; authentication is still required, public is not anonymous.
2. group — direct membership of one named group. Does not roll up: a member of a subgroup does not satisfy it.
3. attribute — one or more constraints on the subject's own attributes, held in its own right.
4. mission — the subject must currently hold the named mission.

An operation that declares none of these denies everything; deny-by-default is not a fallback. A signature requirement, where one exists, is checked separately, after authorization succeeds — it is not part of the decision above.

A mission clause has two ways to be satisfied

This is the part the policy page states in one line and the missions page spends a whole record on. A subject holds a mission one of two ways, and it is a union, never a replacement of one by the other (plan 061 §1):

• Through a group. A group can bind a mission — carry it in its own missions: [...] list — and every direct member of that group holds every mission the group binds. No window of its own: the binding lasts as long as the membership does.
• Through a grant. A person or service can be handed the mission directly, for a bounded window, through the ask → approve → accept flow Asking for access walks: you find it, you ask, someone with the authority assigns a window, you accept with your own key. When the window closes, the grant stops counting — but a subject who also holds the mission through a group keeps it regardless, because the two routes are independent facts about the same subject.

A mission reachable both ways is credited to the group when a request is decided, because that is the more permissive answer: crediting the grant instead would make a permit expire out from under a subject whose group membership alone would still carry it.

Either way, the mission's own restrictions still apply

Holding the mission — by either route — is not the end of the check. A mission carries its own validity window and its own restrictions (attribute constraints, written in the identical grammar a requirement's own attribute clause uses), and both are checked on top of whatever the requirement demanded directly. A requirement's own attribute clause and a mission's restrictions are never the same check twice: the first is something the operation itself insists on regardless of mission, the second is something the mission insists on regardless of operation.

 operation                     mission
     |                            |
     v                            v
 requirement                 validity window
  (an AND of)                 restrictions
     |                            ^
     +-- public                   |
     +-- group ------------------ | (subject is a direct member,
     +-- attribute                |  group binds the mission)
     +-- mission ---------------- + (subject holds a grant of it,
                                       independently, on its own window)

Where each fact lives

• What an operation demands is reviewed on Policy (/ui/policy) — read-only, because it lives in a shipped document, changed by a diff somebody reads. Toured in The console, page by page.
• What a mission means, who it is classified for, and which groups bind it is on Missions (/ui/missions) — writable, because a mission's own record is store data, not specification. Also toured there.
• How a project authors its own missions is Your project's own missions.
• How a person gets a grant of one is Asking for access.
• The design argument for the policy browser itself is plan 047 §3; the union rule above is plan 061 §1.