generated from coulomb/repo-seed
tegwick
3ccf841095
Record B2B SaaS subscriber tenancy and Stripe billing source notes. Resolve the Customer Account open question: reject it as canonical, add Commercial Record and Commercial Relationship to the Record and relationship layers, and document Subscriber as a convenience term only.
195 lines
6.3 KiB
Markdown
195 lines
6.3 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,
|
||
mandatory Synonymity Assertion fields). Customer Account is resolved: use
|
||
Commercial Record for billing-side artifacts. These affect refinement, not
|
||
scenario satisfiability.
|