Permissions and RBAC — Chandra Passport
Source: James, directly — confirming that "gr-identity," referenced in earlier drafts of this chapter and elsewhere in this manual, was an early internal working title for what is now called Chandra Passport. It is in active development and not yet available for beta. Cross-reference: Chapter 10 independently identified Chandra Passport's public-facing role (page-integrity/CU verification for chandrahub.net itself) from the site's own footer text — this chapter and that finding describe the same system from two different angles, now confirmed as one and the same rather than two separate things.
This is the chapter that would resolve Chapter 1's most consequential open gap: request-level authentication and access control. As documented in Chapter 9, the CEE client sends no bearer token, API key, or other credential on any call — only an operator string, which is attribution for the CU chain (Chapter 1), not authentication. Nothing reviewed anywhere in this manual's source material — not the CEE client, not the source zip's Lisp files, not any of the live-fetched sites — describes how a request is actually authorized to act on a given spine.
Chandra Passport is Chandra's RBAC and identity-governance system. It was developed under the internal working title "gr-identity" before being renamed — the two names refer to the same system, not two different ones, and any reference to "gr-identity" elsewhere in earlier drafts of this manual should be read as Chandra Passport under its earlier name. It is in active development and not yet available for beta — a real, in-progress system, not vaporware, but not yet something an operator can point at, install, or verify against.
Chandra Passport appears to have two roles, seen from two different angles across this manual:
principal vocabulary (a distinct authority-bearing signing credential — human, agent, service account, API key, examiner, workflow engine, or integration identity).Whether these are genuinely one unified system serving both purposes, or two related-but-distinct capabilities that happen to share a name, hasn't been confirmed — worth asking directly once Chandra Passport is further along, rather than assuming either way.
No real source (UI, API, or backend code) has been reviewed for Chandra Passport — everything above is confirmed positioning (what it's called, what gap it's meant to close, that it's in development), not confirmed implementation. This chapter should be rebuilt from real source the same way every other chapter in this manual was, once Chandra Passport reaches beta and there's something concrete to verify against. Until then, don't draft operational guidance here based on assumption — a name and a stated purpose are not a specification.