generated from coulomb/repo-seed
76 lines
3.2 KiB
Markdown
76 lines
3.2 KiB
Markdown
# 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.
|