Module auth 

Authentication + authorization via Schubert proof-carrying multi-capability grant tokens.

Per docs/DESIGN.md D4 and the GrantToken-migration ADR (docs/adr/grant-token-migration.md), Ijima consumes Schubert 0.4’s GrantToken end-to-end: one signed token carries several capabilities, each with its Schubert partition, and authorization is a geometric containment check (cap_partition ≤ granted_partition, component-wise) that is self-contained in the signed token — no capability registry is consulted for the authz decision, only for the static required-capability → partition lookup.

Consequences of the geometry:

• Write implies read — [2] ≥ [1], so a memory:write grant also satisfies memory:read.
• Admin implies all — [4,4,4,4] (the point class on Gr(4,8)) is ≥ every partition. The legacy == "admin" string short-circuit is gone; admin falls out of the geometry.

The wire format is Schubert’s native GrantToken::to_bytes / from_bytes, base64-encoded for bearer transport. Ijima no longer ships its own token serializer.

Structs

AuthenticatedPrincipal

The authenticated principal + the verified grant carried by a bearer token.

IjimaAuth

Ijima’s auth core: an AccessController (capability → partition resolver) plus a capability issuer and a grant verifier sharing one Ed25519 key, and an in-memory revocation set (the grant kill-switch — see docs/adr/token-revocation.md).

Functions

bearer_hash

Computes the revocation key for a bearer: SHA-256 hex of the trimmed bearer string, with an optional Bearer scheme prefix stripped — so operators (and CLIs) can paste either the raw token or the full Authorization header value and hit the same revocation key. Storing hashes instead of raw bearers keeps live credentials out of store dumps, logs, and backups.