OneNymRegister personal data
Register an address through the authenticated Vault API. It stores encrypted data and returns an unpredictable proxy ID. Design the input and integration path so addresses are not also retained in application logs or servers.
ONENYM / PRIVACY INFRASTRUCTURE
Personal data.
Separate it from
business systems.
OneNym Address Vault is an API service that encrypts delivery addresses and lets business systems reference them by proxy ID. Only permitted fields are returned to an authorized application.
Data separation / Purpose-scoped APIs / Cloud key management
SEPARATE DATA. CONNECT WORK.Architecture example
Business system
Orders. Customer service. Connected.
Order referenceProducts and historyProxy ID: nym_abc
Connect workflows without directly holding personal data.
↓ Specify a proxy ID and purposeOneNym APIAuthenticate → Authorize → Execute
Personal data vault
Encrypted personal data
AddresspostalCoderecipientName
Use only authorized records and fields.
Keys managed by cloud key services
Azure Key Vault
Separate personal dataLimit data accessReduce copies and retention
01 / HOW ONENYM WORKS
Instead of sharing data,
share a permitted action.
Proxy IDs in your systems. Personal data in the vault.
Use purpose-scoped APIs only when needed.
Reference a proxy ID
Store proxy IDs alongside orders and business records. Knowing an ID alone does not grant access to personal data.
Check purpose and permissions
Verify the requester, tenant, record, fields, and expiry. A declared purpose alone is not authorization.
Execute the permitted action
Authenticate the delivery application and check tenant, order, purpose, fields, expiry, usage and contract eligibility. Permitted fields are returned as plaintext, so recipients must also control storage and logging.
| Aspect | Direct handling of personal data | Separation with OneNym |
|---|---|---|
| Business database | Names, emails, addresses, and business records | Proxy IDs and business records |
| Usage | Retrieve data and process it in the app | Request an action through a purpose-scoped API |
| Retrieval permissions | Often tied to database access | Authorize by record, field, purpose, and expiry |
| If only the database is stolen | Personal data may be exposed depending on storage and permissions | Reduce direct paths from the business database to personal data |
Proxy IDs also require protection. Reducing retention requires addressing existing records, logs, and copies at integration partners.
02 / ADDRESS VAULT
Keep the workflow.
Share less data.
OneNym Address Vault is an API service that encrypts delivery addresses and lets business systems reference them by proxy ID. Only permitted fields are returned to an authorized application.
Business application
Keep the order reference and proxy ID in your business database. A proxy ID is neither the address nor permission to retrieve it. Integrating the API does not remove existing copies; migration and deletion are separate steps.
Authorized delivery partner
Bind the order and proxy ID to a recipient application, fields and expiry. Issue a retrieval token with a usage limit for that order. Possession of the token alone does not authorize access.
Authenticate the delivery application and check tenant, order, purpose, fields, expiry, usage and contract eligibility. Permitted fields are returned as plaintext, so recipients must also control storage and logging.
Deletion, backups, and recovery
Revocation blocks future retrieval. Address deletion clears ciphertext and the wrapped data key from the active record. It does not instantly erase recipient copies or retained backups. A suspended contract blocks normal retrieval while owner cleanup remains possible. Agree backup retention and reapplication of deletions during recovery at onboarding.
03 / TRUST BOUNDARIES
Separate keys. Separate permissions.
Contain the impact of a compromise.
Go beyond encryption. Establish a boundary between stored data
and the services allowed to decrypt and use it.
Business application
Handles proxy IDs and business records.
No direct access to the vault database or keysOneNym API
Who can use which data, and why?
Per-request authorization, usage controls, and audit recordsEncrypted vault
Return only permitted address fields.
Separate access to data from access to keysCLOUD KEY MANAGEMENT
Cloud infrastructure for key management.
The address Vault uses Azure Key Vault to manage its KEK. Separate permission to use the key protecting data encryption keys (DEKs) from database access.
Even if an account is compromised.
A successful login alone does not grant retrieval. Check tenant, record, fields, and expiry.
Even if an integration credential is stolen.
Limit purpose, scope, and usage. Maintain audit records and a revocation path.
Even if stored data is stolen.
Separate ciphertext from decryption permissions. Encryption alone cannot protect data if key-use permissions are also compromised.
Separation reduces risk and potential impact. Plaintext already retrieved, broad administrative access, and compromised decryption services still require additional protections.
Read about encryption benefits and limits →04 / DEPLOYMENT & INTEGRATION
Add an independent data boundary
to existing workflows.
Connect your existing systems to an address Vault on Azure.
agree on storage, administration, and operational responsibilities during deployment.
Deployment architecture example
Existing business environment
Business applications and databases
Proxy IDs / Orders / Products / HistorySeparate OneNym environment
Vault API / Encrypted data / Key management
Purpose-scoped access / Audit logsSeparate service identities, permissions, networks, and administration within the same cloud. A second database alone is not a sufficient boundary.
Choose a workflow
Map the data and its purpose. Start with one workflow.
Validate with dummy data
Test registration, proxy IDs, retrieval, execution, and revocation.
Deploy and integrate
Configure permissions and connect existing applications. Migrate records and address remaining copies.
Agree production requirements
Define monitoring, recovery, deletion, updates, and responsibilities for both parties.
Application integration and migration are required. Architecture, scope, pricing, and operating terms are discussed individually.
Discuss your architecture05 / TECHNICAL DESIGN
Understand the design.
Evaluate the fit.
Identifiers, permissions, encryption, and the data lifecycle.
Explore concrete designs, their benefits, and their tradeoffs.
PROXY IDENTITY
Privacy platform overview →Proxy IDs and tenant isolation
Personal data mappings and boundaries between companies and services.
Read the technical design →TOKENIZATIONPurpose-scoped tokens and revocation
Purpose, recipient, expiry, and reuse limits.
Read the technical design →PERMISSIONSAuthorization and API integration
From referencing a proxy ID to authorizing data retrieval.
Read the technical design →DATA VAULTEncryption, key management, and storage
Cloud key management, decryption paths, deletion, and recovery.
Read the technical design →EXPOSURE TEST / ASSESS BEFORE DEPLOYMENT
Understand your current exposure.
An authorized assessment identifies paths to personal data access, viewing, and export. Findings can help prioritize boundaries and data to separate.
Discuss a security assessment →Agree on authorization and data handling first.
- Agree on scope, methods, timing, and stop conditions
- Prioritize dummy and canary data
- Minimize real-data access and business impact
Detailed assessment methods are discussed during consultation.
LET’S DESIGN YOUR DATA BOUNDARY
Which data can you
stop holding?
Start with your workflows and systems.
Talk to us about storage, integrations, and access design.