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.
194 lines
6.2 KiB
Markdown
194 lines
6.2 KiB
Markdown
# Scenario Tests
|
||
|
||
Status: draft. These are narrative tests for the conceptual model. They are
|
||
not executable tests yet; they define expected representation checks for future
|
||
model revisions.
|
||
|
||
## Test Format
|
||
|
||
- Scenario: concrete identity situation.
|
||
- Expected representation: the canonical concepts that should be used.
|
||
- Checks: conditions the model must satisfy without collapsing terms.
|
||
|
||
## S01. Single Person With One Local Account
|
||
|
||
Expected representation: one Natural Person, one Account in an application
|
||
Scope, one local Identifier, one Profile, and one Membership or access
|
||
relationship if the account belongs to a group.
|
||
|
||
Checks:
|
||
|
||
- The person is not identical to the account.
|
||
- The profile is not the credential.
|
||
- Authorization can project the account or subject into a Principal.
|
||
|
||
## S02. Person With Multiple Accounts Across Scopes
|
||
|
||
Expected representation: one Natural Person, multiple Accounts, one Account
|
||
per Scope, and optional Synonymity Assertions linking account records.
|
||
|
||
Checks:
|
||
|
||
- Each account keeps its source and lifecycle state.
|
||
- Linking accounts does not merge them destructively.
|
||
- Different scopes can use different identifiers.
|
||
|
||
## S03. Enterprise With Sub-Organizations
|
||
|
||
Expected representation: Organization actors linked by structural
|
||
relationships, plus Accounts and Membership relationships scoped to relevant
|
||
systems.
|
||
|
||
Checks:
|
||
|
||
- Sub-organization is not automatically a tenant.
|
||
- Legal entity status is modeled separately.
|
||
- Membership and administration relationships are explicit.
|
||
|
||
## S04. Vendor Tenant Serving Customer Tenants
|
||
|
||
Expected representation: Vendor and Customer relationship roles between
|
||
Organization actors; Tenant scopes for platform isolation; optional
|
||
Administration relationships for delegated support.
|
||
|
||
Checks:
|
||
|
||
- Customer is not collapsed into Tenant.
|
||
- Vendor is not collapsed into Realm.
|
||
- Cross-tenant administration is scoped and evidenced.
|
||
|
||
## S05. Customer Organization With Delegated Administrators
|
||
|
||
Expected representation: Organization actor, Tenant scope, administrator
|
||
Accounts, Delegation and Administration relationships.
|
||
|
||
Checks:
|
||
|
||
- Admin rights are relationships, not just group names.
|
||
- Delegation has source, target, scope, and lifecycle state.
|
||
- Authorization projection can consume the relationship separately.
|
||
|
||
## S06. Family With Guardian And Dependent Accounts
|
||
|
||
Expected representation: Family or Household collective actor, Natural Person
|
||
actors, guardian/dependent relationships, child Accounts, and privacy
|
||
constraints.
|
||
|
||
Checks:
|
||
|
||
- Guardian relationship is not generic membership.
|
||
- Household and legal family can differ.
|
||
- Privacy-sensitive links can be scoped.
|
||
|
||
## S07. Spontaneous Interest Group
|
||
|
||
Expected representation: Community or Group collective actor, Membership
|
||
relationships, optional moderator Administration relationships.
|
||
|
||
Checks:
|
||
|
||
- Informal group does not need legal entity or tenant semantics.
|
||
- Moderation is not the same as membership.
|
||
- Group identity can exist without strong real-world identity proofing.
|
||
|
||
## S08. Community With Members, Moderators, And Followers
|
||
|
||
Expected representation: Community actor; Membership relationships for
|
||
members; Administration or moderation relationships for moderators; Following
|
||
relationships for followers.
|
||
|
||
Checks:
|
||
|
||
- Follower is not a member unless the source says so.
|
||
- Moderator authority is explicit and scoped.
|
||
- Public profile can differ from account.
|
||
|
||
## S09. Social Media Follower Graph
|
||
|
||
Expected representation: Actor or Persona profiles connected by Following
|
||
relationships in a social Scope.
|
||
|
||
Checks:
|
||
|
||
- Following is directed.
|
||
- Following does not imply affiliation, membership, trust, or authorization.
|
||
- Pseudonymous profiles can remain scoped.
|
||
|
||
## S10. Bot Or Service Account Acting For An Organization
|
||
|
||
Expected representation: Artificial Agent actor, Service Account, Organization
|
||
actor, Representation or Delegation relationship, and Credential records.
|
||
|
||
Checks:
|
||
|
||
- Bot is not a natural person.
|
||
- Service account has an owner or responsible actor.
|
||
- Delegated authority has bounded scope and lifecycle.
|
||
|
||
## S11. AI Agent Acting Under Delegated Authority
|
||
|
||
Expected representation: Artificial Agent actor, Account or Service Account,
|
||
Delegation relationship from a Natural Person or Organization, and audit or
|
||
evidence references for actions.
|
||
|
||
Checks:
|
||
|
||
- Delegation identifies who granted authority.
|
||
- Agent actions can be attributed without treating the agent as the person.
|
||
- Authorization projection can include delegated context.
|
||
|
||
## S12. Weak Identity Match From Imported Data
|
||
|
||
Expected representation: source Identity Records linked by a weak Synonymity
|
||
Assertion with method, evidence, confidence, scope, and lifecycle state.
|
||
|
||
Checks:
|
||
|
||
- Weak match does not merge accounts.
|
||
- Consumers can reject or quarantine weak links.
|
||
- Evidence source remains visible.
|
||
|
||
## S13. Strong Account Link After Explicit Verification
|
||
|
||
Expected representation: Accounts linked by a strong Synonymity Assertion or
|
||
Account Link relationship, with verification evidence and revocation path.
|
||
|
||
Checks:
|
||
|
||
- Strong link is still scoped.
|
||
- Verification method is recorded.
|
||
- Revocation or unlinking is possible.
|
||
|
||
## S14. Pseudonymous Profile Linked Only Within A Restricted Scope
|
||
|
||
Expected representation: Persona or Profile with Scoped Identifier and
|
||
privacy-limited Synonymity Assertion visible only inside an allowed Scope.
|
||
|
||
Checks:
|
||
|
||
- Public consumers cannot infer the hidden link.
|
||
- The pseudonym can have relationships independent of legal identity.
|
||
- Scope boundaries are explicit.
|
||
|
||
## S15. Organization Represented By A Legal Entity And Operational Tenants
|
||
|
||
Expected representation: Organization actor, Legal Entity specialization or
|
||
relationship, one or more Tenant scopes, and Representation relationships for
|
||
authorized persons or agents.
|
||
|
||
Checks:
|
||
|
||
- Legal entity and tenant are separate model elements.
|
||
- Multiple tenants can relate to one organization.
|
||
- Representation authority is scoped and evidenced.
|
||
|
||
## Current Result
|
||
|
||
After IDENTITY-WP-0003 corpus backfill, `model/ConceptualModel.md` documents
|
||
an explicit representation path for each scenario (S01–S15). All fifteen
|
||
scenarios remain representable without glossary or principle changes.
|
||
|
||
Remaining ambiguities are tracked in `OpenQuestions.md` (Realm promotion,
|
||
Customer Account concept, mandatory Synonymity Assertion fields). These affect
|
||
refinement, not scenario satisfiability.
|