Identity schema design: separate profile data, authentication, and permissions

Design an identity schema around three questions: what does an attribute describe, does authentication depend on it, and can it affect access? For each attribute, define its purpose, who may change it, and what a change should trigger before translating the model into validation rules or registration forms.

Separate these responsibilities even when they involve the same value. The goal is an explicit authority boundary, not necessarily a separate datastore for every kind of data.

Start with an attribute inventory

Ory’s documentation for Identities in Ory Network describes JSON Schema as the mechanism for accommodating different user-data models. Its examples include customers with billing addresses, users with multiple email addresses, and support staff assigned to cost centers. These examples illustrate flexibility—not a requirement to put every possible attribute on every account. Ory Identities introduction

Start with an inventory organized around purpose rather than a universal profile. For each proposed field, record:

• Purpose: Which feature or workflow needs it?
• Authority: Which person or system supplies the authoritative value?
• Writers: Which self-service, administrative, or integration paths may update it?
• Requiredness: At what point in the account lifecycle must it exist?
• Consumers: Which interfaces, workflows, or access decisions depend on it?

For example, an application might use the following ownership boundaries. These are illustrative design choices, not Ory defaults or configuration syntax.

Data	Intended purpose	Proposed update authority	Boundary to document
Display name	Personalization	Account holder	Not evidence of access rights
Billing address	Billing workflow	Approved billing update path	When it becomes required
Contact email	Communication	Account holder through a defined change flow	Whether authentication workflows also use it
Staff cost center	Organizational classification	Administrative or workforce system	Whether access policy consumes it
Document-reader relationship	Resource access	Permission-management workflow	How grants and revocations occur

If a field has no clear purpose or owner, defer adding it. If two workflows assign different meanings to the same field, resolve that ambiguity before choosing its name and type.

Define authentication meaning separately from data shape

The Ory Identities introduction lists self-service login and registration, account verification, recovery, and profile-management flows. Review schema decisions across those workflows, not only at account creation. Ory Identities introduction

For an email attribute, answer separate questions:

1. Is it a contact address, a sign-in identifier, a recovery destination, or some combination?
2. What establishes ownership of the address?
3. Who may replace it, and through which workflow?
4. If your design includes a pending replacement, how should dependent workflows behave during that interval?

Document the answers as authentication requirements. Do not assume that naming a field email establishes its credential role, verification state, or change policy.

Likewise, keep descriptive organizational labels distinct from evidence that an account has completed an authentication step. Give each concept an explicit meaning rather than overloading a convenient profile field.

Keep permission authority distinct from profile editing

Ory Keto’s documentation describes fine-grained permissions, such as a user belonging to the readers of a document, and permission inheritance through groups, roles, and hierarchies. This offers a useful contrast with the customizable account data described in the Identities documentation: model access relationships deliberately rather than treating them as ordinary personal details. Ory Keto introduction · Ory Identities introduction

Use that distinction as an architectural guide: a profile update should not silently become a permission grant.

For example, if a cost-center attribute is merely descriptive, keep access decisions independent of it. If policy intentionally depends on cost center, designate a trusted writer and specify how a change affects access. Do not expose that authoritative input through an unrestricted personal-details editor.

For any attribute used by access policy, review every write path—not just the profile form. Include administrative tools and integrations in the authority model.

This recommendation does not require Keto or a particular database layout. The important boundary is who can change the information that determines access, and where the application evaluates it. Specify those controls separately from the field’s validation rules.

Specify behavior across the account lifecycle

Ory’s documentation describes self-service updates to personal details and email addresses, as well as administrative APIs for importing, updating, and deleting accounts. Consider these distinct paths when designing the account model. Ory Identities introduction

Write a lifecycle contract for each important attribute:

• Registration: Require the information needed at this stage. Decide explicitly which details can be collected later.
• Import: Define mappings from existing records, including how to handle missing, ambiguous, or invalid values. Avoid inventing placeholder values merely to satisfy a proposed requirement.
• Self-service updates: Specify which changes are permitted and which authentication or ownership checks they require.
• Administrative updates: Document administrative authority separately from ordinary profile editing. Identify downstream workflows that must react to changes.
• Deletion: Assign responsibility for related application records and permission relationships. Verify cleanup behavior in each system rather than assuming identity deletion performs every operation your application needs.

Use this contract to review proposed required fields. Before making a field required, explain how both a newly registered account and an imported older account will acquire a valid value through an approved path.

Plan schema changes and interfaces together

The Ory Identities documentation offers the Account Experience in Ory Network or the option to build a custom interface. Treat the identity model and its user interface as related design tasks rather than assuming a schema definition settles every interaction detail. Ory Identities introduction

For each change, review the registration form, profile editor, administrative tooling, and import process. Decide how each should display, collect, or omit the affected data—and enforce the intended update authority through each path.

Before writing production configuration, confirm the JSON Schema dialect and keyword behavior supported by your implementation. Before rollout, evaluate representative existing records against the proposed rules and plan how incompatible records will be handled. Use the documented deployment procedure rather than assuming a migration mechanism.

Finish by tracing three scenarios: an account holder changes an email address, an administrator imports an older account, and a document-reader relationship is revoked. For each, identify the authoritative writer, applicable validation, dependent workflows, and expected result. Record these decisions alongside the schema; do not leave them implicit in a registration form.