Skip to main content

Attribute Sensitivity and Data Handling

Summary​

Sensitivity classification is governed metadata and an input to explicit read and token-release controls. It is not evidence of a general compliance, encryption, retention, or masking capability.

Why It Exists​

Explicit classifications let provider and Security boundaries fail closed without encouraging broad or unsupported product claims about how every deployment stores and processes data.

Where It Fits in Keymate​

Attribute Management owns classification and authorized redaction. Security Management owns projection policy, while deployment-specific infrastructure owns storage and transport controls.

Boundaries​

This page covers evidenced attribute sensitivity and release behavior. Legal conclusions and deployment controls require their own owner, scope, approval, and executable evidence.

How It Works​

Current Evidenced Controls​

Attribute definitions classify sensitivity. Attribute fact reads can redact values when sensitive detail is not authorized. Token projection is fail-closed:

  • The platform prohibits SENSITIVE attributes from token projection.
  • CONFIDENTIAL attributes require an explicit approved bundle/client/surface policy. The current manager-only phase keeps this projection disabled; Security #290 owns any later activation.
  • Missing policy, scope/grant, mapper support, value, or a safe resolution result omits the claim.
  • Values and sensitive provenance must not appear in logs, metrics, audit details or error messages.

Classification is metadata plus an input to these explicit controls. It is not a general compliance certification.

Required Audit Generation and Delivery Limits​

The first-release decision of 15 September 2026 retains value-free audit generation through the existing Event extension for governed Attribute policy operations. Audit must bind the realm, authenticated actor, policy kind/version and scope without including attribute values. A valid GLOBAL ALL policy may omit its public source-owner ID; do not invent an owner to populate audit.

Audit command construction, publisher invocation, actual Event construction/dispatch and durable delivery are separate stages. The existing void publisher does not return a delivery receipt and can tolerate a missing store or swallow persistence/listener failures. A successful policy response must not be represented as guaranteed audit delivery or persistence.

The supported audit-enabled profile must be verified with the actual Attribute factory/service and Event integration. Disabled required admin audit or an unavailable publisher must deny mandatory policy authoring; escaping publication failure must fail the operation with a value-free error and transaction rollback as applicable. Missing-store or swallowed-failure cases provide no delivery guarantee. Do not change global audit settings or use mock invocation as evidence that these cases produced or delivered an event. These checks do not replace the separate writer-epoch/activation fences or change protected token-acquisition audit requirements.

The local Attribute audit correction is not yet qualified for successful writes. Event #148 records deferred Maintenance for explicit, compatible publication-result semantics and staged consumer migration; a non-void result alone is not a guarantee. It is not a new prerequisite for this release and does not expand #147 acquisition-attempt protection. The existing Event path is retained; a new same-transaction final audit-store SPI is not required by this decision. Fresh exact-head consumer tests remain required before acceptance.

Controls Not Established by Attribute Evidence​

No released attribute evidence currently establishes per-definition encryption-at-rest toggles, per-definition transport encryption toggles, UI masking, retention schedules, anonymize-on-delete, or legal-restriction masking. Those claims have been removed from current attribute behavior. Where the platform provides storage or transport protection, document it at the owning infrastructure or protocol boundary rather than inventing an attribute-definition control.

Compliance statements such as KVKK or GDPR conformance require an approved scope, control owner, executable evidence and review/expiry date. A sensitivity label alone is insufficient.

Operational Guidance​

  • Minimize stored and projected personal data.
  • Prefer INTERNAL or stricter classification when uncertain; never weaken a classification to make a token scenario pass.
  • Keep SENSITIVE values out of tokens.
  • Require explicit Product Security approval for every CONFIDENTIAL projection policy.
  • Treat the historical manager-only Product Security decision as a negative boundary, not as positive CONFIDENTIAL authorization.
  • Verify the actual storage, transport, backup and deletion controls of the deployment separately.

Diagram​

Example Scenario​

Scenario​

An application requests a confidential employee attribute in an access token.

Input​

A confidential employee attribute is eligible for an access-token claim. Projection remains denied until a Security-owned rule explicitly approves the client and token surface and the native scope, verified context, mapper, and safe value gates all pass.

Expected Outcome​

The mapper omits the claim until every required gate passes; it never projects a SENSITIVE value.

Common Misunderstandings​

  • "A sensitivity label enables encryption." Classification does not configure infrastructure.
  • "Confidential means allowed." Confidential projection is default deny and requires explicit approval; sensitive projection is prohibited.

Design Notes / Best Practices​

  • Minimize stored and projected personal data.
  • Keep classification, infrastructure protection, and legal assurance as separately evidenced controls.
  • Record explicit Security approval for every confidential client and token surface.
  • Redact a sensitive direct value from an unauthorized administration read.
  • Deny a sensitive token claim even when its definition marks it eligible.
  • Evaluate a confidential claim through Security, scope, context, and mapper gates.

Attribute Definition Model

Understand definition-owned classification metadata.

Identity Attributes and Claims

Follow the independent projection gates.

Attribute Capability Status

Review current evidence and blockers.

Attribute Capability Verification

Keep runtime and product evidence separate.