Skip to main content

Client Scope & Claim Governance

Summary​

Attribute claim release is a multi-owner, default-deny decision. Definition eligibility, Security policy, native client scope/grant, verified context, and mapper behavior must all agree.

Why It Exists​

A single tokenVisible flag cannot safely decide which client and token surface receives a claim. Independent gates preserve ownership and omit claims when required evidence is missing.

Where It Fits in Keymate​

Attribute Management owns definition and value facts, Security Management owns projection policy, native Keycloak owns scope/grant state, and KEOPS plus the mapper orchestrate and serialize the result.

Boundaries​

This model does not move client allow-lists into Attribute definitions and does not let a successful business request prove runtime or product activation.

How It Works​

Ownership Model​

Attribute claims require agreement across four owners:

OwnerDecision
Attribute ManagementDefinition eligibility, sensitivity and resolved fact
Security ManagementBundle/rule, client, surface, missing/conflict/size policy and confidential approval
Native Keycloak / Client ManagementActive client scope and grant
KEOPS and mapperVerified context, orchestration and token-surface emission

tokenVisible=true satisfies only the first eligibility check. It is not permission to emit, and a definition never contains client include/exclude lists.

Default Deny​

The mapper omits a claim when any required policy, scope/grant, approval, context or safe resolution input is absent. SENSITIVE values are prohibited. CONFIDENTIAL values require explicit policy and surface approval. Collision and encoded-size checks also fail closed.

Access, ID, UserInfo, introspection, refresh and service-account behavior are distinct governed surfaces; evidence for one is not automatically evidence for another.

Diagram​

Current Evidence State​

The immutable AKS image v2026.9.1001 passed the governed exact-image runtime and lifecycle suites. Product Security #257 historically recorded APPROVED_CURRENT_MANAGER_ONLY_PHASE for that tested digest; it is not candidate-specific target authority. CONFIDENTIAL projection remains disabled and deferred to #290.

That historical decision is not the current administration-role contract. Security Management v2026.9.10 retired both dedicated projection roles in !115/!116, and KEOPS #955/!611 consumed the no-dedicated-projection-role contract. The temporary current authorization boundary is manage-realm, realm-local administration, mandatory audit reason, and maker-checker separation. A future scoped gate is deferred under non-blocking Security #309. The isolated-local T901 matrix passed, but it is not a shared-environment or same-digest image observation. The capability remains BLOCKED. The KEOPS #894 fail-closed consumer is released, but its operational result remains UNAVAILABLE without an actual candidate-qualified attestation under the delivered GitOps #429 contract. Admin Console, Console #4279 consumption, and Product Documentation completion remain open. An authorized matching deployment observation is required only for ACTIVE, not signed VERIFIED. GİB is a separate deferred release lane. See Attribute Capability Status.

The current preparation snapshot does not weaken this boundary. Attribute v2026.9.11002 is the contract origin, Attribute #254/!175 v2026.9.12001 is the current released provider, and Migration v2026.9.11001 is a released input. The bounded #180 provider change is released and adopted by Migration. Product deferred AC01 in the current phase rather than approving the candidate 6,000 ms request budget and 3,769 ms database-query ceiling. Attribute #180 remains open at 11/12 with native status Blocked; Migration #209 remains open at 41/41 and #287 at 10/11, both native Blocked. Existing implementation/release/adoption evidence remains valid unless its inputs change. KEOPS #1033 still waits for the release coordinator to consume the new type-only contract. KEOPS #1004 and MR !623 are terminal and v2026.9.12001 passed registry read-back; #1030 is a separate adjacent follow-up. Technical Docs !27 is a merged preparation baseline while #121 remains open at 0/7. Admin Console !966 remains requested-changes, diverged from current develop, and waits for a same-digest real-environment signed ACTIVE receipt. Admin #5079/!991, #5078/!992, and #5082/!994 are terminal merged source integrations but remain unreleased; #5146 is non-blocking. The aggregate stays BLOCKED; the final immutable tuple is blank, so neither VERIFIED nor ACTIVE may be inferred.

Example Scenario​

Scenario​

Two clients request the same eligible identity attribute.

Input​

An assosId definition is eligible for projection. Intranet receives the claim only when its Security rule, native scope/grant, verified selected context, token surface, and safe resolved fact all match. GP Portal receives no claim when any corresponding gate is absent.

Expected Outcome​

The mapper emits assosId only to the client and token surface whose complete release chain passes.

Common Misunderstandings​

  • "Eligibility is authorization." Eligibility is only the first gate.
  • "A runtime DEPLOYED result means the capability is active." Runtime inspection cannot prove product deployment, immutable acceptance, or environment activation.

Design Notes / Best Practices​

  • Keep attribute eligibility separate from client-specific release policy.
  • Govern each token surface explicitly and fail closed on missing evidence.
  • Bind claim evaluation to the same verified selected context used by KEOPS orchestration.
  • Permit an attribute claim for one client while omitting it from another.
  • Prohibit sensitive claims regardless of definition eligibility.
  • Require an explicit approval before projecting a confidential value.

Identity Attributes & Claims

Follow the complete projection decision.

Token Claims & Context

Understand issuance-time claim and context behavior.

Attribute Sensitivity and Data Handling

Review sensitive and confidential release rules.

Attribute Capability Status

Check immutable evidence and remaining gates.

Attribute Capability Verification

Keep runtime state separate from product status.