Skip to main content

Identity Attributes & Claims

Summary​

Keymate separates governed attribute definitions and values from client-specific token-claim release. A claim appears only when definition eligibility, Security policy, native scope, verified context, and mapper behavior all agree.

Why It Exists​

This separation prevents a definition flag or direct value from becoming implicit authorization to disclose identity data to every client.

Where It Fits in Keymate​

Attribute Management owns definitions and values, Security owns projection policy, native Keycloak owns client scopes and grants, and KEOPS orchestrates the verified-context mapper flow.

Boundaries​

This concept does not make the browser a resolution authority, place client allow-lists on attribute definitions, or treat deployment evidence as proof of product activation.

How It Works​

Attribute ownership​

An identity attribute definition uses a stable definitionId and a separate semantic definitionKey. Its subject, governance owner and direct value owner are independent dimensions. Direct values retain their source metadata. Defaults and applicability policies are separate inputs, and an effective value requires server-side resolution of a verified context.

The current public facts endpoint is direct, not inherited. See Attribute Values and Resolution before describing a value as effective.

Claim projection is a multi-owner decision​

tokenVisible=true is eligibility only. The platform emits a custom attribute claim only when every required gate agrees:

  1. Attribute Management reports an eligible definition and a safe resolution result.
  2. Security owns an active projection bundle/rule for the client, claim path and token surface.
  3. CONFIDENTIAL projection has explicit approval; SENSITIVE projection is prohibited.
  4. The client has the native Keycloak client-scope/grant required by the rule.
  5. KEOPS orchestration and the mapper bind the same verified selected context.
  6. Missing, conflict, sensitivity, collision and size policies permit emission.

Failure of any gate omits the claim by default. Attribute Definition never owns a client include/exclude list.

Diagram​

Example Scenario​

Scenario​

An administrator evaluates whether Intranet and GP Portal may receive the governed assosId claim.

Input​

Assume assosId is eligible and has a direct value for the verified user context.

Expected Outcome​

  • Intranet receives the claim only if its Security rule, confidential approval when applicable, active client scope/grant and requested token surface all match.
  • GP Portal receives no claim when it lacks the active rule or scope, even though the same definition has tokenVisible=true.

This is default deny, not an attribute-definition client list.

Current Maturity​

The immutable AKS reference image has passed exact-image runtime acceptance. 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 Security #290. The isolated-local T901 matrix passed but is not a shared-environment or same-digest image observation. The product capability remains BLOCKED with assembly detail ASSEMBLED. 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, and no page may call the current capability ACTIVE. See Attribute Capability Status.

Canonical userType​

ValueMeaning
0Internal user
1, 2, or 3External user categories
explicit ASSOS_SYSTEM identity/typeSystem identity
any other numeric valueUnknown/unsupported; never coerce to system

No numeric userType value creates a system identity implicitly.

Common Misunderstandings​

  • "tokenVisible=true emits the claim." It establishes eligibility only.
  • "A direct value proves the effective value." Only verified server-side resolution can make that determination.
  • "A deployed component makes the product capability active." Product activation requires the complete immutable evidence and environment gates.

Design Notes / Best Practices​

  • Keep stable definition identity, value ownership, resolution, and projection policy separate.
  • Omit a claim whenever any required policy, scope, context, or sensitivity gate is missing.
  • Keep the browser as a renderer of server-owned results, not an inheritance engine.
  • Project one eligible attribute to an approved client and omit it from another.
  • Inspect direct values without presenting them as inherited or effective.
  • Explain why a claim was omitted without exposing sensitive value data.

Attribute Definition Model

Understand definition identity and ownership boundaries.

Token Claims & Context

Review issuance-time context and claim behavior.

Client Scope & Claim Governance

Follow client-specific default-deny release policy.

Attribute Capability Verification

Verify immutable delivery and activation evidence.