generated from coulomb/repo-seed
tegwick
1c1b5c9bc6
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
93 lines
4.0 KiB
Markdown
93 lines
4.0 KiB
Markdown
# Design Principles
|
|
|
|
Status: draft. Refined after IDENTITY-WP-0003 corpus backfill. 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. After corpus backfill, all fifteen scenarios in
|
|
`scenarios/ScenarioTests.md` have explicit representation paths in
|
|
`model/ConceptualModel.md`.
|
|
|
|
## P12. Distinguish Assurance Dimensions
|
|
|
|
Identity proofing, authentication, and federation assurance are separable
|
|
dimensions (NIST IAL, AAL, FAL). Do not collapse them into a single "trust
|
|
level" on an account. Record assurance metadata on bindings, credentials, and
|
|
federation relationships where sources provide it.
|
|
|
|
## P13. Prefer Non-Destructive Linking
|
|
|
|
Entity resolution, federation account linking, and semantic web equivalence
|
|
patterns should produce Synonymity Assertions, not silent record merges.
|
|
Probabilistic matches default to weak strength with review lifecycle. Deterministic
|
|
and verified matches may be strong but remain scoped and revocable.
|
|
|
|
## 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.
|