Proxy IDs and tenant isolation

Managing identifier mappings

Assign proxy IDs to tenant_id, service_id, and internal-person-reference combinations instead of exposing internal IDs. Use separate proxy IDs across services to reduce cross-service correlation.

tenant_id

Company boundary, derived from authenticated client context.

service_id

The service within a tenant. Do not reuse its IDs in other services.

proxy_id

A random external identifier with no name or email embedded.

subject_ref

An internal vault reference to the person. Exclude it from business-system responses.

status / version

Active or inactive state and a version for concurrent updates.

Issue, rotate, and delete

Confirm the authenticated tenant and service, check mappings, issue secure random IDs only when needed, and prevent duplicates with unique constraints and transactions. Reject disabled references and delete mappings according to retention policy.

Concurrent issuance

Concurrent registration requests must not create duplicate mappings.

ID rotation

Revoke old IDs, activate replacements, and migrate historical references.

Deletion

Distinguish proxy-ID revocation from data deletion. Address backups and audit records separately.

Knowing an ID does not grant access

A proxy ID is not a credential. Verify tenant, service, and record permissions server-side on every request. Changing an ID must not expose another tenant's record.

Reject cross-tenant lookups

Require the authenticated tenant_id to match the mapping's tenant_id.

Separate the mapping store

Business-database access must not also grant access to personal-data mappings.

Authority to link identities

Linking identifiers requires stronger authorization and audit records than ordinary lookup.

DATA / INTEGRATION EXAMPLE

Data and integration example

These samples explain the design. Field names and values are illustrative, not an executable API reference.

{
  "operation": "Proxy ID issuance and lookup example",
  "request": {
    "service_id": "shop-a",
    "registration_ref": "reg_example_01"
  },
  "response": {
    "proxy_id": "nym_example_01",
    "status": "active"
  }
}

registration_ref is issued by the vault registration process. This is not identity matching or anonymization based only on email hashes.

Related technical designs

Integration designed for your workflows.

Map retained data, partners, and required actions to identify ways to reduce exposure.