3.2 KiB
Design Principles
Status: draft. These principles make the proposal's modeling stance explicit. They are constraints for canonical vocabulary and conceptual model work, not implementation requirements for downstream systems.
P1. Use Actor As The Participation Root
Do not start the model with user. An Actor is anything that can participate
in relationships, hold accounts, be represented, or be evaluated by downstream
systems. Natural persons, organizations, communities, families, and artificial
agents can all be actors.
P2. Keep Person, Account, Identity, Profile, And Principal Separate
A natural person is not an account. An account is not a profile. A profile is not a credential. A principal is an authorization projection. A subject is an issuer-bound protocol view. These distinctions prevent the most common identity model collapse.
P3. Treat Scope As First Class
Identifiers, accounts, relationships, roles, policies, and meanings are only stable within a scope. A scope may be a tenant, realm, relying party, sector, community, application, namespace, or authorization domain.
P4. Model Collective Actors Without Collapsing Them
Organizations, legal entities, customers, vendors, communities, families, households, groups, and teams are not interchangeable. They may relate to each other, but each should keep its social, legal, operational, or commercial meaning visible.
P5. Model Relationships Explicitly
Membership, affiliation, following, ownership, representation, delegation, administration, employment, guardianship, and trust are separate relationship types. Do not hide them inside groups, roles, or ad hoc attributes.
P6. Keep Authorization Projections Separate
Authorization engines need principals, resources, actions, roles, policies, and relationship tuples. These are projections from the conceptual identity model, not the whole identity model.
P7. Treat Synonymity As An Assertion
Weak matches, verified links, same-as claims, and merges are different. The canon should represent synonymity as a scoped, evidenced, revocable assertion with confidence and method, never as an automatic destructive merge.
P8. Preserve Source And Evidence
Source systems, issuers, import jobs, operators, documents, and verification events matter. Claims and relationships should be traceable to evidence or source references when the model depends on them.
P9. Prefer Orthogonal Concepts Over Product Terms
External systems are mapping targets, not the source of canonical truth. If a product calls something a user, organization, group, project, tenant, or realm, the canon should identify the underlying concept before adopting the label.
P10. Test Concepts Against Scenarios
Every canonical concept should survive concrete scenarios: enterprise directories, vendor/customer tenancy, families, communities, social graphs, service accounts, delegated agents, weak matches, strong links, and pseudonymous profiles.
P11. Keep Implementation Recommendations Downstream
The repository may recommend downstream schemas, APIs, UI flows, or adapters,
but it should not implement them directly. Implementation ideas belong in
DownstreamRecommendations.md or a dedicated downstream workplan.