Protocol-specific credential keys, in any casing, added on top of the base vocabulary.
The personal-data tier; omit it to redact credentials alone.
The second vocabulary tier createRedaction accepts, declared APART from the credential keys because it answers a different rule: a credential must never reach a log because it opens an account; a personal-data field must never reach one because the user typed it, and a diagnostic report pasted into a public issue reproduces it.
Optional ReadonlypersonalDataKeys?: Iterable<string, any, any>User-entered or identifying fields the SDK names on its wire — a
device's display name, an account holder's name, a postal address —
in any casing. Blanked exactly like a credential wherever they ride
(request and response bodies, headers, params, URL queries, the
thrown HttpError snapshot). The core knows no wire's field names,
so this tier is EMPTY unless the SDK fills it, and the credential
tier never depends on it: an SDK passing none redacts exactly what
it did before.
The bound redaction engine.
Builds the Redaction engine for one protocol vocabulary. The mechanism is owned here; the vocabulary is the caller's — the consuming SDK passes every key that names a credential on ITS wire, and the engine unions them with BASE_SENSITIVE_KEYS. A second, separately declared tier names the user-entered fields the same wire carries (RedactionOptions.personalDataKeys); both tiers blank the same way, through every seat the engine reaches.