Access Control

Administer and verify least-privilege access through explicit authority lifecycles for sessions, authenticators, signing keys, step-up, role assignments, revocations, and audit evidence without accepting generic action objects or credential-bearing compatibility payloads.

BUSINESS CASES

Where this module fits

interactive session creation and rotation
session and signing-key inventory
self-service or administrative revocation
authenticator enrollment and recovery
purpose-bound step-up
role assignment
access audit review

PRIMARY CONSUMERS

Who integrates it

security administrators
workspace owners
access-review agents
mobile and workload integration agents

PREREQUISITES

What must exist first

the exact bearer scope, tenant, workspace, and role required by the selected operation
fresh device and session context for interactive credentials
RFC 9421 signing where the executable OpenAPI operation requires it
fresh purpose-bound step-up for sensitive self-service or administrative changes
caller-owned secure storage and redaction rules for access, refresh, recovery, and step-up credentials

RECOMMENDED WORKFLOW

Compose the module safely.

01
ingest live OpenAPI and choose the explicit resource matching the intended security outcome
02
create, introspect, refresh, or revoke a session without mixing credential lifecycles
03
list signing keys before registration or revocation and retain the returned key epoch and evidence
04
obtain a single-use purpose-bound step-up only immediately before an eligible sensitive operation
05
for restricted administration, read current roles and sessions, apply the least-privilege version-bound change, and verify audit evidence
06
discard revoked or rotated credentials and re-read canonical posture before continuing

AGENT INTEGRATION

Machine-use boundaries

A password proves one login factor; a bearer represents one bounded session; a refresh credential rotates one session; a workspace role, API signing key, and step-up token are separate authority checks. No one substitutes for another.
Never place access tokens, refresh credentials, passwords, authenticator seeds or codes, recovery codes, signing private keys, step-up tokens, or session credentials in URLs, prompts, analytics, generic action objects, or legacy compatibility bodies.
Session issuance is not account activation, refresh success invalidates the submitted refresh credential, revocation is not deletion, signing-key registration is not a bearer grant, and step-up authorizes only one documented purpose for a short bounded window.
Immediately stop using revoked, expired, rotated, or superseded sessions and keys. After an ambiguous security mutation, re-read canonical sessions, key metadata, authenticator posture, and audit evidence before deciding whether an exact retry is safe.
Administrative role and session plans remain non-executable until they appear in live OpenAPI and must preserve tenant isolation, least privilege, last-owner and lockout safety, version concurrency, attribution, and immutable audit history.
Treat POST /api/v2/identity/validate and POST /api/v2/identity/mobile/{session,refresh,revoke,security} as bodyless 501 migration markers. Use the implemented canonical GET /me, /auth, /security, and authenticator operations named in their guidance.
Access Control cannot grant or modify trading, matching, prediction execution, ingress, publisher, allowlist, market status, suspension, settlement, payment, or traffic authority while those controls remain frozen.

Register only production-listed routes as executable tools, and re-fetch the deployed OpenAPI before generating or sending a request. Source-ready routes awaiting deployment are preparation references; planned contracts are non-executable.

MODULE CONTRACTS

Every mapped endpoint

Each operation states whether its request shape is authoritative in OpenAPI, reviewed as a planning profile, or intentionally left as an outline pending an owner schema.