identity-canon/scenarios/ScenarioTests.md

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, mandatory Synonymity Assertion fields). Customer Account is resolved: use Commercial Record for billing-side artifacts. These affect refinement, not scenario satisfiability.