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.

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.