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. 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.

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.