Token Structure

A token carries identity, policy, and metadata fields. Fields are organized by concern and annotated with mutability:

• Fixed — set at creation, never changes. The security-critical identity fields fall into this category.
• Adjustable — may be modified at runtime via the adjustment operations defined in this specification.
• One-way — can be set or tightened but never cleared or loosened.

§4.2.1 Identity core (fixed) #

The set of group SIDs on a token is fixed at creation — AdjustGroups MUST NOT add or remove SIDs. However, individual groups MAY be enabled or disabled by modifying SE_GROUP_ENABLED, subject to constraints: mandatory groups (SE_GROUP_MANDATORY) MUST NOT be disabled, and deny-only groups (SE_GROUP_USE_FOR_DENY_ONLY) MUST NOT be re-enabled.

A token MUST contain at most 1024 entries in its groups array, including the kernel-injected logon SID. CreateToken therefore accepts at most 1023 caller-supplied groups.

§4.2.2 Token type (fixed) #

§4.2.3 Integrity (fixed) #

The mandatory_policy field is immutable. A process MUST NOT change its MIC constraints at runtime (neither loosen nor tighten).

§4.2.4 Privileges (adjustable) #

A token MUST carry a set of privileges. Each privilege MUST have four independent states:

• Present — the privilege exists on the token. A present privilege MAY be removed (permanent), but a privilege MUST NOT be added after creation.
• Enabled — the privilege is currently active. Only present privileges MAY be enabled or disabled.
• Enabled by default — the creation-time enabled state. AdjustPrivileges MAY restore all privileges to this state.
• Used — the privilege has been exercised during this token's lifetime. Monotonic — once set, MUST NOT be cleared.

A privilege's lifecycle on a token: present and disabled → enabled → used → optionally disabled → optionally permanently removed. Removal clears the privilege from the present, enabled, and enabled-by-default states.

§4.2.5 Elevation (one-way) #

Linked token pairs are associated at the session level, not stored on individual tokens. See §4.6 for the pairing mechanism.

§4.2.6 Default object security (adjustable) #

§4.2.7 Metadata (fixed) #

§4.2.8 Mutation tracking (adjustable) #

Privilege-used accounting is audit/accounting state, not an access-decision input. Marking a privilege used MUST remain monotonic, but it MUST NOT bump modified_id.

§4.2.9 Session (adjustable) #

§4.2.10 Claims and security attributes (fixed) #

§4.2.11 LCS registry credentials (fixed) #

These fields are KACS-owned credential material for PSD-005. They are fixed at token creation and copied by token duplication and filtering. Attachment is authorized by the same trusted-token-minting gate as the rest of CreateToken: only a caller holding SeCreateTokenPrivilege can create a token carrying these fields.

§4.2.12 Device identity (fixed) #

§4.2.13 Confinement (fixed) #

§4.2.14 Audit (fixed at creation) #

Audit policy flags:

Follows impersonation: if service A impersonates client B and client B's token has auditing enabled for a category, operations during impersonation are audited under client B's identity. Default value at creation: 0 (no per-token audit overrides).

§4.2.15 Credential projection (fixed) #

Computed by authd at token creation time, stored on the token. KACS MUST NOT resolve SID-to-UID mappings at runtime. Projection reflects all groups regardless of enabled/disabled state — AdjustGroups MUST NOT trigger projection recalculation.

§4.2.16 Token security (adjustable) #

§4.2.17 Internal #