Human scope issuance
Source checkpoint: f6d01fcc697ebe1756e859c27c792895f7ca7fdc, merged with main at 039bc8ece09b99a28b163b22cac1534d1c112e59. Authority sources are unchanged after the final main merge 5392fe44261405a832a959198587a937e284302c. Re-verify with the owner commands below. This contract describes source behavior; no estate deployment or live role assignment is established here.
Authority applies one compiled human-role resolution contract to interactive authorization-code login and password grants. The accepted scopes are the intersection of the request, the client’s allowedScopes, and the union of the recognized user-role bundles. Output is distinct and ordinally sorted. A missing or empty client ceiling grants no scopes, including for administrators. The persisted AllowedScopes list is the ceiling, matching authorization-code and refresh redemption. The properties.allowedScopes mirror cannot widen it, and an empty persisted list never falls back to metadata.
The four professional bundles retain their existing scopes. Multiple recognized roles compose additively, independent of role order. Unknown roles contribute no product scopes, including when combined with a recognized role. A user without a recognized role can receive only requested and client-permitted openid, profile, email, and offline_access; these identify the session and do not authorize a product operation.
The existing administrator families retain requested, client-permitted grants. The existing developer and viewer families keep their bounded bundles. The four compiled Scanner roles receive exactly their published Scanner grants. Custom role rows remain catalog/editor state: assigning arbitrary scopes to a custom role does not authorize token issuance.
Additive approval and enrollment roles
| Role | Product scope | Purpose |
|---|---|---|
role/release-approver | release:publish | The existing Release Orchestrator release approval route. |
role/decision-signing-enrollee | authority:signing-keys.enroll | The existing enrollment contract for the user’s decision-signing key. |
These are independent compiled grants. Neither role grants administration, approval-policy changes, Policy exception approval, or gate bypass. Enrollment does not create a key, establish signer trust, or bypass downstream signing, fresh-authentication, tenant, expiry, or separation-of-duties checks.
Ordinary interactive login always omits release:gate-bypass, including for an administrator. Password requests without a scope use the client’s ordinary default scope set and then the same human-role intersection. Existing exclusions for operation-bound scopes remain in effect. Explicit administrator password operation requests still pass the existing scope, metadata, MFA and assurance validators. CCP-082 adds a final issuance refusal for unbound gate bypass across password, service and refresh grants. The separate fresh gate-operation flow requires verified upstream authentication and binds one exact exception; its source qualification and future live acceptance remain distinct from the earlier role-resolution checkpoint above.
Proposed acceptance assignments
These assignments describe a later operator-approved acceptance setup; this source change provisions no account, assignment, scope ceiling or key.
| Acceptance identity | Proposed compiled roles |
|---|---|
ccp-acc-release-approver in default | role/release-operations-steward, role/release-approver, role/decision-signing-enrollee |
ccp-acc-exception-approver in default, enrollment prerequisite only | role/security-risk-manager, role/decision-signing-enrollee |
The first identity remains subject to the approval route’s tenant and separation-of-duties rules. The second identity cannot obtain release:gate-bypass from these roles. That capability needs the separately reviewed operation-bound flow and its exact identity, approval context and client ceiling. Do not substitute exceptions:approve or a Policy code-owner role for the Release Orchestrator gate-exception contract.
The operator must approve the concrete usernames, tenants, client permissions, signing-key enrollment and deployment separately. Existing bearer and refresh tokens are not retroactively narrowed by this source change. The existing token redemption and revocation policies continue to apply; use fresh login for the acceptance evidence.
Verification
The owner tests invoke the interactive sign-in method and the password validation and issuance handlers with isolated identities, then inspect the resulting principal scopes. Run tools/scripts/test-targeted-xunit.ps1 with project src/Authority/StellaOps.Authority/StellaOps.Authority.Tests/StellaOps.Authority.Tests.csproj, -Method '*HumanScopeIssuance*' and -BuildProjectReferences. Adjacent password, authorize and Console role-catalog tests cover the existing operation validators and published base bundles. This evidence establishes source behavior, not a deployed estate or completed signed-approval journey.