OneNymProxy IDs and tokens
Reference orders and members.
Reduce direct storage of personal data.
ONENYM PLATFORM / TECHNICAL DESIGN
Perform the necessary action,
without sharing personal data.
Move away from duplicating personal data across companies,
toward executing permitted actions with limited access.
OneNym Platform combines proxy IDs, tokens, authorization, and a separate vault. Its design separates personal data from business systems and limits use to necessary purposes.
01 / ARCHITECTURE
Separate identity, permissions, and data.
Business systems handle proxy IDs and tokens. Retrieval and processing pass through independent authorization. Keep personal data in a separate vault and reduce copies across systems.
Request an action
↓
↓
Permitted actions only
Verify requester, purpose, record, and expiry.
Reject requests outside the grant.
Limit to necessary information
↓
↓
Data vault
Manage personal data and mappings.
Return results or limited fields.
Conceptual diagram. Mappings between proxy IDs and personal data also require protection as sensitive information.
02 / FOUR COMPONENTS
Reduce exposure through design.
01 / PROXY IDENTITY
Proxy ID
Reference a person through service-specific identifiers instead of personal data. Separate IDs across services reduce opportunities for correlation and tracking.
Considerations: tenant and service isolation, unpredictable IDs, rotation, deletion, and restricted mapping access.
02 / TOKENIZATION
Tokenization
Use purpose-scoped reference tokens instead of addresses or emails. Manage permitted actions, expiry, and usage limits.
Considerations: stolen-token abuse, reuse limits, revocation, and who can resolve a token. Simple hashing does not make data anonymous.
03 / PERMISSIONS
Access permissions
Check conditions for each operation, such as allowing company A to use this order's address once for delivery. Verify who may handle which data and for what purpose, beyond login status.
Considerations: tenant isolation, purpose, scope, expiry, revocation, administration, and audit trails. Technical permission is distinct from consent or contractual grounds.
04 / DATA VAULT
Data vault
Separate personal data from business records and expose it only through restricted paths. Design encryption, key management, administration, backups, and deletion together. Use cloud key services such as Azure Key Vault or AWS KMS according to the deployment environment.
Considerations: key and data separation, tenant boundaries, recovery, availability, audit records, and retention. A centralized vault can become a valuable target.
03 / INTEGRATION EXAMPLE
Request delivery without storing the address.
A design example for a retailer and delivery provider. Provider integration, data custody, and grounds for use require separate design and agreement.
Register required data in the vault
Register a delivery address and return an order-related proxy ID to the retailer. Design an input path that avoids the retailer's servers and logs.
Issue a purpose-scoped token
Limit a token to the order, carrier, and expiry. The retailer passes the token instead of the address.
Authorize the delivery provider
Authenticate the provider and validate the token scope. Return only the permitted delivery data.
Apply expiry and revocation
Stop future access when a grant expires or is revoked. Deleting addresses already retrieved depends on the provider's operations and agreements.
Example records retained by the retailer
Order ID, proxy ID, delivery token, and delivery status.
Example data with reduced direct retentionName, postal code, and address. Determine separately what billing and customer support must retain.
TECHNICAL DEEP DIVE
Explore implementation-level designs.
Read concrete examples of identifier mappings, authorization, encryption keys, and deletion.
PROXY IDENTITY
Proxy IDs and tenant isolation
Separate identifiers from personal data and establish boundaries by tenant and service.
Read the technical designTOKENIZATIONPurpose-scoped tokens and revocation
Pass references instead of data, limiting records, recipients, purposes, and expiry. Separate possession of a token from permission to retrieve data.
Read the technical designPERMISSIONSAuthorization and API integration
Authentication identifies the requester. Authorization determines permitted actions. Check the record and purpose for each operation.
Read the technical designDATA VAULTEncryption, key management, and storage
Store personal data separately and restrict decryption paths. Design storage, use, deletion, and recovery as one lifecycle.
Read the technical design04 / LIMITS AND CONSIDERATIONS
Reducing retention is only part of the solution.
Proxy IDs need protection too
IDs and tokens that identify or link to a person are not automatically anonymous. Manage storage and access appropriately.
Retrieved data may remain
Revoking access does not erase copies or logs already created. Partners need retention and deletion policies.
Availability and responsibilities
Agree on outage impact, recovery, responsibilities, data location, and retention during deployment.
Design decisions before implementation
Define authentication, authorization, keys, audit logs, retention, deletion, failure behavior, and migration. APIs and integration scope depend on the system and workflow.
FROM EXPOSURE TO ARCHITECTURE
Start by understanding your data flow.
An Exposure Test can assess current paths to personal data.
Contact us to discuss reducing data retention.