DROP Identifier Standardization and Hashing
Matching is only as good as standardization. Identical consumers produce different hashes when normalization rules differ, and the failure is silent.
DROP matching workflows generally rely on identifiers standardized to a specified format, encoded as UTF-8, hashed with SHA-256, and represented in Base64. Some list types use composite hashes combining multiple identifiers.
Why standardization dominates accuracy
A hash function amplifies any difference in its input. " Jane.Doe@Example.COM " and "jane.doe@example.com" are the same consumer and completely different hashes. Every normalization decision — trimming, case folding, punctuation, phone formatting, date formats, ZIP length — has to be written down and applied identically everywhere.
A working specification checklist
- One written rule per identifier type, versioned alongside your code.
- Explicit encoding: UTF-8 in, SHA-256 over the bytes, Base64 out.
- For composite values, an explicit field order and separator, documented and tested.
- Golden test vectors — known inputs with known expected outputs — in your test suite.
- The same specification applied in every system, not reimplemented per team.
Validate representative outputs in the DROP Sandbox before production. Untested hashing fails as under-matching, which produces no error message to investigate.
Confirm the exact standardization rules and composite definitions for each list type against current official DROP technical documentation before finalizing your implementation.
This page describes CA DROP Broker's operational reading of publicly available California materials. Verify current requirements against official CalPrivacy sources and with qualified counsel.