Distribute frozen commercial research provenance
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
parent
8a07292dd7
commit
8a89a6869e
40 changed files with 7201 additions and 4 deletions
|
|
@ -17,4 +17,5 @@ destinations. Start with the draft [kernel](infospace/kernel/CommerceCanonCore.m
|
|||
[registry](canon.yaml), and [layout assessment](docs/RepositoryLayout.md).
|
||||
The draft [counterparty model](infospace/models/counterparty/CommerceCanonCounterpartyModel.md)
|
||||
now defines the commerce assignments using explicit identity and evidence imports.
|
||||
Corpus distribution and reciprocal interface cards remain pending T07/T08.
|
||||
The [distributed corpus](infospace/assimilation/canon-federation/README.md) preserves
|
||||
research provenance; reciprocal interface cards remain pending T08.
|
||||
|
|
|
|||
2
SCOPE.md
2
SCOPE.md
|
|
@ -26,7 +26,7 @@ CUST-ADR-006. Its shared technical concepts are imported from InfoTechCanon.
|
|||
The repository rename preserves history. The old mixed glossary remains a
|
||||
migration input. T04 establishes the draft kernel and directory layout;
|
||||
T05/T11 registered the draft identity and evidence models; T06 registers the
|
||||
draft counterparty model. CFED T07/T08 still own provenance distribution and
|
||||
draft counterparty model. T07 distributes frozen research with a source ledger. CFED T08 still owns
|
||||
reciprocal interface cards. Draft registration does not imply stable promotion
|
||||
or consumer adoption.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
# Assimilation
|
||||
|
||||
Canon assimilation practice and destination provenance indexes belong here. The existing research/, terminology/, and scenarios/ trees remain source material; CFED-WP-0001-T07 owns their recorded distribution.
|
||||
[Canon federation corpus](canon-federation/README.md) preserves and routes the
|
||||
completed research as historical provenance. Current definitions stay in models/.
|
||||
|
|
|
|||
40
infospace/assimilation/canon-federation/ASSIMILATION.md
Normal file
40
infospace/assimilation/canon-federation/ASSIMILATION.md
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
# Canon federation research provenance
|
||||
|
||||
Status: closed provenance distribution. Disposition: observe. Native workplan:
|
||||
COMMERCE-WP-0003; project task CFED-WP-0001-T07. These are historical research inputs,
|
||||
not newly adopted definitions or evidence that external sources are current.
|
||||
|
||||
## Context and decision
|
||||
|
||||
Accepted ADR-006 assigns concept destinations and the user authorized continuing
|
||||
the migration. T07 routes already-completed research; it does not rerun research
|
||||
or open a new domain-concept adoption decision. Preserve immutable source copies
|
||||
and route shared material through model-specific indexes and exact fragments.
|
||||
Source repository: commerce-canon, commit `8a07292dd78d094151f165d3ac1dfc7512114308`.
|
||||
|
||||
Options considered: moving originals would break historical references; rewriting
|
||||
old assertions would destroy provenance; copying without destination indexes would
|
||||
hide the split. The chosen layout retains originals and copies frozen snapshots,
|
||||
with SHA-256 records and destination-specific reading views.
|
||||
|
||||
## Scope and consequences
|
||||
|
||||
24 source files are present here, including their complete context.
|
||||
[distribution.json](distribution.json) records source paths, hashes, applicable
|
||||
models and exact fragment line ranges. [source-summary](source-summary.md) lists
|
||||
the corpus areas. [comparison-matrix](comparison-matrix.md) applies the existing
|
||||
ownership ledger. [mappings.yaml](mappings.yaml) records the authoritative donor
|
||||
term destinations; it is a migration mapping, not a new external-vocabulary model.
|
||||
|
||||
Views under views/ partition the shared terminology rows, conflict sections and
|
||||
scenario sections by destination interest. Each fragment is verbatim, with its
|
||||
source locator and a warning that current canon takes precedence. Model indexes
|
||||
link full source notes without removing context. A shared source copy does not
|
||||
create a second concept owner. Source files are never runtime normative artifacts.
|
||||
|
||||
## Review trigger
|
||||
|
||||
A revised external source is a new intake; do not edit these snapshots. Any new
|
||||
concept or behavior proposed from the corpus requires its own review. Historical
|
||||
open questions remain historical; current unresolved work is linked in
|
||||
[open-questions.md](open-questions.md). No new domain definition is adopted here.
|
||||
5
infospace/assimilation/canon-federation/README.md
Normal file
5
infospace/assimilation/canon-federation/README.md
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
# Research provenance entry point
|
||||
|
||||
Read [ASSIMILATION.md](ASSIMILATION.md) before using historical sources.
|
||||
|
||||
- [counterparty](views/counterparty.md)
|
||||
35
infospace/assimilation/canon-federation/assimilation.yaml
Normal file
35
infospace/assimilation/canon-federation/assimilation.yaml
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
id: assimilation/canon-federation
|
||||
title: Canon federation research provenance
|
||||
source: identity-canon historical research corpus via commerce-canon
|
||||
source_version: 8a07292dd78d094151f165d3ac1dfc7512114308
|
||||
source_type: completed-internal-research
|
||||
source_files:
|
||||
- source/research/CorpusIndex.md
|
||||
- source/research/README.md
|
||||
- source/research/ResearchSeed.md
|
||||
- source/research/commercial-identity/beneficial-ownership-kyc-boi.md
|
||||
- source/research/commercial-identity/commercial-identity-nuance-settlement.md
|
||||
- source/research/commercial-identity/commercial-identity-synthesis.md
|
||||
- source/research/commercial-identity/commercial-trust-binding-theory.md
|
||||
- source/research/commercial-identity/crm-pipeline-commitment-threshold.md
|
||||
- source/research/commercial-identity/duns-commercial-credit-identity.md
|
||||
- source/research/commercial-identity/eidas-eudi-legal-person-wallet.md
|
||||
- source/research/commercial-identity/kyc-aml-commercial-identity-binding.md
|
||||
- source/research/commercial-identity/legal-person-agency-contract.md
|
||||
- source/research/commercial-identity/lei-gleif-legal-entity-identifier.md
|
||||
- source/research/commercial-identity/payment-credential-pci-boundary.md
|
||||
- source/research/commercial-identity/registry-identifier-subtypes.md
|
||||
- source/research/commercial-identity/reputation-assurance-gradient.md
|
||||
- source/research/commercial-identity/salesforce-crm-commercial-record.md
|
||||
- source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md
|
||||
- source/research/commercial-subscription/stripe-customer-billing.md
|
||||
- source/research/identity-provisioning/keycloak-organizations.md
|
||||
- source/research/identity-provisioning/zitadel-organizations-projects.md
|
||||
- source/scenarios/ScenarioTests.md
|
||||
- source/terminology/TerminologyConflictMap.md
|
||||
- source/terminology/TerminologyInventory.md
|
||||
status: closed
|
||||
disposition: observe
|
||||
impacts:
|
||||
- counterparty
|
||||
workplan: COMMERCE-WP-0003
|
||||
67
infospace/assimilation/canon-federation/comparison-matrix.md
Normal file
67
infospace/assimilation/canon-federation/comparison-matrix.md
Normal file
|
|
@ -0,0 +1,67 @@
|
|||
# Comparison with current canon
|
||||
|
||||
Existing approved migration assignments are reused; historical wording is not
|
||||
promoted by being copied. Family remains seeded only.
|
||||
|
||||
| Donor concept | Current destination | Classification |
|
||||
| --- | --- | --- |
|
||||
| Actor | itc-org: Actor | covered_differently |
|
||||
| Natural Person | itc-org: Person | covered_differently |
|
||||
| Artificial Agent | itc-org: Agent | covered_differently |
|
||||
| Collective Actor | itc-org: CollectiveActor | covered_differently |
|
||||
| Account | itc-ident: Account | already_covered |
|
||||
| Service Account | itc-ident: Service Account | already_covered |
|
||||
| Identity Record | itc-ident: Identity Record | already_covered |
|
||||
| Identifier | itc-ident: Identifier | already_covered |
|
||||
| Registry Identifier | counterparty: Registry Identifier | already_covered |
|
||||
| Proxy Commercial Identifier | counterparty: Proxy Commercial Identifier | already_covered |
|
||||
| Scoped Identifier | itc-ident: Scoped Identifier | already_covered |
|
||||
| Credential | itc-ident: Credential | already_covered |
|
||||
| Claim | itc-ident: Claim | already_covered |
|
||||
| Authenticated Subject | itc-access: Subject | covered_differently |
|
||||
| Authorization Principal | itc-access: Principal | covered_differently |
|
||||
| Profile | itc-ident: Profile | already_covered |
|
||||
| Persona | itc-ident: Persona | already_covered |
|
||||
| Scope | itc-ident: Scope | already_covered |
|
||||
| Tenant | itc-ident: Tenant | already_covered |
|
||||
| Realm | itc-ident: Realm | already_covered |
|
||||
| Organization | itc-org: Organization | covered_differently |
|
||||
| Legal Entity | counterparty: Legal Entity | already_covered |
|
||||
| Legal Person | counterparty: Legal Person | already_covered |
|
||||
| Beneficial Owner | counterparty: Beneficial Owner | already_covered |
|
||||
| Beneficial Ownership Relationship | counterparty: Beneficial Ownership Relationship | already_covered |
|
||||
| Beneficial Ownership Exemption | counterparty: Beneficial Ownership Exemption | covered_differently |
|
||||
| Customer | counterparty: Customer | already_covered |
|
||||
| Vendor | counterparty: Vendor | already_covered |
|
||||
| Commercial Relationship | counterparty: Commercial Relationship | already_covered |
|
||||
| Commercial Commitment | counterparty: Commercial Commitment | already_covered |
|
||||
| Payment Instrument Reference | counterparty: Payment Instrument Reference | already_covered |
|
||||
| Payment Mandate | counterparty: Payment Mandate | already_covered |
|
||||
| Pipeline Pursuit | counterparty: Pipeline Pursuit | already_covered |
|
||||
| Commercial Record | counterparty: Commercial Record | already_covered |
|
||||
| Community | itc-org: Community | covered_differently |
|
||||
| Family Or Household | itc-org: Household; family-area: Family | covered_differently |
|
||||
| Group | itc-org: Group | covered_differently |
|
||||
| Role | itc-org: Role | covered_differently |
|
||||
| Relationship | itc-ident: Relationship | already_covered |
|
||||
| Membership Relationship | itc-org: Membership | covered_differently |
|
||||
| Affiliation Relationship | itc-ident: Affiliation Relationship | already_covered |
|
||||
| Following Relationship | itc-ident: Following Relationship | already_covered |
|
||||
| Representation Relationship | itc-ident: Representation Relationship | already_covered |
|
||||
| Delegation Relationship | itc-ident: Delegation Relationship | covered_differently |
|
||||
| Administration Relationship | itc-ident: Administration Relationship | already_covered |
|
||||
| Trust Relationship | itc-ident: Trust Relationship | already_covered |
|
||||
| Synonymity Assertion | itc-ident: Synonymity Assertion | already_covered |
|
||||
| Evidence Source | itc-evid: Evidence Source | covered_differently |
|
||||
| Counterparty Assurance Gradient | counterparty: Counterparty Assurance Gradient | already_covered |
|
||||
| Reputation Signal | counterparty: Reputation Signal | covered_differently |
|
||||
| Performance Evidence | counterparty: Performance Evidence | covered_differently |
|
||||
| Adjudication Outcome | itc-evid: Adjudication Outcome | covered_differently |
|
||||
| Non-Canonical Convenience Term: Reputation | counterparty: Reputation | already_covered |
|
||||
| Lifecycle State | itc-ident: Lifecycle State | already_covered |
|
||||
| Assurance Level | itc-ident: Assurance Level | already_covered |
|
||||
| Relationship Tuple | itc-access: Relationship Tuple | covered_differently |
|
||||
| Pseudonymous Identifier | itc-ident: Pseudonymous Identifier | already_covered |
|
||||
| Non-Canonical Convenience Term: User | itc-ident: User | already_covered |
|
||||
| Non-Canonical Convenience Term: Subscriber | itc-ident: Subscriber | already_covered |
|
||||
| Non-Canonical Convenience Term: Customer Account | counterparty: Customer Account | already_covered |
|
||||
1635
infospace/assimilation/canon-federation/distribution.json
Normal file
1635
infospace/assimilation/canon-federation/distribution.json
Normal file
File diff suppressed because it is too large
Load diff
429
infospace/assimilation/canon-federation/extracted-concepts.yaml
Normal file
429
infospace/assimilation/canon-federation/extracted-concepts.yaml
Normal file
|
|
@ -0,0 +1,429 @@
|
|||
extraction_basis: Existing donor glossary and federation ledger; research product
|
||||
terms remain candidate mappings in frozen sources.
|
||||
source_revision: 4bb474970b73d500da03b6482e84e6c256146b79
|
||||
entries:
|
||||
- source_term: Actor
|
||||
destinations:
|
||||
- concept: Actor
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Natural Person
|
||||
destinations:
|
||||
- concept: Person
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Artificial Agent
|
||||
destinations:
|
||||
- concept: Agent
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Collective Actor
|
||||
destinations:
|
||||
- concept: CollectiveActor
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Account
|
||||
destinations:
|
||||
- concept: Account
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Service Account
|
||||
destinations:
|
||||
- concept: Service Account
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Identity Record
|
||||
destinations:
|
||||
- concept: Identity Record
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Identifier
|
||||
destinations:
|
||||
- concept: Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Registry Identifier
|
||||
destinations:
|
||||
- concept: Registry Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Proxy Commercial Identifier
|
||||
destinations:
|
||||
- concept: Proxy Commercial Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Scoped Identifier
|
||||
destinations:
|
||||
- concept: Scoped Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Credential
|
||||
destinations:
|
||||
- concept: Credential
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Claim
|
||||
destinations:
|
||||
- concept: Claim
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Authenticated Subject
|
||||
destinations:
|
||||
- concept: Subject
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-access
|
||||
- source_term: Authorization Principal
|
||||
destinations:
|
||||
- concept: Principal
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-access
|
||||
- source_term: Profile
|
||||
destinations:
|
||||
- concept: Profile
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Persona
|
||||
destinations:
|
||||
- concept: Persona
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Scope
|
||||
destinations:
|
||||
- concept: Scope
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Tenant
|
||||
destinations:
|
||||
- concept: Tenant
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Realm
|
||||
destinations:
|
||||
- concept: Realm
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Organization
|
||||
destinations:
|
||||
- concept: Organization
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Legal Entity
|
||||
destinations:
|
||||
- concept: Legal Entity
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Legal Person
|
||||
destinations:
|
||||
- concept: Legal Person
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Beneficial Owner
|
||||
destinations:
|
||||
- concept: Beneficial Owner
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Beneficial Ownership Relationship
|
||||
destinations:
|
||||
- concept: Beneficial Ownership Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Beneficial Ownership Exemption
|
||||
destinations:
|
||||
- concept: Beneficial Ownership Exemption
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Customer
|
||||
destinations:
|
||||
- concept: Customer
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Vendor
|
||||
destinations:
|
||||
- concept: Vendor
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Commercial Relationship
|
||||
destinations:
|
||||
- concept: Commercial Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Commercial Commitment
|
||||
destinations:
|
||||
- concept: Commercial Commitment
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Payment Instrument Reference
|
||||
destinations:
|
||||
- concept: Payment Instrument Reference
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Payment Mandate
|
||||
destinations:
|
||||
- concept: Payment Mandate
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Pipeline Pursuit
|
||||
destinations:
|
||||
- concept: Pipeline Pursuit
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Commercial Record
|
||||
destinations:
|
||||
- concept: Commercial Record
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Community
|
||||
destinations:
|
||||
- concept: Community
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Family Or Household
|
||||
destinations:
|
||||
- concept: Household
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- concept: Family
|
||||
kind: seed
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: family-area
|
||||
- source_term: Group
|
||||
destinations:
|
||||
- concept: Group
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Role
|
||||
destinations:
|
||||
- concept: Role
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Relationship
|
||||
destinations:
|
||||
- concept: Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Membership Relationship
|
||||
destinations:
|
||||
- concept: Membership
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Affiliation Relationship
|
||||
destinations:
|
||||
- concept: Affiliation Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Following Relationship
|
||||
destinations:
|
||||
- concept: Following Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Representation Relationship
|
||||
destinations:
|
||||
- concept: Representation Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Delegation Relationship
|
||||
destinations:
|
||||
- concept: Delegation Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Administration Relationship
|
||||
destinations:
|
||||
- concept: Administration Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Trust Relationship
|
||||
destinations:
|
||||
- concept: Trust Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Synonymity Assertion
|
||||
destinations:
|
||||
- concept: Synonymity Assertion
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Evidence Source
|
||||
destinations:
|
||||
- concept: Evidence Source
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-evid
|
||||
- source_term: Counterparty Assurance Gradient
|
||||
destinations:
|
||||
- concept: Counterparty Assurance Gradient
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Reputation Signal
|
||||
destinations:
|
||||
- concept: Reputation Signal
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Performance Evidence
|
||||
destinations:
|
||||
- concept: Performance Evidence
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Adjudication Outcome
|
||||
destinations:
|
||||
- concept: Adjudication Outcome
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-evid
|
||||
- source_term: 'Non-Canonical Convenience Term: Reputation'
|
||||
destinations:
|
||||
- concept: Reputation
|
||||
kind: convenience_term
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Lifecycle State
|
||||
destinations:
|
||||
- concept: Lifecycle State
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Assurance Level
|
||||
destinations:
|
||||
- concept: Assurance Level
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Relationship Tuple
|
||||
destinations:
|
||||
- concept: Relationship Tuple
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-access
|
||||
- source_term: Pseudonymous Identifier
|
||||
destinations:
|
||||
- concept: Pseudonymous Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: 'Non-Canonical Convenience Term: User'
|
||||
destinations:
|
||||
- concept: User
|
||||
kind: convenience_term
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: 'Non-Canonical Convenience Term: Subscriber'
|
||||
destinations:
|
||||
- concept: Subscriber
|
||||
kind: convenience_term
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: 'Non-Canonical Convenience Term: Customer Account'
|
||||
destinations:
|
||||
- concept: Customer Account
|
||||
kind: convenience_term
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
488
infospace/assimilation/canon-federation/mappings.yaml
Normal file
488
infospace/assimilation/canon-federation/mappings.yaml
Normal file
|
|
@ -0,0 +1,488 @@
|
|||
authority: CUST-ADR-006 accepted-1 (2026-08-17)
|
||||
status: provenance-mapping
|
||||
entries:
|
||||
- source_term: Actor
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Actor
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Natural Person
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Person
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Artificial Agent
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Agent
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Collective Actor
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: CollectiveActor
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Account
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Account
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Service Account
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Service Account
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Identity Record
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Identity Record
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Identifier
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Registry Identifier
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Registry Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Proxy Commercial Identifier
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Proxy Commercial Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Scoped Identifier
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Scoped Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Credential
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Credential
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Claim
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Claim
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Authenticated Subject
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Subject
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-access
|
||||
- source_term: Authorization Principal
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Principal
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-access
|
||||
- source_term: Profile
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Profile
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Persona
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Persona
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Scope
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Scope
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Tenant
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Tenant
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Realm
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Realm
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Organization
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Organization
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Legal Entity
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Legal Entity
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Legal Person
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Legal Person
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Beneficial Owner
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Beneficial Owner
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Beneficial Ownership Relationship
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Beneficial Ownership Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Beneficial Ownership Exemption
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Beneficial Ownership Exemption
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Customer
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Customer
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Vendor
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Vendor
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Commercial Relationship
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Commercial Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Commercial Commitment
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Commercial Commitment
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Payment Instrument Reference
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Payment Instrument Reference
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Payment Mandate
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Payment Mandate
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Pipeline Pursuit
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Pipeline Pursuit
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Commercial Record
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Commercial Record
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Community
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Community
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Family Or Household
|
||||
disposition: split
|
||||
targets:
|
||||
- concept: Household
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- concept: Family
|
||||
kind: seed
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: family-area
|
||||
- source_term: Group
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Group
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Role
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Role
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Relationship
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Membership Relationship
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Membership
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-org
|
||||
- source_term: Affiliation Relationship
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Affiliation Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Following Relationship
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Following Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Representation Relationship
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Representation Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Delegation Relationship
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Delegation Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Administration Relationship
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Administration Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Trust Relationship
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Trust Relationship
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Synonymity Assertion
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Synonymity Assertion
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Evidence Source
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Evidence Source
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-evid
|
||||
- source_term: Counterparty Assurance Gradient
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Counterparty Assurance Gradient
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Reputation Signal
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Reputation Signal
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Performance Evidence
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Performance Evidence
|
||||
kind: concept
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Adjudication Outcome
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Adjudication Outcome
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-evid
|
||||
- source_term: 'Non-Canonical Convenience Term: Reputation'
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Reputation
|
||||
kind: convenience_term
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
- source_term: Lifecycle State
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Lifecycle State
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Assurance Level
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Assurance Level
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: Relationship Tuple
|
||||
disposition: import
|
||||
targets:
|
||||
- concept: Relationship Tuple
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-access
|
||||
- source_term: Pseudonymous Identifier
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Pseudonymous Identifier
|
||||
kind: concept
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: 'Non-Canonical Convenience Term: User'
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: User
|
||||
kind: convenience_term
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: 'Non-Canonical Convenience Term: Subscriber'
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Subscriber
|
||||
kind: convenience_term
|
||||
owner:
|
||||
canon: info-tech-canon
|
||||
model: itc-ident
|
||||
- source_term: 'Non-Canonical Convenience Term: Customer Account'
|
||||
disposition: own
|
||||
targets:
|
||||
- concept: Customer Account
|
||||
kind: convenience_term
|
||||
owner:
|
||||
canon: commerce-canon
|
||||
model: counterparty
|
||||
13
infospace/assimilation/canon-federation/open-questions.md
Normal file
13
infospace/assimilation/canon-federation/open-questions.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
# Current versus historical questions
|
||||
|
||||
Frozen source review queues describe their original state, not new live tasks.
|
||||
Known superseded assertions include Family as a collective actor (ADR R6),
|
||||
Evidence Source used for assertions and adjudication (R3/R5/R7), generic Role or
|
||||
Subject redefinitions, and pipeline status treated as commercial binding.
|
||||
The current models and migration ledger govern those cases. Historical scenario
|
||||
claims of universal satisfiability are not a current conformance result.
|
||||
|
||||
Live continuation: CFED-WP-0001-T08 owns reciprocal cards, current navigation and
|
||||
reviewed import revisions; T09 owns fleet references; T10 owns residual handoffs.
|
||||
Family model authoring and consumer adoption require named demand and are not
|
||||
created as speculative implementation work by this distribution.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
# Canon changes
|
||||
|
||||
None in this provenance-distribution task. T05/T06/T11/T12/T13 established the
|
||||
current draft destinations. Historical candidates such as Identifier Binding,
|
||||
Account Link or Family-as-collective are not promoted by retaining their source
|
||||
notes. Read the destination definitions and accepted ADR-006 before reuse.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
# Source summary
|
||||
|
||||
Frozen completed research, not revalidated external specifications.
|
||||
|
||||
- commercial-identity: 14 files.
|
||||
- commercial-subscription: 2 files.
|
||||
- identity-provisioning: 2 files.
|
||||
- shared-context: 6 files.
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
# CorpusIndex.md
|
||||
|
||||
# identity-canon Research Corpus Index
|
||||
|
||||
This index tracks the research corpus for `identity-canon`.
|
||||
|
||||
The repository is focused on research and terminology. The corpus should collect source notes, terminology extracts, conflict observations, and modeling implications from standards, product documentation, semantic vocabularies, authorization systems, decentralized identity work, and entity-resolution/privacy research.
|
||||
|
||||
## Source Stack
|
||||
|
||||
### identity-provisioning
|
||||
|
||||
- `scim-rfc7643-rfc7644.md`
|
||||
- `ldap-rfc4519-inetorgperson-rfc2798.md`
|
||||
- `keycloak-organizations.md`
|
||||
- `zitadel-organizations-projects.md`
|
||||
- `ory-kratos-keto.md`
|
||||
|
||||
### authentication-federation
|
||||
|
||||
- `oidc-core-subject-identifiers.md`
|
||||
- `saml-nameid-federation.md`
|
||||
- `nist-800-63-4.md`
|
||||
- `shared-signals-caep-risc.md`
|
||||
|
||||
### social-community-graphs
|
||||
|
||||
- `activitypub-actors-followers.md`
|
||||
- `foaf-agent-person-group-onlineaccount.md`
|
||||
- `webid-solid-profile.md`
|
||||
- `schema-org-person-organization-membership.md`
|
||||
|
||||
### authorization-relationships
|
||||
|
||||
- `zanzibar-rebac.md`
|
||||
- `openfga-modeling.md`
|
||||
- `cedar-principal-action-resource-context.md`
|
||||
- `cerbos-abac-derived-roles.md`
|
||||
|
||||
### verifiable-claims
|
||||
|
||||
- `did-core.md`
|
||||
- `vc-data-model-2.md`
|
||||
- `openid4vc.md`
|
||||
|
||||
### entity-resolution-privacy
|
||||
|
||||
- `deterministic-vs-probabilistic-matching.md`
|
||||
- `synonymity-assertions.md`
|
||||
- `gdpr-pseudonymization.md`
|
||||
|
||||
### commercial-subscription
|
||||
|
||||
- `b2b-saas-subscriber-tenancy.md`
|
||||
- `stripe-customer-billing.md`
|
||||
|
||||
### commercial-identity
|
||||
|
||||
- `commercial-identity-synthesis.md`
|
||||
- `commercial-trust-binding-theory.md`
|
||||
- `legal-person-agency-contract.md`
|
||||
- `lei-gleif-legal-entity-identifier.md`
|
||||
- `duns-commercial-credit-identity.md`
|
||||
- `kyc-aml-commercial-identity-binding.md`
|
||||
- `eidas-eudi-legal-person-wallet.md`
|
||||
- `salesforce-crm-commercial-record.md`
|
||||
- `beneficial-ownership-kyc-boi.md`
|
||||
- `registry-identifier-subtypes.md`
|
||||
- `reputation-assurance-gradient.md`
|
||||
- `payment-credential-pci-boundary.md`
|
||||
- `crm-pipeline-commitment-threshold.md`
|
||||
- `commercial-identity-nuance-settlement.md`
|
||||
|
||||
## Source Note Template
|
||||
|
||||
Each source note should capture:
|
||||
|
||||
- source name;
|
||||
- source type;
|
||||
- domain;
|
||||
- key concepts;
|
||||
- relevant terminology;
|
||||
- assumptions;
|
||||
- modeling implications;
|
||||
- conflicts with other sources;
|
||||
- usefulness for identity-canon;
|
||||
- candidate canonical mappings;
|
||||
- open questions.
|
||||
|
||||
## Derived Canon Artifacts
|
||||
|
||||
The first proposal follow-up pass created these draft artifacts from the
|
||||
proposal and seeded corpus topics:
|
||||
|
||||
- `terminology/TerminologyInventory.md`
|
||||
- `terminology/TerminologyConflictMap.md`
|
||||
- `canon/DesignPrinciples.md`
|
||||
- `canon/CanonicalGlossary.md`
|
||||
- `model/ConceptualModel.md`
|
||||
- `scenarios/ScenarioTests.md`
|
||||
- `OpenQuestions.md`
|
||||
- `DownstreamRecommendations.md`
|
||||
|
||||
These files are candidate canon surfaces. Treat them as hypotheses to test
|
||||
while backfilling the individual source notes.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
# research
|
||||
|
||||
This directory contains the research corpus for `identity-canon`.
|
||||
|
||||
Start with:
|
||||
|
||||
- `ResearchSeed.md` for the initial research framing and seeded terminology;
|
||||
- `CorpusIndex.md` for the source stack and source note structure.
|
||||
|
||||
Each subdirectory corresponds to one research domain.
|
||||
|
|
@ -0,0 +1,549 @@
|
|||
# ResearchSeed.md
|
||||
|
||||
# identity-canon Research Seed
|
||||
|
||||
This file captures the initial research seeding information for `identity-canon`.
|
||||
|
||||
The research goal is to distill a canonical terminology and conceptual data model for identity, user, organization, community, tenant, and relationship management in complex systems that are multi-tenant, multi-vendor, multi-community, and multi-user capable.
|
||||
|
||||
The model should support enterprises with sub-organizations, social communities, social-media follower graphs, single users, family entities, spontaneous interest groups, bots, service accounts, AI agents, and weak/strong synonymity between identity records.
|
||||
|
||||
## Initial Framing
|
||||
|
||||
The project should not start from a simple `user` table or from a classic `users + groups + roles` IAM schema.
|
||||
|
||||
A more robust canonical core is a graph of:
|
||||
|
||||
- actors;
|
||||
- identities;
|
||||
- accounts;
|
||||
- identifiers;
|
||||
- profiles;
|
||||
- personas;
|
||||
- scopes;
|
||||
- tenants;
|
||||
- organizations;
|
||||
- communities;
|
||||
- families/households;
|
||||
- memberships;
|
||||
- relationships;
|
||||
- credentials;
|
||||
- claims;
|
||||
- evidence;
|
||||
- synonymity assertions.
|
||||
|
||||
Classic IAM systems, social networks, enterprise directories, family accounts, communities, vendors, customers, and spontaneous groups can then be modeled as specializations or patterns over that graph.
|
||||
|
||||
## Important Research Domains
|
||||
|
||||
## 1. Identity Provisioning and Directory Models
|
||||
|
||||
Important sources:
|
||||
|
||||
- SCIM 2.0: RFC 7643 and RFC 7644;
|
||||
- LDAP and inetOrgPerson: RFC 4519 and RFC 2798;
|
||||
- Keycloak Organizations;
|
||||
- ZITADEL organizations and projects;
|
||||
- Ory Kratos and Keto.
|
||||
|
||||
Research focus:
|
||||
|
||||
- provisioning semantics;
|
||||
- users and groups;
|
||||
- organization/member terminology;
|
||||
- directory assumptions;
|
||||
- account lifecycle;
|
||||
- separation between identity management and authorization.
|
||||
|
||||
SCIM is especially important as a provisioning baseline because it defines platform-neutral schemas and protocol operations for user and group resources.
|
||||
|
||||
LDAP and inetOrgPerson remain important because lightweight IAM stacks and enterprise systems still inherit LDAP-style person, organizational unit, and group terminology.
|
||||
|
||||
Keycloak and ZITADEL provide live multi-tenant IAM product vocabularies. Ory is useful because it separates identity management from authorization.
|
||||
|
||||
## 2. Authentication and Federation
|
||||
|
||||
Important sources:
|
||||
|
||||
- OpenID Connect Core;
|
||||
- SAML 2.0;
|
||||
- NIST SP 800-63-4;
|
||||
- OpenID Shared Signals, CAEP, and RISC.
|
||||
|
||||
Research focus:
|
||||
|
||||
- issuer and subject concepts;
|
||||
- pairwise and public subject identifiers;
|
||||
- authentication assurance;
|
||||
- federation assurance;
|
||||
- assertions and claims;
|
||||
- risk and security event streams;
|
||||
- account linking and pseudonymous identifiers.
|
||||
|
||||
OIDC is central because externally issued subject identifiers and pairwise identifiers directly affect synonymity and account-linking semantics.
|
||||
|
||||
SAML remains important for enterprise federation and assertion semantics.
|
||||
|
||||
NIST identity guidance is useful for separating identity proofing, authentication assurance, federation assurance, and lifecycle management.
|
||||
|
||||
Shared Signals, CAEP, and RISC suggest that canonical identity models should also anticipate dynamic security and lifecycle events.
|
||||
|
||||
## 3. Social Graph and Community Models
|
||||
|
||||
Important sources:
|
||||
|
||||
- ActivityPub;
|
||||
- FOAF;
|
||||
- WebID;
|
||||
- Solid profiles;
|
||||
- Schema.org Person and Organization.
|
||||
|
||||
Research focus:
|
||||
|
||||
- actors;
|
||||
- followers/following;
|
||||
- public profiles;
|
||||
- handles;
|
||||
- accounts on federated servers;
|
||||
- communities;
|
||||
- groups;
|
||||
- social relationships;
|
||||
- semantic vocabularies for persons and organizations.
|
||||
|
||||
ActivityPub is especially relevant because it treats users as server-side actors with inboxes and outboxes. A person may have several actors across servers, which maps well to contextual identities and personas.
|
||||
|
||||
FOAF and Schema.org are useful because they distinguish persons, agents, organizations, groups, accounts, and membership-like properties.
|
||||
|
||||
WebID/Solid are useful for user-controlled profiles and decentralized identity-style profile discovery.
|
||||
|
||||
## 4. Authorization and Relationship Semantics
|
||||
|
||||
Important sources:
|
||||
|
||||
- Google Zanzibar;
|
||||
- OpenFGA;
|
||||
- Cedar;
|
||||
- AWS Verified Permissions;
|
||||
- Cerbos.
|
||||
|
||||
Research focus:
|
||||
|
||||
- relationship-based authorization;
|
||||
- subject-relation-object tuples;
|
||||
- principals;
|
||||
- resources;
|
||||
- actions;
|
||||
- context;
|
||||
- roles vs permissions vs relationships;
|
||||
- delegated administration.
|
||||
|
||||
Zanzibar/OpenFGA-style relationship tuples are especially close to what `identity-canon` needs for memberships, ownership, representation, delegation, family roles, community moderation, vendor/customer relationships, and tenant administration.
|
||||
|
||||
Cedar’s principal-action-resource-context distinction is useful for preserving orthogonality between identity, action, resource, and request context.
|
||||
|
||||
## 5. Decentralized Identity and Verifiable Claims
|
||||
|
||||
Important sources:
|
||||
|
||||
- W3C DID Core;
|
||||
- W3C Verifiable Credentials Data Model 2.0;
|
||||
- OpenID for Verifiable Credentials.
|
||||
|
||||
Research focus:
|
||||
|
||||
- decentralized identifiers;
|
||||
- DID subjects and controllers;
|
||||
- verification methods;
|
||||
- claims;
|
||||
- issuers;
|
||||
- holders;
|
||||
- verifiers;
|
||||
- presentations;
|
||||
- portable identity claims;
|
||||
- externally controlled identifiers.
|
||||
|
||||
DID and Verifiable Credentials are relevant when identity, membership, authorization, or representation claims are issued outside the platform.
|
||||
|
||||
The canonical model should distinguish claims from verified facts and should preserve issuer, evidence, scope, validity, and revocation state.
|
||||
|
||||
## 6. Entity Resolution, Synonymity, and Privacy
|
||||
|
||||
Important sources:
|
||||
|
||||
- deterministic matching;
|
||||
- probabilistic matching;
|
||||
- entity resolution and record linkage literature;
|
||||
- GDPR pseudonymization and anonymization guidance.
|
||||
|
||||
Research focus:
|
||||
|
||||
- weak identity matches;
|
||||
- strong identity links;
|
||||
- scoped identity equivalence;
|
||||
- operational account linking;
|
||||
- legal identity links;
|
||||
- privacy-preserving links;
|
||||
- source and evidence;
|
||||
- confidence;
|
||||
- revocation;
|
||||
- GDPR implications.
|
||||
|
||||
The model should avoid treating identity linkage as a destructive merge. Instead, synonymity should be modeled as an assertion with strength, scope, source, evidence, confidence, validity, and revocation state.
|
||||
|
||||
## Terminology Challenge
|
||||
|
||||
Many common terms are overloaded:
|
||||
|
||||
| Term | Common Meanings | Modeling Risk |
|
||||
| --- | --- | --- |
|
||||
| User | Human, account, login principal, profile, customer record, app user | Collapses person, account, and actor |
|
||||
| Account | Login credential set, billing account, social media handle, tenant account | Collapses authentication and business relationship |
|
||||
| Organization | Legal entity, tenant, department, team, community, vendor, customer | Collapses legal structure, membership scope, and operational boundary |
|
||||
| Group | LDAP group, social group, permission group, family, team, community | Collapses social grouping and authorization grouping |
|
||||
| Role | Job function, permission bundle, relationship label, social role | Collapses semantics, permissions, and responsibility |
|
||||
| Identity | Real-world personhood, credentialed subject, account identity, profile | Collapses entity, claim, authenticator, and identifier |
|
||||
| Principal | Human user, service account, agent, organization acting entity | Good for authorization, too narrow for social modeling |
|
||||
| Tenant | Isolation boundary, customer organization, billing unit, realm | Collapses infrastructure boundary and social/legal actor |
|
||||
|
||||
The key design move is to stop using `user` as the root concept.
|
||||
|
||||
## Candidate Canonical Vocabulary
|
||||
|
||||
## Entity and Actor Layer
|
||||
|
||||
### Entity
|
||||
|
||||
Anything that can be referred to as a modeled thing: person, organization, family, community, bot, service, account, resource, project, domain, or device.
|
||||
|
||||
### Actor
|
||||
|
||||
An entity capable of intentional or delegated action in a system. Examples include human persons, organizations acting through representatives, AI agents, service accounts, and community bots.
|
||||
|
||||
### Natural Person
|
||||
|
||||
A human being. This should not be identical to `user`, because a person can have many accounts, profiles, personas, and relationships.
|
||||
|
||||
### Collective Actor
|
||||
|
||||
A group-like actor that can act collectively or be represented by members/admins. Subtypes include enterprise, department, family, community, interest group, vendor, customer tenant, and project team.
|
||||
|
||||
### Artificial Actor
|
||||
|
||||
A bot, service account, automation, coding agent, or autonomous agent.
|
||||
|
||||
## Identity and Account Layer
|
||||
|
||||
### Identity
|
||||
|
||||
A claim-bearing representation of an actor in a context. An actor can have multiple identities.
|
||||
|
||||
### Identifier
|
||||
|
||||
A value used to refer to an identity or entity: UUID, email address, username, OIDC subject, SAML NameID, DID, domain name, phone number, employee number.
|
||||
|
||||
### Account
|
||||
|
||||
A system-local operational identity used for login, profile, preferences, sessions, and credentials.
|
||||
|
||||
### Profile
|
||||
|
||||
A presentation surface of an identity or account. A profile may be public, private, tenant-local, app-local, community-local, or audience-specific.
|
||||
|
||||
### Persona
|
||||
|
||||
A deliberate contextual identity expression of an actor. Examples include private person, employee persona, admin persona, and pseudonymous community handle.
|
||||
|
||||
### Credential
|
||||
|
||||
Something used to authenticate or prove a claim: password, passkey, certificate, TOTP seed, recovery factor, verifiable credential, or domain ownership proof.
|
||||
|
||||
### Authenticator
|
||||
|
||||
The concrete authentication factor or mechanism bound to an account/subscriber.
|
||||
|
||||
## Scope and Tenancy Layer
|
||||
|
||||
### Scope
|
||||
|
||||
A bounded context in which identifiers, memberships, roles, policies, and profile data have meaning.
|
||||
|
||||
### Tenant
|
||||
|
||||
A scope with operational isolation and delegated administration. A tenant may be backed by an organization, family, community, individual, vendor, or platform unit.
|
||||
|
||||
### Realm / Identity Domain
|
||||
|
||||
A hard identity boundary with separate users, credentials, clients, policies, and lifecycle.
|
||||
|
||||
### Organization
|
||||
|
||||
A structured collective actor with governance, membership, and possibly sub-organizations. It may or may not be a legal entity.
|
||||
|
||||
### Legal Entity
|
||||
|
||||
An organization recognized by a jurisdiction. Not every organization, community, or team is a legal entity.
|
||||
|
||||
### Community
|
||||
|
||||
A collective actor primarily organized by shared interest, social graph, participation, or moderation rules rather than employment/legal hierarchy.
|
||||
|
||||
### Household / Family
|
||||
|
||||
A collective actor organized around family/household relationships, guardianship, shared resources, and dependent accounts.
|
||||
|
||||
### Spontaneous Group
|
||||
|
||||
A lightweight collective actor created ad hoc around temporary interest, event, project, or conversation.
|
||||
|
||||
Important distinction: tenant, organization, and community must not be synonyms. A tenant is an operational boundary. An organization, community, or family is a social/legal actor that may own or inhabit a tenant.
|
||||
|
||||
## Relationship Layer
|
||||
|
||||
### Relationship
|
||||
|
||||
A typed edge between entities, actors, accounts, scopes, resources, or other modeled concepts.
|
||||
|
||||
### Membership
|
||||
|
||||
A relationship where an actor participates in a collective actor or scope.
|
||||
|
||||
### Affiliation
|
||||
|
||||
A looser relationship indicating association without necessarily implying membership, authority, or access.
|
||||
|
||||
### Representation
|
||||
|
||||
A relationship where one actor can act on behalf of another.
|
||||
|
||||
### Delegation
|
||||
|
||||
A scoped, revocable grant of authority from one actor to another.
|
||||
|
||||
### Administration
|
||||
|
||||
A delegated authority to manage lifecycle, membership, policy, or resources in a scope.
|
||||
|
||||
### Ownership
|
||||
|
||||
A strong control or responsibility relationship over an entity, resource, or scope. This may require legal, operational, and data-control subtypes.
|
||||
|
||||
### Follower Relationship
|
||||
|
||||
A directional social relationship expressing subscription or attention, not necessarily trust, membership, or permission.
|
||||
|
||||
### Trust Relationship
|
||||
|
||||
A relationship where one actor accepts claims, credentials, or decisions from another actor under defined conditions.
|
||||
|
||||
## Role and Capability Layer
|
||||
|
||||
### Role
|
||||
|
||||
A named relationship pattern in a scope. Examples include member, owner, moderator, billing admin, guardian, employee, and vendor admin.
|
||||
|
||||
### Capability
|
||||
|
||||
An ability to perform an action, usually derived from roles, policies, relationships, credentials, or explicit grants.
|
||||
|
||||
### Permission
|
||||
|
||||
A concrete allowed action on a resource type or instance.
|
||||
|
||||
### Policy
|
||||
|
||||
A rule that derives permissions or capabilities from relationships, attributes, credentials, and context.
|
||||
|
||||
This prevents the classic collapse of role, group, permission bundle, and job title.
|
||||
|
||||
## Synonymity and Identity Resolution Layer
|
||||
|
||||
### Strong Synonymity
|
||||
|
||||
Two identifiers, accounts, or identities are asserted to refer to the same underlying actor with high confidence and strong evidence.
|
||||
|
||||
Examples:
|
||||
|
||||
- same verified OIDC subject from the same issuer;
|
||||
- account explicitly linked after re-authentication;
|
||||
- verifiable credential bound to the same DID/controller.
|
||||
|
||||
### Weak Synonymity
|
||||
|
||||
Two records may refer to the same actor based on partial, contextual, or probabilistic evidence.
|
||||
|
||||
Examples:
|
||||
|
||||
- same email seen in imported CSV and social profile;
|
||||
- matching name/domain;
|
||||
- same account handle without explicit proof.
|
||||
|
||||
### Scoped Synonymity
|
||||
|
||||
Two identifiers are treated as equivalent only within a defined context.
|
||||
|
||||
Example:
|
||||
|
||||
- a pairwise OIDC subject mapped to a local account for one relying party.
|
||||
|
||||
### Operational Link
|
||||
|
||||
A system-level account link used for convenience, not necessarily a real-world identity assertion.
|
||||
|
||||
### Legal Identity Link
|
||||
|
||||
A stronger assertion that may support contracts, billing, employment, guardianship, or compliance.
|
||||
|
||||
### Privacy-Preserving Link
|
||||
|
||||
A link that enables continuity without exposing global identity.
|
||||
|
||||
Examples:
|
||||
|
||||
- pairwise identifiers;
|
||||
- pseudonymous handles;
|
||||
- tenant-local subjects.
|
||||
|
||||
## Synonymity Assertion Fields
|
||||
|
||||
A synonymity assertion should carry at least:
|
||||
|
||||
```text
|
||||
source
|
||||
target
|
||||
relation_type: same_as | probably_same_as | linked_to | represents | controls | acts_for
|
||||
strength: weak | medium | strong | authoritative
|
||||
scope
|
||||
evidence
|
||||
issuer/source_system
|
||||
created_at
|
||||
valid_from / valid_until
|
||||
revocation_state
|
||||
privacy_classification
|
||||
```
|
||||
|
||||
## Initial Conceptual Model Shape
|
||||
|
||||
```text
|
||||
Entity
|
||||
├─ Actor
|
||||
│ ├─ NaturalPerson
|
||||
│ ├─ CollectiveActor
|
||||
│ │ ├─ Organization
|
||||
│ │ ├─ LegalEntity
|
||||
│ │ ├─ Community
|
||||
│ │ ├─ FamilyOrHousehold
|
||||
│ │ └─ SpontaneousGroup
|
||||
│ └─ ArtificialActor
|
||||
│ ├─ ServiceAccount
|
||||
│ ├─ Bot
|
||||
│ └─ Agent
|
||||
├─ Account
|
||||
├─ Profile
|
||||
├─ Credential
|
||||
├─ Resource
|
||||
└─ Scope
|
||||
├─ Tenant
|
||||
├─ Realm
|
||||
├─ OrganizationScope
|
||||
├─ CommunityScope
|
||||
└─ ApplicationScope
|
||||
```
|
||||
|
||||
## Initial Relationship Model Shape
|
||||
|
||||
```text
|
||||
Relationship
|
||||
subject_entity_id
|
||||
relation_type
|
||||
object_entity_id
|
||||
scope_id
|
||||
source
|
||||
evidence_ref
|
||||
strength
|
||||
status
|
||||
valid_from
|
||||
valid_until
|
||||
metadata
|
||||
```
|
||||
|
||||
## Example Statements the Model Should Express
|
||||
|
||||
```text
|
||||
Bernd is member of Binect
|
||||
Binect is sub-organization of Whynot GmbH
|
||||
User account A is operated by Bernd
|
||||
ActivityPub actor @x follows @y
|
||||
Child account C is represented by guardian G
|
||||
Vendor tenant V provides application App1
|
||||
Customer tenant C consumes application App1
|
||||
Service account S acts for organization O in scope T
|
||||
OIDC subject sub123 is strongly linked to local account U in relying-party scope R
|
||||
Email e@example.com is weakly linked to person P based on imported evidence
|
||||
```
|
||||
|
||||
## CLI/UI Implications for Later Work
|
||||
|
||||
Although `identity-canon` is not an implementation repository, the model should later support convenient CLI/UI workflows such as:
|
||||
|
||||
```text
|
||||
create-person
|
||||
create-organization
|
||||
create-community
|
||||
create-family
|
||||
create-spontaneous-group
|
||||
create-tenant-for-actor
|
||||
invite-member
|
||||
link-account
|
||||
claim-domain
|
||||
assign-admin
|
||||
delegate-authority
|
||||
create-service-account
|
||||
create-agent
|
||||
add-follower-edge
|
||||
assert-synonymity
|
||||
review-synonymity
|
||||
revoke-link
|
||||
export-scim
|
||||
sync-ldap
|
||||
provision-keycloak
|
||||
```
|
||||
|
||||
These workflows should remain downstream implementation concerns.
|
||||
|
||||
## Working Hypothesis
|
||||
|
||||
A strong canonical model can be based on five orthogonal primitives:
|
||||
|
||||
```text
|
||||
Actor who/what can act
|
||||
Identity how an actor is represented or claimed in a context
|
||||
Scope where a statement has meaning
|
||||
Relationship how modeled things are connected
|
||||
Evidence why a statement is trusted
|
||||
```
|
||||
|
||||
From these, operational IAM concepts can be derived:
|
||||
|
||||
```text
|
||||
User = account/identity used by a natural person in a scope
|
||||
Tenant = operational scope with delegated administration
|
||||
Group = collective actor or membership set, depending on context
|
||||
Role = named relationship/policy pattern in a scope
|
||||
Org = structured collective actor
|
||||
Community = participatory collective actor
|
||||
Family = household/kinship collective actor
|
||||
```
|
||||
|
||||
## Research Direction
|
||||
|
||||
The next step is to populate the source-stack notes, extract terminology from each source, and create:
|
||||
|
||||
- terminology inventory;
|
||||
- terminology conflict map;
|
||||
- canonical glossary;
|
||||
- concept cards;
|
||||
- scenario tests;
|
||||
- conceptual model;
|
||||
- synonymity model;
|
||||
- scope model;
|
||||
- downstream recommendations.
|
||||
|
|
@ -0,0 +1,183 @@
|
|||
# Beneficial Ownership — CDD, BOI, and KYC Modeling
|
||||
|
||||
## Source Type
|
||||
|
||||
Regulatory framework synthesis. FinCEN CDD Rule (31 CFR 1010.230), Corporate
|
||||
Transparency Act / BOI reporting, FATF Recommendation 24, and KYC industry
|
||||
practice.
|
||||
|
||||
## Domain
|
||||
|
||||
Beneficial ownership identification for legal entity customers — financial
|
||||
institution due diligence, government transparency registries, and regulated
|
||||
commercial onboarding.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Beneficial ownership is the regulatory answer to "who really controls this
|
||||
legal entity customer?" It is **not** the same as corporate parent ownership
|
||||
(LEI Level 2), operational resource ownership (Cerbos), or CRM account hierarchy.
|
||||
Regulators impose **two independent prongs** (equity and control), trust
|
||||
look-through rules, nominee prohibitions, and evidence retention — all scoped
|
||||
to **counterparty risk**, not general graph semantics.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### FinCEN CDD Rule (customer due diligence)
|
||||
|
||||
- **Legal entity customer**: corporations, LLCs, general partnerships, and
|
||||
similar entities opening accounts at covered financial institutions.
|
||||
- **Beneficial owner — ownership prong**: each individual who directly or
|
||||
indirectly owns **25% or more** of equity interests.
|
||||
- **Beneficial owner — control prong**: a **single** individual with significant
|
||||
responsibility to control, manage, or direct the legal entity (e.g., CEO,
|
||||
CFO, managing member, general partner, president).
|
||||
- **Collection at account opening**: identify and verify BO identities when a
|
||||
new account opens (with 2026 exceptive relief allowing reuse after first
|
||||
account unless risk triggers update).
|
||||
- **Nominee prohibition**: legal entity must identify **ultimate** beneficial
|
||||
owners, not nominees or straw men.
|
||||
- **Trust look-through**: when a trust owns 25%+ equity, identify natural persons
|
||||
behind the trust (settlor, trustees, beneficiaries as applicable); a legal
|
||||
entity trustee does **not** satisfy the ownership prong — natural persons must
|
||||
be identified.
|
||||
- **Risk-based updates**: ongoing CDD may require BO refresh on triggering
|
||||
events, not only at opening.
|
||||
- **CIP alignment**: BO verification procedures must contain CIP-equivalent
|
||||
elements for individuals but are not identical to the institution's CIP.
|
||||
|
||||
### BOI / Corporate Transparency Act (entity reporting)
|
||||
|
||||
- **Distinct from CDD**: BOI is a **filing obligation on reporting companies**
|
||||
to FinCEN's BOI registry, not a financial-institution collection rule.
|
||||
- **Reporting company beneficial owner**: similar dual-prong concept (substantial
|
||||
ownership + substantial control) with FinCEN ID for individuals.
|
||||
- **US regulatory volatility (2025–2026)**: interim final rules and litigation
|
||||
have substantially narrowed or suspended BOI reporting for many US domestic
|
||||
entities. **CDD beneficial ownership collection by financial institutions
|
||||
remains in force** for covered institutions regardless of BOI reporting shifts.
|
||||
- **Foreign entities**: BOI and transparency expectations remain more relevant
|
||||
for non-US reporting companies and cross-border KYC.
|
||||
|
||||
### FATF Recommendation 24
|
||||
|
||||
- Requires countries to ensure adequate, accurate, and up-to-date **beneficial
|
||||
ownership information** on legal persons, accessible to competent authorities.
|
||||
- Supports **multi-prong** definitions (ownership threshold + control) and
|
||||
look-through for complex structures (trusts, nominees, layered ownership).
|
||||
- Drives national registries and financial-sector CDD alignment globally.
|
||||
|
||||
### KYC practice overlay
|
||||
|
||||
- Institutions may adopt **lower equity thresholds** for high-risk customers
|
||||
(e.g., 10%) under AML program risk policies.
|
||||
- **PEP screening** applies to beneficial owners, not only account signers.
|
||||
- **Sanctions screening** (OFAC) must cover identified beneficial owners.
|
||||
- BO evidence retained for years after relationship ends (BSA record retention).
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Beneficial owner | Natural person owning 25%+ or exercising substantial control. |
|
||||
| Ownership prong | Equity-interest threshold test. |
|
||||
| Control prong | Significant management/control responsibility test. |
|
||||
| Legal entity customer | Entity opening a financial account subject to CDD. |
|
||||
| CDD Rule | FinCEN customer due diligence requirements (2016, amended). |
|
||||
| BOI / CTA | Corporate Transparency Act beneficial ownership information reporting. |
|
||||
| FinCEN ID | Individual identifier for BOI filers. |
|
||||
| Nominee / straw man | Non-ultimate owner; prohibited as BO response under CDD. |
|
||||
| Look-through | Identifying natural persons behind trusts or intermediary entities. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Beneficial ownership is relationship semantics**, not a new actor type.
|
||||
The natural person remains **Natural Person**; the assertion is regulatory.
|
||||
- **Ownership prong and control prong are orthogonal** — one person may satisfy
|
||||
both, and multiple persons may satisfy ownership prong while exactly one
|
||||
control-prong person is required under US CDD.
|
||||
- **Beneficial ownership ≠ corporate parent ownership** (LEI Level 2 describes
|
||||
corporate structure; BO describes natural persons behind a customer entity).
|
||||
- **Beneficial ownership ≠ Representation** (authorized signers may represent
|
||||
without being beneficial owners).
|
||||
- **Lifecycle is risk-triggered**, not merely account-open/close.
|
||||
- **Regulatory regime is a scope dimension** — US CDD, EU AMLD, FATF R24, and
|
||||
BOI filing may differ; canon models the relationship, downstream applies law.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
### Resolved: dedicated relationship type
|
||||
|
||||
**Beneficial Ownership Relationship** is a first-class relationship type — **not**
|
||||
an Ownership subtype with `beneficial` metadata.
|
||||
|
||||
**Rationale:**
|
||||
|
||||
| Concern | Why not Ownership subtype |
|
||||
| --- | --- |
|
||||
| Semantic collision | Ownership in canon covers records, tenants, resources, corporate parents — not regulated natural-person BO. |
|
||||
| Dual prongs | Ownership prong (%) and control prong (role) are regulatory-specific; corporate Ownership edges lack this structure. |
|
||||
| Trust look-through | Requires intermediary entity traversal metadata absent from generic Ownership. |
|
||||
| Evidence & scope | BO ties to CDD/AML Evidence Source, Commercial Relationship, and jurisdictional scope — distinct lifecycle from LEI parent edges. |
|
||||
| Projection safety | Prevents Cerbos/Zanzibar "owner" tuples from silently implying KYC beneficial owner compliance. |
|
||||
|
||||
**Beneficial Owner** remains a glossary label for the **natural person** who is
|
||||
the target of a Beneficial Ownership Relationship — not a participation root.
|
||||
|
||||
### Recommended relationship fields
|
||||
|
||||
- `relationship_type`: `beneficial_ownership`
|
||||
- `source`: Natural Person
|
||||
- `target`: Organization / Legal Entity (the legal entity **customer**)
|
||||
- `scope`: jurisdiction + institution/program (e.g., US CDD, EU AMLD)
|
||||
- `ownership_prong`: boolean
|
||||
- `control_prong`: boolean
|
||||
- `equity_percentage`: optional numeric (when ownership prong)
|
||||
- `control_basis`: optional enum (e.g., `ceo`, `managing_member`, `general_partner`)
|
||||
- `intermediary_chain`: optional ordered list for trust/entity look-through
|
||||
- `evidence_reference`: CDD certification, BOI filing, registry extract
|
||||
- `lifecycle_state`: proposed, active, superseded, revoked
|
||||
- `regulatory_basis`: optional reference (CDD Rule, FATF R24, national statute)
|
||||
|
||||
### Mapping table
|
||||
|
||||
| Source concept | Canonical mapping |
|
||||
| --- | --- |
|
||||
| Beneficial owner (person) | Natural Person |
|
||||
| BO linkage | Beneficial Ownership Relationship |
|
||||
| CDD certification | Evidence Source |
|
||||
| Legal entity customer | Organization / Legal Entity + Commercial Relationship |
|
||||
| BOI filing record | Evidence Source (registry) on Legal Entity |
|
||||
| FinCEN ID | Identifier (government registry) on Natural Person |
|
||||
| PEP/sanctions hit on BO | Lifecycle State / Trust Relationship on BO relationship |
|
||||
| LEI Level 2 parent | Ownership Relationship (corporate structure — separate) |
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Beneficial owner (CDD)** vs. **beneficial owner (BOI filing)** vs.
|
||||
**beneficial owner (transparency registry)**: same conceptual person, different
|
||||
regulatory scopes and evidence — use `scope` and `regulatory_basis` metadata.
|
||||
- **Owner (Cerbos resource)** vs. **beneficial owner**: authorization attribute
|
||||
vs. regulated natural-person linkage.
|
||||
- **Shareholder** vs. **beneficial owner**: not all shareholders meet BO thresholds;
|
||||
control prong may identify non-shareholders.
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- `control_basis` enum — jurisdiction-neutral role codes + `regulatory_basis`.
|
||||
- FinCEN ID → **Registry Identifier** on Natural Person.
|
||||
- Exempt entities → **Beneficial Ownership Exemption** Evidence (not absence).
|
||||
- BOI filing volatility separated from CDD Beneficial Ownership Relationships.
|
||||
|
||||
## References
|
||||
|
||||
- FinCEN, CDD Rule FAQs — https://www.fincen.gov/resources/statutes-and-regulations/cdd-rule-faqs
|
||||
- FinCEN, CDD Final Rule — https://www.fincen.gov/resources/statutes-regulations/cdd-final-rule
|
||||
- FinCEN, Account Opening Exceptive Relief Order (FIN-2026-R001) — https://www.fincen.gov/system/files/2026-02/FinCEN-Order-CCDExceptiveRelief.pdf
|
||||
- FATF, Recommendation 24 — https://www.fatf-gafi.org/en/topics/fatf-recommendations.html
|
||||
- Open Ownership, reliable identifiers for corporate vehicles — https://www.openownership.org/en/publications/using-reliable-identifiers-for-corporate-vehicles-in-beneficial-ownership-data/
|
||||
- Internal: `kyc-aml-commercial-identity-binding.md`, `lei-gleif-legal-entity-identifier.md`
|
||||
|
|
@ -0,0 +1,240 @@
|
|||
# Commercial Identity Nuance Settlement (2026)
|
||||
|
||||
## Source Type
|
||||
|
||||
identity-canon adjudication note — resolves remaining open questions and
|
||||
"remaining nuance" items across the commercial-identity research stack.
|
||||
|
||||
## Domain
|
||||
|
||||
Standard enums, cross-registry linking rules, regulatory layering, and adapter
|
||||
guidance for commercial identity edge cases.
|
||||
|
||||
## Beneficial Ownership Nuances
|
||||
|
||||
### `control_basis` enum (settled)
|
||||
|
||||
Use a **jurisdiction-neutral role code** on Beneficial Ownership Relationship,
|
||||
plus `regulatory_basis` for program-specific rules.
|
||||
|
||||
| `control_basis` | Typical sources |
|
||||
| --- | --- |
|
||||
| `senior_managing_official` | FATF generic; US CDD control prong when no other role fits |
|
||||
| `chief_executive` | CEO, managing director, president, executive director |
|
||||
| `chief_financial` | CFO, treasurer with control |
|
||||
| `managing_member` | LLC managing member |
|
||||
| `general_partner` | Partnership general partner |
|
||||
| `board_chair` | Chair with operational control |
|
||||
| `trustee` | Trust with management control |
|
||||
| `settlor_with_control` | Settlor retaining control over trust |
|
||||
| `other_control` | Catch-all — require `control_basis_detail` free text |
|
||||
|
||||
`regulatory_basis` values: `us_cdd`, `us_boi_cta`, `eu_amld`, `fatf_r24`, `national_statute`.
|
||||
|
||||
US CDD "significant responsibility to control, manage, or direct" maps to the
|
||||
most specific code available, else `senior_managing_official`. EU AMLD "senior
|
||||
managing official" maps directly. Store **one** control-prong person per US CDD
|
||||
rule; multiple ownership-prong persons allowed.
|
||||
|
||||
### FinCEN ID (settled)
|
||||
|
||||
FinCEN ID for BOI filers maps to **Registry Identifier**:
|
||||
|
||||
- `authority_class: government_registry`
|
||||
- `scheme: fincen_individual_id` (or jurisdiction-specific extension)
|
||||
- `jurisdiction: US`
|
||||
- Attached to **Natural Person**, not Organization.
|
||||
|
||||
### Exempt legal entity customers (settled)
|
||||
|
||||
Do not rely on absence of Beneficial Ownership Relationships. Record explicit
|
||||
**Beneficial Ownership Exemption** as **Evidence Source** on the Legal Entity /
|
||||
Organization with:
|
||||
|
||||
- `exemption_type`: `publicly_traded`, `government_entity`, `regulated_financial_institution`, `subsidiary_of_exempt_parent`, `other`
|
||||
- `regulatory_basis`, `evidence_reference`, `lifecycle_state`
|
||||
|
||||
Absence alone is ambiguous (not collected vs. exempt vs. not applicable).
|
||||
|
||||
### BOI filing volatility vs. CDD (settled)
|
||||
|
||||
Separate regulatory layers in canon — do not merge:
|
||||
|
||||
| Layer | Canon artifact | Volatility |
|
||||
| --- | --- | --- |
|
||||
| CDD beneficial ownership | Beneficial Ownership Relationship | Stable for covered FIs; collection obligation endures |
|
||||
| BOI registry filing | Evidence Source (`evidence_type: boi_filing`) | Jurisdiction-dependent; track lifecycle downstream |
|
||||
| Transparency registry | Evidence Source (`evidence_type: bo_registry_extract`) | Per national register |
|
||||
|
||||
Canon does not prescribe legal outcomes; downstream adapters apply current statute.
|
||||
CDD relationships remain even when BOI filing requirements change.
|
||||
|
||||
## Registry Identifier Nuances
|
||||
|
||||
### `authority_class` extension (settled)
|
||||
|
||||
Add `industry_association` for identifiers issued by trade, standards, or
|
||||
procurement bodies without government incorporation authority:
|
||||
|
||||
- NCAGE / CAGE (defense supplier ID)
|
||||
- GS1 GLN when used as organization/location key in supply chain
|
||||
|
||||
Retain `government_registry`, `regulatory_global`, `commercial_proxy`, `tax`.
|
||||
|
||||
### Cross-registry Synonymity strength (settled)
|
||||
|
||||
| Link | Default strength | Notes |
|
||||
| --- | --- | --- |
|
||||
| LEI ↔ national company reg / ALEI | **strong** | Same legal entity when LOU or government register confirms |
|
||||
| LEI ↔ UEI | **strong** | When SAM.gov or authoritative crosswalk confirms |
|
||||
| LEI ↔ DUNS | **medium** | D&B may assign per location; proxy authority |
|
||||
| DUNS ↔ UEI | **medium** | Historical procurement migration |
|
||||
| DUNS ↔ company reg | **medium** | Branch/location mismatch common |
|
||||
| company reg ↔ ALEI | **authoritative** | Same register encoding |
|
||||
|
||||
Use `relation_type: same_as` when strength is strong or authoritative;
|
||||
`linked_to` for medium. Require `evidence_reference` (crosswalk, operator verify).
|
||||
|
||||
### ISO 6523 OPI / branch modeling (settled)
|
||||
|
||||
ISO 6523 **organization part identifier (OPI)** models a **branch or org unit**,
|
||||
not a separate legal entity by default:
|
||||
|
||||
- Store OPI on **Registry Identifier** as optional `organization_part_id`.
|
||||
- Map branch to **Organization Unit** (Group specialization) or child **Organization**
|
||||
when operationally distinct.
|
||||
- Branch DUNS + parent LEI: link branch Proxy Commercial Identifier to parent
|
||||
Organization via structural relationship; Synonymity Assertion (medium) between
|
||||
branch DUNS and parent LEI when same legal entity confirmed.
|
||||
|
||||
## Reputation and Assurance Nuances
|
||||
|
||||
### `assurance_tier` vs. numeric score (settled)
|
||||
|
||||
**Primary:** `assurance_tier` enum (`opinion` | `observed` | `committed` | `adjudicated`).
|
||||
|
||||
**Optional:** `numeric_score` + `score_scale` on Evidence Source for downstream
|
||||
(e.g., PAYDEX 0–100, star rating 1–5). Downstream maps score ranges to tiers;
|
||||
canon does not merge tiers from scores alone.
|
||||
|
||||
### Platform escrow without separate contract (settled)
|
||||
|
||||
Segregated escrow with defined release conditions is **committed** tier:
|
||||
|
||||
- Model **Commercial Commitment** `commitment_type: escrow`
|
||||
- Evidence Source: platform escrow terms, payment-provider escrow object, or
|
||||
marketplace buyer-protection policy accepted at transaction time
|
||||
- Funds segregation + conditional release = commitment, not merely observed metric
|
||||
|
||||
### Cross-platform reputation portability (settled)
|
||||
|
||||
Portable reputation uses **Synonymity Assertion** between **Reputation Signal**
|
||||
Evidence Sources:
|
||||
|
||||
- Default `relation_type: linked_to` (not `same_as`)
|
||||
- Default strength: **weak**
|
||||
- Upgrade to medium only with verified identity bridge (same Natural Person proof,
|
||||
verified purchase on both platforms, operator confirmation)
|
||||
- Require `portability_evidence` reference; scope must list both platforms
|
||||
|
||||
### Smart-contract / oracle outcomes (settled)
|
||||
|
||||
| Outcome type | Tier | Canon |
|
||||
| --- | --- | --- |
|
||||
| On-chain condition check (oracle, escrow release) | observed | Performance Evidence |
|
||||
| Binding ADR with identified parties (incl. on-chain tribunal with published rules) | adjudicated | Adjudication Outcome |
|
||||
| Court judgment enforced on-chain | adjudicated | Adjudication Outcome |
|
||||
|
||||
Automation alone does not elevate to adjudicated without identifiable dispute
|
||||
authority and parties.
|
||||
|
||||
## Payment Nuances
|
||||
|
||||
### Network tokens e.g. Visa VTS (settled)
|
||||
|
||||
Network tokens map to **Payment Instrument Reference**:
|
||||
|
||||
- `instrument_type: network_token`
|
||||
- `network_token_service` (e.g., `visa_vts`, `mastercard_mdes`)
|
||||
- Same lifecycle and PCI boundary as `pm_xxx` references
|
||||
|
||||
### Shared payment methods across org customers (settled)
|
||||
|
||||
One Payment Instrument Reference may attach to **multiple Commercial Records**
|
||||
within the same payment-provider org **Scope**:
|
||||
|
||||
- `sharing_scope: payment_provider_org`
|
||||
- `shared_across_records: [commercial_record_ids]`
|
||||
- Do not Synonymity-merge Commercial Records — only share the instrument reference
|
||||
|
||||
### Customer wallet balance (settled)
|
||||
|
||||
Provider ledger balance (Stripe Customer balance) is a **Commercial Record**
|
||||
attribute `provider_ledger_balance` — not a Credential, not a Commercial Commitment.
|
||||
Currency and provider scope required.
|
||||
|
||||
## CRM and Pipeline Nuances
|
||||
|
||||
### `binding_trigger` enum (settled)
|
||||
|
||||
| Value | Commitment state | Typical evidence |
|
||||
| --- | --- | --- |
|
||||
| `quote_accepted` | proposed | CPQ acceptance, e-sign |
|
||||
| `loi_signed` | proposed | Signed LOI |
|
||||
| `purchase_order_executed` | active | PO record |
|
||||
| `contract_executed` | active | Signed agreement |
|
||||
| `subscription_activated` | active | Billing webhook |
|
||||
| `regulatory_onboarding_complete` | active | KYC/KYB completion |
|
||||
| `org_policy_closed_won` | active only if org maps Closed Won → executed contract **and** policy documented as Evidence |
|
||||
|
||||
`org_policy_closed_won` is downstream-configured; canon requires explicit Evidence.
|
||||
|
||||
### Renewal Opportunity (settled)
|
||||
|
||||
| Situation | Canon treatment |
|
||||
| --- | --- |
|
||||
| Renewal on existing contract (same agreement extended) | **Commitment amendment** Evidence on existing Commercial Commitment; optional Pipeline Pursuit for forecast tracking |
|
||||
| Competitive rebid / new agreement cycle | New **Pipeline Pursuit** |
|
||||
| Material term change | Commitment amendment + may create Pipeline Pursuit |
|
||||
|
||||
Rule: if `amends_commitment_id` is set and change type is `renewal` or `amendment`,
|
||||
do not create a new root Commercial Commitment unless terms are net-new contract.
|
||||
|
||||
### Partner vs. customer Opportunity (settled)
|
||||
|
||||
Same **Pipeline Pursuit** type with `pursuit_role`:
|
||||
|
||||
- `customer` (default)
|
||||
- `partner` (channel, alliance)
|
||||
- `vendor` (reverse sourcing)
|
||||
|
||||
Role affects **Commercial Relationship** typing, not Pipeline Pursuit structure.
|
||||
|
||||
### Person Account adapter guidance (settled)
|
||||
|
||||
Salesforce Person Account and similar B2C shortcuts:
|
||||
|
||||
- **Canon storage:** Natural Person + Commercial Record (split layers)
|
||||
- **Adapter projection:** `projection_mode: person_account_combined` on export only
|
||||
- Do not introduce Person Account as canonical root; discourage unified tables in
|
||||
downstream schema without layer tags
|
||||
|
||||
## eIDAS / EUDI Nuances (commercial stack)
|
||||
|
||||
### Qualified electronic seal (settled)
|
||||
|
||||
Maps to **Credential** with `credential_type: qualified_seal`, bound to
|
||||
**Organization** / **Legal Entity** through **Representation Relationship**
|
||||
(signing officer or mandated agent). Distinct from login Credential.
|
||||
|
||||
### EUDI organizational wallet Scope (settled)
|
||||
|
||||
Organizational wallet is a **Scope** specialization (`wallet_scope`) holding
|
||||
wallet-hosted **Credentials** and **Claims** — not a **Tenant** (no admin
|
||||
isolation semantics). Link wallet Scope to **Commercial Record** and Organization
|
||||
actor via Commercial Relationship.
|
||||
|
||||
## References
|
||||
|
||||
All prior commercial-identity source notes. This note supersedes their Open
|
||||
Questions sections where marked settled below.
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
# Commercial Identity Synthesis
|
||||
|
||||
## Source Type
|
||||
|
||||
identity-canon research synthesis connecting commercial theory, law, regulation,
|
||||
and software practice to the canonical model.
|
||||
|
||||
## Domain
|
||||
|
||||
Cross-cutting commercial identity — binding, trust, persistence, and layer separation.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
This note captures the research prompt: **identity and commerce are tightly coupled
|
||||
in practice**. Conceptual or login-only identity can remain fluid when no commercial
|
||||
value or enforceable promises attach. **Commercial binding** increases an identity's
|
||||
relevance to other actors and creates foundations for trust, shared information, and
|
||||
durable relationships.
|
||||
|
||||
## The Binding Gradient
|
||||
|
||||
| Stage | Commercial stake | Identity behavior | Canon pattern |
|
||||
| --- | --- | --- | --- |
|
||||
| Anonymous browse | None | Fluid, discardable | Persona, ephemeral Identifier |
|
||||
| Free trial / lead | Low | Pseudonymous, reversible | Account + weak Commercial Record |
|
||||
| Paying subscriber | Medium | Stable tenant + billing ID | Organization + Tenant + Commercial Record |
|
||||
| KYC/AML customer | High | Verified, monitored, retained | Commercial Record + Evidence + BO linkage |
|
||||
| Regulated markets (LEI) | Very high | Renewed legal identity, ownership public | Legal Entity + LEI Identifier + Lifecycle |
|
||||
| Contractual enterprise | High | Agency, seals, signatures | Commercial Commitment + Representation |
|
||||
|
||||
**Insight:** fluidity is not a bug — it is rational when commercial externalities are
|
||||
absent. Binding is what makes identity **economically and legally salient**.
|
||||
|
||||
## Layer Model (Commercial + Identity)
|
||||
|
||||
```text
|
||||
Actor Layer Natural Person, Organization, Legal Entity
|
||||
Record Layer Account (access), Commercial Record (billing/CRM/regulatory)
|
||||
Reference Layer Identifiers (LEI, DUNS, UEI, VAT, stripe_customer_id)
|
||||
Relationship Layer Commercial Relationship, Representation, Ownership, Trust
|
||||
Commitment Layer Commercial Commitment (contract, subscription, payment mandate)
|
||||
Evidence Layer KYC files, credit history, registry extracts, qualified credentials
|
||||
Projection Layer Auth Subject, Auth Principal (unchanged — not commercial roots)
|
||||
```
|
||||
|
||||
Commerce does not replace identity layers; it **selectively hardens** them when
|
||||
counterparties must rely, sue, invoice, or report.
|
||||
|
||||
## How Binding Creates Trust
|
||||
|
||||
From commercial theory and practice:
|
||||
|
||||
1. **Attribution**: counterparties know **who** bears liability (legal person, BO, agent).
|
||||
2. **Commitment**: contracts, subscriptions, and payment authorizations create **costly exit**.
|
||||
3. **Evidence**: KYC, LEI, registry credentials, and credit files provide **verifiable history**.
|
||||
4. **Reputation / assurance**: tiered reliance from opinion signals (reviews) through
|
||||
observed metrics (PAYDEX) to committed stakes (bonds) and adjudicated outcomes
|
||||
(courts) — see **Counterparty Assurance Gradient**.
|
||||
5. **Enforcement**: law of agency and contract makes promises **actionable** beyond platform ToS.
|
||||
|
||||
Trust Relationship in canon should often be **justified by** Commercial Relationship +
|
||||
Commercial Commitment + Evidence, not declared ad hoc.
|
||||
|
||||
## Software Mirrors (Practical)
|
||||
|
||||
| System | Commercial artifact | Identity separation lesson |
|
||||
| --- | --- | --- |
|
||||
| Stripe | Customer | Billing ≠ login |
|
||||
| Salesforce | Account / Contact | CRM ≠ User |
|
||||
| Auth0/Stytch | Organization / Member | Subscriber ≠ billing record |
|
||||
| KYC platforms | Customer profile + BO | Regulated counterparty ≠ session |
|
||||
| GLEIF | LEI | Legal entity ID for markets |
|
||||
| D&B | DUNS + PAYDEX | Credit identity + reputation |
|
||||
| eIDAS/EUDI | Legal person wallet | Qualified org credentials |
|
||||
|
||||
## Canon Decisions From This Research
|
||||
|
||||
### Rejected
|
||||
|
||||
- **Customer Account** as canonical type (overloads layers).
|
||||
|
||||
### Added / strengthened
|
||||
|
||||
- **Commercial Record** — billing, CRM, regulatory counterparty records.
|
||||
- **Commercial Relationship** — vendor/customer commercial link.
|
||||
- **Commercial Commitment** — enforceable or costly promise binding parties (contract,
|
||||
subscription, payment mandate, regulatory onboarding acceptance).
|
||||
- **Beneficial Ownership Relationship** — dedicated type from Natural Person to
|
||||
Organization/Legal Entity for KYC/CDD (not Ownership subtype).
|
||||
- **Registry Identifier** and **Proxy Commercial Identifier** — Reference layer
|
||||
subtypes with authority class, ICD scheme, and renewal lifecycle.
|
||||
- **Counterparty Assurance Gradient** — opinion → observed → committed →
|
||||
adjudicated; Reputation Signal, Performance Evidence, Adjudication Outcome.
|
||||
- **Payment Instrument Reference** + **Payment Mandate** — PCI boundary; not Credential.
|
||||
- **Pipeline Pursuit** — CRM Opportunity before Commercial Commitment promotion.
|
||||
|
||||
### Unchanged roots
|
||||
|
||||
- **Actor** remains participation root.
|
||||
- **Account** remains operational access record.
|
||||
- Login, authz, and social layers unchanged; commerce **binds** them when stakes require.
|
||||
|
||||
## Fluid ↔ Bound Transitions
|
||||
|
||||
Model as lifecycle events, not silent merges:
|
||||
|
||||
- Lead → Account (CRM conversion): weak → medium evidence.
|
||||
- Opportunity opened: Pipeline Pursuit — not Commercial Commitment until binding trigger.
|
||||
- Trial → paid subscription: Commercial Commitment (subscription) + Payment Mandate
|
||||
+ Payment Instrument Reference.
|
||||
- Org onboarding → KYC complete: raise Assurance Level, add BO relationships.
|
||||
- Pseudonym → verified legal person: Synonymity Assertion with strength upgrade and scope change.
|
||||
|
||||
## Scenario Impact
|
||||
|
||||
- **S04 (vendor/customer tenants)**: add Commercial Record per customer tenant, Commercial
|
||||
Commitment for subscription/contract.
|
||||
- **S14 (pseudonymous profile)**: incompatible with active Commercial Commitment unless
|
||||
explicitly scoped (e.g., marketplace escrow with privacy partition).
|
||||
- **S15 (legal entity + tenants)**: LEI/registry Identifier + Commercial Record + renewals.
|
||||
|
||||
## Research Gaps
|
||||
|
||||
- Smart contracts and automated Commercial Commitment lifecycle (implementation patterns).
|
||||
- National statute variants beyond settled enum baselines (downstream legal config).
|
||||
|
||||
## Nuance settlement
|
||||
|
||||
Commercial identity edge-case enums and linking rules are consolidated in
|
||||
`commercial-identity-nuance-settlement.md` (2026).
|
||||
|
||||
## Source Notes in This Stack
|
||||
|
||||
- `commercial-trust-binding-theory.md`
|
||||
- `legal-person-agency-contract.md`
|
||||
- `lei-gleif-legal-entity-identifier.md`
|
||||
- `duns-commercial-credit-identity.md`
|
||||
- `kyc-aml-commercial-identity-binding.md`
|
||||
- `eidas-eudi-legal-person-wallet.md`
|
||||
- `salesforce-crm-commercial-record.md`
|
||||
- `beneficial-ownership-kyc-boi.md`
|
||||
- `registry-identifier-subtypes.md`
|
||||
- `reputation-assurance-gradient.md`
|
||||
- `payment-credential-pci-boundary.md`
|
||||
- `crm-pipeline-commitment-threshold.md`
|
||||
- `commercial-identity-nuance-settlement.md`
|
||||
- `../commercial-subscription/b2b-saas-subscriber-tenancy.md`
|
||||
- `../commercial-subscription/stripe-customer-billing.md`
|
||||
|
||||
## References
|
||||
|
||||
See individual source notes. Primary external anchors: GLEIF/ISO 17442, FinCEN CIP,
|
||||
EU eIDAS, D&B DUNS, Salesforce Account model, Auth0/Stytch org tenancy, FATF digital identity.
|
||||
|
|
@ -0,0 +1,119 @@
|
|||
# Commercial Trust and Identity Binding Theory
|
||||
|
||||
## Source Type
|
||||
|
||||
Academic and industry synthesis. Transaction-cost economics, contract performance
|
||||
literature, digital trust research, and identity-canon conceptual framing.
|
||||
|
||||
## Domain
|
||||
|
||||
Commercial theory, trust formation, identity persistence, and the economic
|
||||
function of binding commitments.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Practitioners often treat login identity and billing identity as separate
|
||||
accidents of software architecture. Commercial theory suggests a deeper
|
||||
pattern: **commercially unbound identities stay fluid**; **commercially bound
|
||||
identities become durable points of coordination** for trust, information
|
||||
sharing, and enforceable promises.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Fluid identity**: participation with low exit cost and weak external reliance;
|
||||
pseudonymous handles, trial accounts, anonymous browsing.
|
||||
- **Commercial binding**: attachment of economic or legal obligation to an
|
||||
identity representation (payment authorization, contract, subscription, KYC
|
||||
onboarding, credit exposure).
|
||||
- **Reputation capital**: value accumulated when past performance is observable
|
||||
and attributable to a stable identity.
|
||||
- **Transaction costs**: search, bargaining, monitoring, and enforcement costs
|
||||
that trust mechanisms reduce (Williamson, Coase tradition).
|
||||
- **Contract performance assurance**: market and legal mechanisms ensuring
|
||||
parties keep promises (bonding, hostages, repeat play, legal enforcement).
|
||||
- **Transient trust**: short-lived trust between previously unknown parties
|
||||
enabled by verified credentials and real-time assurance (EU digital wallet
|
||||
discourse).
|
||||
- **Perpetual master data**: continuous re-validation of enterprise identity
|
||||
attributes once commercial relationships depend on accuracy (KYC/KYB, LEI
|
||||
renewal).
|
||||
- **Counterparty risk**: commercial exposure to wrong or misidentified party;
|
||||
drives identity rigor.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Binding | Attachment of enforceable or costly-to-break obligation. |
|
||||
| Commitment | Promise backed by legal, financial, or reputational stake. |
|
||||
| Trust | Willingness to rely on another party under uncertainty. |
|
||||
| Reputation | Observable history attributed to an identity. |
|
||||
| Fluid identity | Low-stakes, easily abandoned or rotated representation. |
|
||||
| Bound identity | Identity whose change imposes cost on self or counterparties. |
|
||||
| Assurance | Mechanism increasing confidence in performance or identity. |
|
||||
| Counterparty | Other party in a commercial transaction. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- Identity relevance scales with **stakes of reliance** by other parties.
|
||||
- Without commercial binding, actors optimize for **low friction and privacy**
|
||||
(fluid personas, ephemeral identifiers).
|
||||
- Commercial activity introduces **attribution requirements** (who invoiced,
|
||||
who signed, who is liable).
|
||||
- Trust between commercial actors rests on **identity stability + evidence +
|
||||
enforceable commitments**, not on profile richness alone.
|
||||
- Digital systems separate layers (login, CRM, billing, KYC) but commercial
|
||||
reality treats them as **one counterparty** when risk is integrated.
|
||||
- Reputation and legal liability create **path dependence**: past bindings make
|
||||
future identity changes costly (account migration, LEI renewal, contract novation).
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Distinguish **fluid participation** (Actor/Persona/Account with no commercial
|
||||
commitment) from **commercially bound participation** (Commercial Record +
|
||||
Commercial Relationship + Commercial Commitment).
|
||||
- **Trust Relationship** in canon should often be **downstream of** Commercial
|
||||
Relationship and evidenced commitments, not a substitute for them.
|
||||
- **Synonymity Assertion** strength should rise when commercial counterparty
|
||||
risk requires deterministic matching (KYC, LEI, registry ID).
|
||||
- **Lifecycle State** on commercial artifacts gates access and trust (subscription
|
||||
active, delinquent, KYC expired, LEI lapsed).
|
||||
- User insight formalized: conceptual identity without commercial binding may
|
||||
remain intentionally fluid; binding increases **relevance to other commercial
|
||||
actors** and justifies **stronger identifiers and promises**.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Trust (social)** vs. **trust (commercial)**: following ≠ credit trust.
|
||||
- **Identity (conceptual)** vs. **identity (counterparty)**: philosophy vs. KYC record.
|
||||
- **Binding (technical)** vs. **binding (legal)**: OIDC binding ≠ contract.
|
||||
- **Reputation (brand)** vs. **reputation (performance history)**: marketing vs. credit.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Theory concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Fluid identity | Persona / Scoped Identifier without Commercial Commitment |
|
||||
| Commercial binding | Commercial Commitment on Commercial Relationship |
|
||||
| Reputation capital | Performance Evidence history + Trust Relationship (assurance_basis) |
|
||||
| Star ratings / reviews | Reputation Signal (opinion tier) |
|
||||
| Counterparty identification | Commercial Record + Legal Entity + Identifiers |
|
||||
| Contractual promise | Commercial Commitment (contract subtype) |
|
||||
| Assurance mechanism | Assurance Level + Evidence Source |
|
||||
| Transient trust | Trust Relationship with short lifecycle + VC/qualified ID |
|
||||
| Perpetual MDM | Ongoing Evidence Source refresh on Commercial Record |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should Commercial Commitment be a Relationship subclass or metadata on
|
||||
Commercial Relationship?
|
||||
- How should fluid-to-bound transitions be modeled (trial → paid, anonymous → KYC)?
|
||||
- Resolved: tiered Evidence Source pattern — see `reputation-assurance-gradient.md`.
|
||||
|
||||
## References
|
||||
|
||||
- Klein and Leffler (1981), role of market forces in contractual performance
|
||||
- Williamson, transaction cost economics (institutional trust)
|
||||
- FATF Guidance on Digital Identity (trust frameworks for financial identity)
|
||||
- Spherity/EUDI organizational wallet discourse on transient trust and perpetual MDM
|
||||
- identity-canon ResearchSeed (trust, synonymity, evidence)
|
||||
|
|
@ -0,0 +1,157 @@
|
|||
# CRM Pipeline and Commercial Commitment Threshold
|
||||
|
||||
## Source Type
|
||||
|
||||
Product data model and sales-operations synthesis. Salesforce Opportunity stages,
|
||||
forecast categories, and contract-law binding thresholds.
|
||||
|
||||
## Domain
|
||||
|
||||
When CRM pipeline artifacts (Opportunity, deal stage, forecast) constitute
|
||||
canonical **Commercial Commitment** vs. provisional pursuit evidence only.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Salesforce **Opportunity** tracks potential revenue — but most pipeline stages are
|
||||
**forecasts**, not enforceable obligations. Treating every Opportunity as
|
||||
Commercial Commitment would:
|
||||
|
||||
- falsely elevate identity binding during early prospecting;
|
||||
- collide with **Counterparty Assurance Gradient** (pipeline ≠ committed tier);
|
||||
- ignore that **Closed Won** often precedes executed contract in real orgs.
|
||||
|
||||
Canon needs a **promotion threshold** — when pipeline becomes commitment.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### Salesforce Opportunity model
|
||||
|
||||
- **Opportunity**: deal record tied to Account; amount, stage, close date, forecast.
|
||||
- **Stage**: position in sales process (e.g., Prospecting → Proposal → Negotiation
|
||||
→ Closed Won / Closed Lost).
|
||||
- **Forecast category**: Pipeline, Best Case, Commit, Closed — revenue prediction
|
||||
semantics, not legal commitment.
|
||||
- **Closed Won**: deal marked won in CRM — operational signal; may or may not
|
||||
coincide with signed contract depending on org process.
|
||||
- **Closed Lost**: pursuit ended — no commitment.
|
||||
- **Quote / Order** (CPQ): closer to binding when customer accepts quote or order
|
||||
is placed — stronger evidence than early stage.
|
||||
|
||||
### Binding threshold (legal/commercial)
|
||||
|
||||
A **Commercial Commitment** requires evidenced obligation that raises counterparty
|
||||
reliance — aligned with canon definition and tier 3 assurance:
|
||||
|
||||
| Signal | Binding strength | Canon treatment |
|
||||
| --- | --- | --- |
|
||||
| Lead created | None | Pipeline Pursuit or weak Commercial Record |
|
||||
| Opportunity Prospecting | None | Pipeline Pursuit |
|
||||
| Opportunity Proposal | Low | Pipeline Pursuit + stage Evidence |
|
||||
| Signed quote / LOI | Medium | Commercial Commitment `proposed` |
|
||||
| Executed PO / order | High | Commercial Commitment `active` |
|
||||
| Closed Won (CRM only) | Org-dependent | `proposed` until contract Evidence |
|
||||
| Signed MSA / SOW | High | Commercial Commitment `active` |
|
||||
| Active subscription (Stripe) | High | Commercial Commitment `active` (billing) |
|
||||
|
||||
**Rule:** CRM stage alone is **never sufficient** for `active` Commercial Commitment
|
||||
unless org policy equates Closed Won with executed agreement **and** that policy
|
||||
is recorded as Evidence Source (downstream configuration).
|
||||
|
||||
### Fluid-to-bound transition
|
||||
|
||||
Lead → Account conversion raises commercial attribution (Organization +
|
||||
Commercial Record). Opportunity creation adds **Pipeline Pursuit**. Commitment
|
||||
materializes only at binding trigger — not at Opportunity create.
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Pipeline is prospective** — counterparties may rely for forecasting internally
|
||||
but external legal reliance is limited until commitment artifacts exist.
|
||||
- **Multiple Opportunities** per Account are normal; commitments may coexist.
|
||||
- **Opportunity amount** is expected value, not obligation amount until contracted.
|
||||
- **Forecast Commit category** (Salesforce) is sales-team confidence, not legal
|
||||
commitment — do not map to Commercial Commitment `active`.
|
||||
- **CPQ Quote accepted** or **e-signature completed** are valid binding triggers
|
||||
with Evidence Source.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
### Resolved: Opportunity is not Commercial Commitment by default
|
||||
|
||||
Map Salesforce **Opportunity** (and HubSpot deal, etc.) to **Pipeline Pursuit** —
|
||||
Record layer artifact for in-flight commercial deal pursuit.
|
||||
|
||||
**Pipeline Pursuit** fields:
|
||||
|
||||
- `source_system` — Salesforce, HubSpot, etc.
|
||||
- `stage` — vendor stage name (Prospecting, Negotiation, Closed Won, …)
|
||||
- `forecast_category` — pipeline, best_case, commit, closed
|
||||
- `expected_amount`, `expected_close_date`
|
||||
- `linked_commercial_record` — CRM Account / Commercial Record
|
||||
- `lifecycle_state` — open, won, lost, abandoned
|
||||
- `binding_status` — `none` | `proposed` | `active` (derived from evidence, not stage alone)
|
||||
|
||||
### Promotion to Commercial Commitment
|
||||
|
||||
Create or activate **Commercial Commitment** only when `binding_trigger` satisfied:
|
||||
|
||||
| Trigger | Commitment state | Evidence |
|
||||
| --- | --- | --- |
|
||||
| Signed LOI / quote acceptance | `proposed` | Document, e-sign event |
|
||||
| Executed PO / order | `active` | Order record |
|
||||
| Closed Won + contract on file | `active` | Contract Evidence Source |
|
||||
| Subscription checkout complete | `active` | Stripe webhook (billing) |
|
||||
| Stage-only Closed Won | **No auto-promotion** | Pipeline Pursuit `won` only |
|
||||
|
||||
**Pipeline Pursuit** may **reference** a Commercial Commitment once promoted;
|
||||
do not replace Opportunity with commitment in CRM adapters — mirror both.
|
||||
|
||||
### What Opportunity stage provides
|
||||
|
||||
Stage changes produce **Evidence Source** events on Pipeline Pursuit (observed
|
||||
tier — internal sales telemetry). They support **Trust Relationship** only for
|
||||
**internal** vendor forecasting, not external counterparty assurance at tier 3.
|
||||
|
||||
### Lead and Account (unchanged)
|
||||
|
||||
- **Lead** → provisional prospect (weak Commercial Record or Pipeline Pursuit seed).
|
||||
- **Account** → **Commercial Record** + Organization.
|
||||
- **Opportunity** → **Pipeline Pursuit** (not Commercial Commitment).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Opportunity (CRM)** vs. **Commercial Commitment**: forecast vs. obligation.
|
||||
- **Forecast Commit (Salesforce)** vs. **Commercial Commitment (canon)**: homonym disaster.
|
||||
- **Closed Won** vs. **contract signed**: CRM ops vs. legal binding.
|
||||
- **Deal (informal)** vs. **Pipeline Pursuit**: resolve to Pipeline Pursuit.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| CRM concept | Canonical mapping |
|
||||
| --- | --- |
|
||||
| Account | Commercial Record + Organization |
|
||||
| Contact | Natural Person |
|
||||
| Lead | Pipeline Pursuit (seed) / weak Commercial Record |
|
||||
| Opportunity | Pipeline Pursuit |
|
||||
| Stage change | Evidence Source on Pipeline Pursuit |
|
||||
| Quote accepted | Commercial Commitment `proposed` |
|
||||
| Order / contract executed | Commercial Commitment `active` |
|
||||
| Closed Lost | Pipeline Pursuit lifecycle `lost` |
|
||||
| Forecast category "Commit" | Pipeline Pursuit metadata only |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- `binding_trigger` enum — seven values including `org_policy_closed_won`.
|
||||
- Renewal on same contract → commitment amendment; rebid → new Pipeline Pursuit.
|
||||
- `pursuit_role`: customer | partner | vendor on Pipeline Pursuit.
|
||||
|
||||
## References
|
||||
|
||||
- Salesforce Opportunity object — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunity.htm
|
||||
- Shellblack, Salesforce data model overview — https://www.shellblack.com/whiteboard/overview-of-leads-account-and-contacts-the-salesforce-data-model/
|
||||
- Internal: `salesforce-crm-commercial-record.md`, `commercial-identity-synthesis.md`,
|
||||
`reputation-assurance-gradient.md`, `legal-person-agency-contract.md`
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
# DUNS and Commercial Credit Identity
|
||||
|
||||
## Source Type
|
||||
|
||||
Industry registry. Dun & Bradstreet Data Universal Numbering System (D-U-N-S).
|
||||
|
||||
## Domain
|
||||
|
||||
Commercial credit, vendor onboarding, procurement identity, and business verification.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
DUNS predates LEI as a global commercial identifier for **business entities** in
|
||||
trade and credit. It ties identity to **creditworthiness and payment behavior**
|
||||
(PAYDEX), illustrating how commercial activity creates durable, high-stakes identity
|
||||
interest among counterparties.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **DUNS number**: nine-digit proprietary identifier for a business location/entity.
|
||||
- **D&B database**: 300M+ business records; global trade and procurement usage.
|
||||
- **Business entity**: company or location receiving DUNS; not a natural person.
|
||||
- **PAYDEX score**: D&B payment performance score (credit behavior).
|
||||
- **Credit file**: aggregated commercial history attributed to DUNS.
|
||||
- **Government procurement**: historically required DUNS (US); migrated to SAM UEI.
|
||||
- **UEI (Unique Entity Identifier)**: US federal successor identifier in SAM.gov.
|
||||
- **ISO/IEC 6523 ICD 0060**: standard representation for DUNS in ISO identifiers.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| DUNS / D-U-N-S | D&B business identifier. |
|
||||
| Business entity | Company or site in D&B registry. |
|
||||
| PAYDEX | Payment performance score. |
|
||||
| Credit file | Commercial history record. |
|
||||
| UEI | US government unique entity ID (SAM.gov). |
|
||||
| Vendor onboarding | Procurement verification using DUNS/UEI. |
|
||||
| Headquarters vs. branch | Separate DUNS per distinct business location. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Commercial identity serves credit and procurement**, not authentication.
|
||||
- **Payment history feeds reputation** attributable to identifier.
|
||||
- **Multiple national ID schemes** (DUNS, UEI, LEI, VAT, company reg) coexist; linking
|
||||
requires Synonymity Assertion or registry crosswalk.
|
||||
- **Identifier assignment is vendor-operated** (D&B), not self-asserted.
|
||||
- **Commercial counterparties rely on DUNS** for risk decisions beyond bare legal existence.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- DUNS maps to **Proxy Commercial Identifier** (`scheme: 0060`,
|
||||
`authority_class: commercial_proxy`) on **Commercial Record** / **Organization**.
|
||||
- PAYDEX and credit file map to **Evidence Source** influencing **Trust Relationship**
|
||||
and counterparty risk.
|
||||
- UEI maps to **Identifier** (government authoritative) on Commercial Record.
|
||||
- Illustrates user thesis: once credit exposure exists, identity becomes **economically
|
||||
binding** and **reputationally persistent**.
|
||||
- Link to LEI via Synonymity Assertion when same legal entity holds both.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **DUNS** vs. **LEI**: credit/procurement vs. financial regulatory identifier.
|
||||
- **Business entity (D&B)** vs. **Tenant**: vendor record ≠ SaaS isolation.
|
||||
- **Customer (credit)** vs. **Customer (role)**: credit customer vs. relationship role.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| D&B / procurement concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| DUNS number | Proxy Commercial Identifier (ICD 0060) |
|
||||
| D&B business record | Commercial Record |
|
||||
| PAYDEX | Evidence Source (credit performance) |
|
||||
| UEI | Identifier (government registry) |
|
||||
| Vendor onboarding check | Trust Relationship + Evidence Source |
|
||||
| Parent/branch linkage | Organization structure Relationship |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- PAYDEX → Performance Evidence; `numeric_score` optional; tier enum primary.
|
||||
- LEI↔DUNS Synonymity default **medium**.
|
||||
|
||||
## References
|
||||
|
||||
- Dun & Bradstreet DUNS — https://www.dnb.com/duns-number.html
|
||||
- Wikipedia, Data Universal Numbering System — https://en.wikipedia.org/wiki/Data_Universal_Numbering_System
|
||||
- GSA Unique Entity Identifier — https://www.gsa.gov/about-us/organization/federal-acquisition-service/fas-initiatives/integrated-award-environment/iae-systems-information-kit/unique-entity-identifier-update
|
||||
|
|
@ -0,0 +1,102 @@
|
|||
# eIDAS and EUDI Wallet for Legal Persons
|
||||
|
||||
## Source Type
|
||||
|
||||
Regulatory framework and industry analysis. EU eIDAS Regulation, eIDAS 2.0 / EUDI
|
||||
Wallet, European Business Wallet (organizational wallet) initiatives.
|
||||
|
||||
## Domain
|
||||
|
||||
EU digital identity, qualified trust services, legal person credentials, and
|
||||
cross-border commercial trust.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
eIDAS bridges **legal identity** and **commercial trust** at EU scale: electronic
|
||||
signatures, seals, timestamps, and (via EUDI) wallets for natural and **legal
|
||||
persons** carrying verifiable credentials for B2B and B2G exchange.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **eIDAS**: EU regulation for electronic identification and trust services.
|
||||
- **eID (electronic identification)**: national schemes with mutual recognition.
|
||||
- **Qualified trust services**: legally recognized signatures, seals, timestamps, etc.
|
||||
- **Electronic seal**: legal-entity counterpart to personal e-signature.
|
||||
- **EUDI Wallet**: European Digital Identity Wallet for citizens (eIDAS 2.0).
|
||||
- **Organizational / legal person wallet**: extension for companies (EUBW discourse).
|
||||
- **Verifiable credential (EU context)**: credentials in wallet (licenses, compliance certs).
|
||||
- **Transient trust**: real-time verified trust between unknown parties via credentials.
|
||||
- **KYB/KYS**: Know Your Business / Supplier via registry-sourced credentials.
|
||||
- **Delegation of rights**: organizational members present credentials on behalf of legal person.
|
||||
- **Authorization chains**: parent-subsidiary credential issuance hierarchies.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| eIDAS | EU trust framework regulation. |
|
||||
| Qualified signature/seal | Highest assurance trust service. |
|
||||
| Legal person | Company or organization under law. |
|
||||
| EUDI Wallet | EU digital identity wallet. |
|
||||
| Organizational wallet | Wallet for legal person credentials. |
|
||||
| Electronic seal | Entity-level signing mechanism. |
|
||||
| Trust service provider | TSP issuing qualified services. |
|
||||
| Verifiable credential | Attested claim in wallet. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Natural person and legal person wallets differ materially** — org wallets need
|
||||
delegation, hierarchy, API integration, higher volume.
|
||||
- **Legal person acts through representatives** with scoped credentials (aligns with agency law).
|
||||
- **Qualified services carry legal equivalence** to paper in EU cross-border context.
|
||||
- **Registry-sourced credentials** (e.g., company register) anchor commercial identity to authority.
|
||||
- **Commercial binding increases** when seals/signatures and compliance credentials are used.
|
||||
- **Citizen wallet stack cannot be naively copied** for organizational use cases.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Legal person wallet maps to **Organization/Legal Entity** + **Commercial Record** +
|
||||
**Credential** (qualified seal) + **Claim** set.
|
||||
- Representative presenting org credential maps to **Representation Relationship**
|
||||
with scoped **Delegation**.
|
||||
- Registry-issued credential maps to **Claim** with government **Evidence Source**.
|
||||
- Transient trust maps to **Trust Relationship** established at transaction time with
|
||||
VC/qualified credential evidence.
|
||||
- Supports user thesis: commercial credentials make identity **relevant and durable**
|
||||
to counterparties across borders.
|
||||
- Pairwise/pseudonymous identity insufficient for qualified seal; commercial binding
|
||||
requires legal person resolution.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Legal person (civil law)** vs. **Legal Entity (canon)**: legal person includes natural persons.
|
||||
- **Digital identity (eIDAS)** vs. **Identity Record**: assured ID vs. directory record.
|
||||
- **Trust service** vs. **Trust Relationship**: regulatory service vs. canon relationship.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| eIDAS/EUDI concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Legal person | Organization / Legal Entity |
|
||||
| Organizational wallet | Commercial Record + Credential store (Scope) |
|
||||
| Electronic seal | Credential (entity signing) |
|
||||
| Qualified certificate | Credential + Assurance Level |
|
||||
| Member presenter | Natural Person + Representation |
|
||||
| Registry credential | Claim + authoritative Evidence Source |
|
||||
| KYB/KYS process | Commercial Relationship onboarding |
|
||||
| Authorization chain | Delegation + org hierarchy Relationships |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Qualified seal → **Credential** `credential_type: qualified_seal` via Representation.
|
||||
- Org wallet → **Scope** `wallet_scope`, linked to Commercial Record — not Tenant.
|
||||
|
||||
## References
|
||||
|
||||
- EU eIDAS Regulation — https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation
|
||||
- EU EUDI Regulation — https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation
|
||||
- Spherity, EUDI Wallet for legal persons — https://www.spherity.com/post/the-european-busienss-wallet-eubw-and-legal-person-identity-redefining-trust-in-the-eu-s-digital
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
# KYC AML and Commercial Identity Binding
|
||||
|
||||
## Source Type
|
||||
|
||||
Regulatory framework synthesis. USA PATRIOT Act CIP, FinCEN KYC/AML, FATF digital
|
||||
identity guidance.
|
||||
|
||||
## Domain
|
||||
|
||||
Financial regulation, customer identification, beneficial ownership, and ongoing
|
||||
commercial relationship monitoring.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
KYC/AML is where governments **mandate** commercial identity binding: institutions
|
||||
must verify who they transact with, retain evidence, and monitor behavior. This is
|
||||
the strongest practical force turning fluid identities into **regulated,
|
||||
high-stakes counterparty records**.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **KYC (Know Your Customer)**: policies ensuring institutions know customers and risks.
|
||||
- **AML (Anti-Money Laundering)**: broader program preventing illicit finance.
|
||||
- **CIP (Customer Identification Program)**: US mandate to verify identity before account opening.
|
||||
- **CDD (Customer Due Diligence)**: risk assessment of customer relationship.
|
||||
- **EDD (Enhanced Due Diligence)**: heightened review for high-risk customers.
|
||||
- **Beneficial owner (BO)**: natural persons owning/controlling legal entity customers
|
||||
(historically 25% threshold; may be lowered for high risk).
|
||||
- **Ongoing monitoring**: transaction surveillance after onboarding.
|
||||
- **Record retention**: CIP records kept years after relationship ends.
|
||||
- **Sanctions / PEP screening**: compare identities against government lists.
|
||||
- **Digital identity (FATF)**: guidance on digital ID assurance for KYC.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| KYC | Know-your-customer compliance program. |
|
||||
| CIP | Customer identification at onboarding. |
|
||||
| Beneficial owner | Natural person behind legal entity customer. |
|
||||
| PEP | Politically exposed person (elevated risk). |
|
||||
| Due diligence | Risk-based identity and activity review. |
|
||||
| Ongoing monitoring | Continued scrutiny of customer activity. |
|
||||
| Risk profile | Customer risk classification. |
|
||||
| FinCEN | US Financial Crimes Enforcement Network. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Commercial relationship triggers identity rigor** proportional to risk.
|
||||
- **Legal entity customers require beneficial owner identification** — natural
|
||||
persons bound to organization customers.
|
||||
- **Identity verification is not one-time**; monitoring continues across lifecycle.
|
||||
- **Evidence must be retained** even after account closure.
|
||||
- **False identity has regulatory and criminal consequences** — binding is external,
|
||||
not user preference.
|
||||
- **Friction is accepted** where commercial stakes require it.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- KYC onboarding creates **Commercial Record** + **Commercial Commitment** (regulated
|
||||
relationship) bound to **Natural Person** and/or **Organization/Legal Entity**.
|
||||
- **Beneficial owner** maps to **Natural Person** linked via **Beneficial
|
||||
Ownership Relationship** to Organization/Legal Entity customer (see
|
||||
`beneficial-ownership-kyc-boi.md`).
|
||||
- CIP evidence maps to **Evidence Source** with **Assurance Level**.
|
||||
- Ongoing monitoring produces **Evidence Source** events affecting **Lifecycle State**
|
||||
and **Trust Relationship**.
|
||||
- Supports fluid-to-bound transition: anonymous lead → verified customer with retained proof.
|
||||
- **Account** (bank/login) is insufficient alone; KYC binds the **counterparty**.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Customer (KYC)** vs. **Customer (Stripe)** vs. **Customer (role)**: regulated
|
||||
counterparty vs. billing object vs. commercial role.
|
||||
- **CIP customer** vs. **Account holder**: verified party vs. access credential.
|
||||
- **Digital identity** vs. **login identity**: assurance-ranked ID vs. session user.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| KYC/AML concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Verified customer | Commercial Record + Actor binding |
|
||||
| CIP evidence | Evidence Source |
|
||||
| Beneficial owner | Natural Person + Beneficial Ownership Relationship |
|
||||
| Risk profile | Assurance Level + metadata on Commercial Relationship |
|
||||
| EDD review | Evidence Source (enhanced) |
|
||||
| Sanctions hit | Lifecycle State / Trust Relationship revocation |
|
||||
| Transaction alert | Evidence Source event |
|
||||
| Record retention | Lifecycle/archival policy on Commercial Record |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Beneficial Owner → **Beneficial Ownership Relationship**; `control_basis` enum;
|
||||
CDD vs. BOI filing layered separately.
|
||||
|
||||
## References
|
||||
|
||||
- Thomson Reuters, Customer Identification Program overview — https://legal.thomsonreuters.com/blog/overview-customer-identification-program-cip/
|
||||
- Okta KYC definition — https://www.okta.com/identity-101/kyc/
|
||||
- FinCEN, USA PATRIOT Act Section 326 — https://www.fincen.gov/resources/statutes-regulations/usa-patriot-act
|
||||
- FATF Guidance on Digital Identity — https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-on-Digital-Identity.html
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
# Legal Person, Agency, and Contract Binding
|
||||
|
||||
## Source Type
|
||||
|
||||
Legal doctrine synthesis. Common-law agency principles, contract privity, and
|
||||
juridical person concepts used in commercial law.
|
||||
|
||||
## Domain
|
||||
|
||||
Commercial law foundations for representation, liability, and binding promises
|
||||
between parties.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Commercial software models "accounts" and "organizations," but courts and
|
||||
regulators reason about **principals, agents, legal persons, and contractual
|
||||
obligations**. Agency law explains how organizations act through people and why
|
||||
commercial identity must bind **liability**, not just login state.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Legal person**: entity recognized by law as holder of rights and duties;
|
||||
includes natural persons and juridical persons (corporations, LLCs, etc.).
|
||||
- **Juridical person**: organization recognized as legal person distinct from
|
||||
members (corporation, association).
|
||||
- **Principal**: party on whose behalf an agent acts.
|
||||
- **Agent**: party authorized to act for principal and bind principal within scope.
|
||||
- **Fiduciary duty**: agent's duty of loyalty and care to principal.
|
||||
- **Actual authority**: express or implied permission granted to agent.
|
||||
- **Apparent authority**: third party reasonably believes agent has authority
|
||||
based on principal's conduct.
|
||||
- **Agency by contract**: principal-agent relationship created by agreement
|
||||
(employment, power of attorney, brokerage).
|
||||
- **Contract**: agreement creating enforceable obligations; requires parties with
|
||||
capacity.
|
||||
- **Privity**: doctrine limiting contract rights/obligations to parties to the
|
||||
contract (with modern statutory exceptions).
|
||||
- **Representation**: agent acts **for** principal; principal may be bound by
|
||||
authorized acts.
|
||||
- **Termination**: agency ends by agreement, operation of law (death, bankruptcy),
|
||||
or breach.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Principal | Party represented by agent. |
|
||||
| Agent | Party acting on principal's behalf. |
|
||||
| Legal person | Rights-bearing entity under law. |
|
||||
| Juridical person | Non-human legal person (company). |
|
||||
| Fiduciary | Trust-based duty relationship. |
|
||||
| Power of attorney | Written agency authorization. |
|
||||
| Binding | Creating legal obligation on a party. |
|
||||
| Capacity | Legal ability to enter contracts. |
|
||||
| Apparent authority | Authority as seen by third parties. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Organizations act only through agents** (officers, employees, representatives).
|
||||
- **Commercial binding requires identifiable parties** with legal capacity.
|
||||
- **Representation is contractual or statutory**, not merely technical (API token).
|
||||
- **Principal liability** may attach to unauthorized acts if apparent authority exists.
|
||||
- **Agency terminates**; commercial systems must model lifecycle and revocation.
|
||||
- **Natural person ≠ company** even when sole proprietor; legal structure matters
|
||||
for liability and contract.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- **Organization** collective actor maps to juridical person when legally recognized.
|
||||
- **Natural Person** maps to natural-person legal person.
|
||||
- **Representation Relationship** in canon aligns with agency (acts for).
|
||||
- **Delegation Relationship** is narrower grant of authority; agency may be broader.
|
||||
- **Commercial Commitment** (contracts, PO acceptance) binds **Legal Entity** or
|
||||
**Organization** actors through **Representation** chains.
|
||||
- Login **Account** does not create agency; employment or explicit authorization does.
|
||||
- **Apparent authority** explains why enterprises must govern service accounts and
|
||||
admin roles carefully (S05, S10, S11).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Agent (legal)** vs. **Artificial Agent (canon)**: lawyer's agent ≠ AI agent;
|
||||
overlap when AI acts under delegated authority.
|
||||
- **Principal (legal)** vs. **Authorization Principal**: legal principal vs. Cedar principal.
|
||||
- **Legal person** vs. **Legal Entity** in canon: legal person includes natural persons.
|
||||
- **Account holder** vs. **contracting party**: bank account ≠ signatory authority.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Legal concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Natural person (legal) | Natural Person |
|
||||
| Juridical person | Organization / Legal Entity |
|
||||
| Principal | Organization or Natural Person (represented party) |
|
||||
| Agent (human) | Natural Person + Representation Relationship |
|
||||
| Agent (org acting) | Organization + Representation Relationship |
|
||||
| Power of attorney | Delegation Relationship + Credential |
|
||||
| Contract | Commercial Commitment (contract) |
|
||||
| Apparent authority | Trust Relationship risk + Administration governance |
|
||||
| Agency termination | Lifecycle State on Representation/Delegation |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should canon add **Legal Person** as umbrella for Natural Person + juridical
|
||||
Organization/Legal Entity?
|
||||
- How should apparent authority risks be represented for service accounts?
|
||||
|
||||
## References
|
||||
|
||||
- Stimmel Law, Agency – The Basic Law — https://www.stimmel-law.com/en/articles/agency-basic-law
|
||||
- Contract privity doctrine (common law overview)
|
||||
- Harvard Law School Forum, FinCEN beneficial ownership and corporate persons
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
# LEI and GLEIF Legal Entity Identifier
|
||||
|
||||
## Source Type
|
||||
|
||||
Standard and registry. ISO 17442 Legal Entity Identifier; GLEIF global LEI index.
|
||||
|
||||
## Domain
|
||||
|
||||
Regulated financial markets, legal entity identification, and ownership transparency.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
LEI is the post-2008-crisis global standard for identifying **legal entities** in
|
||||
financial transactions. It encodes **who** and **who owns whom**, making it a
|
||||
canonical example of commercially binding identity with regulatory renewal
|
||||
requirements.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **LEI**: 20-character ISO 17442 identifier for a legal entity.
|
||||
- **Legal entity (LEI scope)**: organization participating in financial transactions;
|
||||
individuals cannot obtain LEI.
|
||||
- **GLEIF**: Global Legal Entity Identifier Foundation; oversees LOUs and data quality.
|
||||
- **LOU (Local Operating Unit)**: issuer/registrar for LEIs in a jurisdiction.
|
||||
- **Level 1 data**: business card data — legal name, address, jurisdiction.
|
||||
- **Level 2 data**: ownership — direct and ultimate parent relationships.
|
||||
- **Renewal**: LEI valid one year; annual renewal required for continued use.
|
||||
- **Regulatory mandate**: 45+ jurisdictions require LEI for certain financial reporting.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| LEI | Legal Entity Identifier code. |
|
||||
| Legal entity | Juridical person in financial markets. |
|
||||
| Level 1 | Entity reference data. |
|
||||
| Level 2 | Parent/ownership reference data. |
|
||||
| GLEIF | Global LEI system operator. |
|
||||
| LOU | Local issuing organization. |
|
||||
| Renewal | Annual reaffirmation of LEI validity. |
|
||||
| Regulator reporting | MiFIR, derivatives reporting, etc. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **LEI identifies legal entities only**, not natural persons or login accounts.
|
||||
- **Ownership is first-class** in LEI Level 2 (parent chains).
|
||||
- **Identity persistence is maintained by renewal**, not immutability of business facts.
|
||||
- **Public global directory** enables counterparty verification.
|
||||
- **LEI does not prove good behavior**; it proves identifiable legal presence.
|
||||
- **One LEI per legal entity** for global financial identification.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- LEI maps to **Registry Identifier** (`scheme: 0199`, `authority_class:
|
||||
regulatory_global`, `renewal_required: true`) for **Legal Entity** /
|
||||
**Organization** actors.
|
||||
- Level 2 parent data maps to **Ownership** or structural Organization relationships.
|
||||
- LEI record maps to **Commercial Record** or authoritative **Identity Record**
|
||||
with registry **Evidence Source**.
|
||||
- Renewal maps to **Lifecycle State** on Identifier/Commercial Record.
|
||||
- LEI exemplifies **commercial binding**: regulatory participation requires stable,
|
||||
renewed legal identity.
|
||||
- Distinct from DUNS (credit/commerce) and from OIDC sub (authentication).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Legal entity (LEI)** vs. **Legal Entity (canon)**: aligned when jurisdictionally recognized.
|
||||
- **Legal entity** vs. **Organization**: not every organization has LEI; LEI subset is regulated finance participants.
|
||||
- **LEI** vs. **company registration number**: national registry ID vs. global LEI.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| LEI concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| LEI code | Registry Identifier (regulatory_global, ICD 0199) |
|
||||
| Legal entity | Legal Entity / Organization |
|
||||
| Level 1 data | Commercial Record / registry Profile |
|
||||
| Level 2 parent | Ownership Relationship |
|
||||
| GLEIF registry | Evidence Source (authoritative) |
|
||||
| Annual renewal | Lifecycle State maintenance |
|
||||
| LOU issuance | Issuer Scope + Trust Relationship |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Registry Identifier subtype; LEI↔company reg **strong**; LEI↔DUNS **medium**.
|
||||
|
||||
## References
|
||||
|
||||
- ISO 17442 — https://www.iso.org/standard/78829.html
|
||||
- GLEIF, Introducing the LEI — https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei
|
||||
- Wikipedia, Legal Entity Identifier — https://en.wikipedia.org/wiki/Legal_Entity_Identifier
|
||||
|
|
@ -0,0 +1,171 @@
|
|||
# Payment Credential Boundary — PCI and Commercial Commitment
|
||||
|
||||
## Source Type
|
||||
|
||||
Standards and product synthesis. PCI DSS tokenization guidance, Stripe Payment
|
||||
Methods / SetupIntents, and identity-canon Credential vs. Commercial Commitment
|
||||
separation.
|
||||
|
||||
## Domain
|
||||
|
||||
Payment instruments on billing customers — what belongs in canonical identity
|
||||
model vs. PCI-scoped downstream vaults, and how charge authorization relates to
|
||||
Commercial Commitment.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Stripe **Customer** objects carry **payment methods**, and canon **Credential**
|
||||
already covers secrets and proof material. Collapsing them causes two failures:
|
||||
|
||||
1. **PCI scope bleed** — modeling PAN, CVV, or vault secrets in identity canon
|
||||
implies they belong in general identity stores.
|
||||
2. **Semantic collision** — login passkeys and payment mandates both "authorize
|
||||
something" but authorize **authentication** vs. **commercial debit**.
|
||||
|
||||
Payment methods are commercially binding (tier 3 assurance) when they encode
|
||||
**mandate to charge** — but the binding artifact is the **authorization/commitment**,
|
||||
not the token reference.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### PCI DSS data categories
|
||||
|
||||
- **CHD (cardholder data)**: PAN, cardholder name, expiration, service code.
|
||||
- **Sensitive authentication data (SAD)**: CVV/CVC, full track data, PIN — never
|
||||
stored after authorization per PCI.
|
||||
- **Token**: surrogate value replacing PAN; if properly implemented, token in
|
||||
merchant environment is **out of PCI CHD scope** (PCI tokenization guidelines).
|
||||
- **Scope principle**: systems that store, process, or transmit CHD fall under PCI;
|
||||
token references (`pm_xxx`) in app DBs are not CHD when only the token exists.
|
||||
|
||||
### Stripe payment object model
|
||||
|
||||
- **PaymentMethod** (`pm_xxx`): reusable payment details attached to Customer;
|
||||
contains type-specific non-transaction data (last4, fingerprint, billing details).
|
||||
- **SetupIntent**: establishes future off-session payment — creates mandate to charge.
|
||||
- **PaymentIntent**: one-time or reusable charge attempt.
|
||||
- **Customer**: billing container; payment methods attach here, not to login User.
|
||||
- **Mandates** (SEPA, Bacs, etc.): explicit customer authorization for debits.
|
||||
|
||||
### Authentication vs. payment authorization
|
||||
|
||||
| Dimension | Authentication credential | Payment authorization |
|
||||
| --- | --- | --- |
|
||||
| Proves | Identity / session control | Right to debit funds |
|
||||
| Scope | IdP, app login, federation | Payment network / acquirer |
|
||||
| Regulation | NIST 800-63, OIDC | PCI DSS, PSD2 SCA, Nacha |
|
||||
| Canon home | Credential | Payment Mandate (Commercial Commitment) |
|
||||
| Secret handling | Passkey, password hash | CHD in vault only; token ref in app |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Canon is implementation-neutral** but must not encourage CHD in identity layers.
|
||||
- **Payment provider owns payment truth**; app holds references and commitment state.
|
||||
- **Reusable payment method** implies **Commercial Commitment** (payment mandate)
|
||||
when customer consented to future charges (SetupIntent succeeded, card on file).
|
||||
- **Single-use payment methods** may exist only for one PaymentIntent — weaker
|
||||
commitment, often no reusable mandate.
|
||||
- **Subscription** is separate Commercial Commitment (recurring service obligation);
|
||||
payment mandate is **enabling** commitment for collection.
|
||||
- **Webhook events** (`setup_intent.succeeded`, `payment_method.attached`) are
|
||||
**Evidence Source** for mandate lifecycle.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
### Resolved: do not map payment methods to Credential
|
||||
|
||||
**Credential** in canon covers authentication, federation, and entitlement proof
|
||||
(passkey, password, certificate, VC). **Payment methods are not Credentials.**
|
||||
|
||||
Raw CHD and SAD are **out of canon entirely** — downstream PCI vault / payment
|
||||
provider only.
|
||||
|
||||
### Payment Instrument Reference
|
||||
|
||||
Add **Payment Instrument Reference** — Reference layer value scoped to a payment
|
||||
provider (Stripe `pm_xxx`, fingerprint, display last4, mandate ID). Links to
|
||||
**Commercial Record**, not to login **Account**.
|
||||
|
||||
Properties:
|
||||
|
||||
- `provider_scope` — Stripe account, Adyen merchant, etc.
|
||||
- `instrument_type` — card, sepa_debit, us_bank_account, etc.
|
||||
- `reference_id` — provider token (not PAN).
|
||||
- `reusable` — boolean.
|
||||
- `lifecycle_state` — attached, detached, expired, revoked.
|
||||
|
||||
This is a **Scoped Identifier** specialization, not a Credential.
|
||||
|
||||
### Payment Mandate as Commercial Commitment
|
||||
|
||||
When a customer authorizes future charges (SetupIntent success, SEPA mandate
|
||||
signed, card saved with explicit consent), model **Payment Mandate** as a
|
||||
**Commercial Commitment** subtype:
|
||||
|
||||
- `commitment_type: payment_mandate`
|
||||
- `lifecycle_state`: proposed → active → revoked → expired
|
||||
- Parties: customer actor (via Commercial Record) and vendor/payment facilitator
|
||||
- **Evidence Source**: SetupIntent result, mandate document, SCA proof metadata
|
||||
- `assurance_tier: committed` on Counterparty Assurance Gradient
|
||||
|
||||
**Subscription** remains `commitment_type: subscription` — distinct but often
|
||||
co-created at checkout.
|
||||
|
||||
### Commercial Record role
|
||||
|
||||
**Commercial Record** (Stripe Customer) **references** payment instrument refs
|
||||
and **hosts** links to Payment Mandate commitments. Do not embed CHD attributes
|
||||
in Commercial Record canon fields — only provider references and lifecycle flags
|
||||
(`delinquent`, default payment method ref).
|
||||
|
||||
### Layer diagram
|
||||
|
||||
```text
|
||||
Login Account → Credential (passkey, password)
|
||||
Commercial Record → Payment Instrument Reference (pm_xxx)
|
||||
Commercial Commitment → Payment Mandate + Subscription
|
||||
PCI Vault / Stripe → CHD (downstream only, not canon)
|
||||
Evidence Source → webhooks, mandate PDF, SCA audit
|
||||
```
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Payment method (Stripe)** vs. **Credential (canon)**: both grant "permission"
|
||||
but different permission domains.
|
||||
- **Payment credential (informal)** vs. **Credential (glossary)**: avoid informal
|
||||
phrase in canonical definitions; use Payment Instrument Reference + Payment Mandate.
|
||||
- **Saved card** vs. **payment mandate**: saved token may exist before explicit
|
||||
off-session mandate — lifecycle `proposed` until SetupIntent completes.
|
||||
- **customer_account (Stripe)** vs. **Account (login)**: reinforces commercial split.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Source artifact | Canonical mapping |
|
||||
| --- | --- |
|
||||
| PAN / CVV | Out of canon (PCI downstream) |
|
||||
| PaymentMethod `pm_xxx` | Payment Instrument Reference |
|
||||
| SetupIntent succeeded | Payment Mandate Commercial Commitment + Evidence |
|
||||
| Subscription object | Commercial Commitment (subscription) |
|
||||
| Default payment method | Reference on Commercial Record |
|
||||
| Payment webhook | Evidence Source |
|
||||
| 3DS / SCA step-up | Evidence Source on mandate (not Credential) |
|
||||
| Passkey for login | Credential (unchanged) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Network tokens → Payment Instrument Reference `instrument_type: network_token`.
|
||||
- Shared methods → multi Commercial Record link within payment org Scope.
|
||||
- Wallet balance → Commercial Record `provider_ledger_balance` attribute.
|
||||
|
||||
## References
|
||||
|
||||
- PCI SSC, Tokenization Guidelines — https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
|
||||
- Stripe Payment Methods — https://docs.stripe.com/payments/payment-methods
|
||||
- Stripe Customer object — https://docs.stripe.com/api/customers/object
|
||||
- Stripe SetupIntent — https://docs.stripe.com/api/setup_intents
|
||||
- Internal: `../commercial-subscription/stripe-customer-billing.md`,
|
||||
`reputation-assurance-gradient.md`, `commercial-identity-synthesis.md`
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
# Registry Identifier Subtypes — ISO 6523, ALEI, LEI, DUNS, UEI
|
||||
|
||||
## Source Type
|
||||
|
||||
Standards and registry synthesis. ISO/IEC 6523, ISO 17442 (LEI), ISO 8000-116
|
||||
(ALEI), GLEIF, D&B DUNS, SAM.gov UEI, EITI/Open Ownership identifier guidance.
|
||||
|
||||
## Domain
|
||||
|
||||
Authoritative and proxy organization identifiers used in commerce, procurement,
|
||||
financial markets, beneficial ownership transparency, and master data management.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Legal entities accumulate **multiple identifiers** from different registries —
|
||||
company registration numbers, LEI, DUNS, UEI, VAT — each with different
|
||||
**issuing authority**, **renewal rules**, and **trust basis**. Collapsing them
|
||||
into generic Identifier loses lifecycle, authority, and cross-registry linking
|
||||
semantics needed for commercial binding and BO transparency.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### ISO/IEC 6523 structure
|
||||
|
||||
ISO/IEC 6523 defines organization identification as:
|
||||
|
||||
- **International Code Designator (ICD)**: up to 4 digits identifying the issuing
|
||||
scheme authority (registered with ISO/IEC 6523-2).
|
||||
- **Organization identifier**: up to 35 characters within that scheme.
|
||||
- **Optional organization part identifier (OPI)**: sub-entity within organization.
|
||||
|
||||
Combined form enables global interchange (PEPPOL, EDIFACT, Schema.org `iso6523Code`).
|
||||
|
||||
Example ICD allocations relevant to commercial identity:
|
||||
|
||||
| ICD | Scheme | Authority type |
|
||||
| --- | --- | --- |
|
||||
| 0060 | D-U-N-S (DUNS) | Commercial proxy (D&B) |
|
||||
| 0088 | EAN Location Code (GLN) | GS1 location |
|
||||
| 0151 | Singapore UEN | Government registry |
|
||||
| 0199 | Legal Entity Identifier (LEI) | GLEIF / ISO 17442 |
|
||||
| 0209 | GS1 identification keys | GS1 |
|
||||
|
||||
(Full list maintained at iso6523.info and PEPPOL ICD codelists.)
|
||||
|
||||
### Authoritative vs. proxy identifiers (ISO 8000-116 / ALEI)
|
||||
|
||||
**Authoritative Legal Entity Identifier (ALEI)**: identifier assigned by a
|
||||
**government jurisdiction** authorized by statute to create legal entities and
|
||||
maintain authoritative registries. Format: jurisdiction prefix + register +
|
||||
local number (e.g., `US-DE.BER:3031657`).
|
||||
|
||||
**Proxy identifiers**: issued by institutions that do **not** create legal
|
||||
entities — DUNS (D&B), NCAGE (CAGE), and arguably LEI (GLEIF issues to existing
|
||||
legal entities but does not incorporate them).
|
||||
|
||||
**LEI nuance**: ISO 17442 / GLEIF is regulatory-mandated for financial
|
||||
transactions but is a **cross-jurisdiction overlay** on existing legal entities,
|
||||
not the incorporating register. Canon treats LEI as **Registry Identifier**
|
||||
with `authority_class: regulatory_global`.
|
||||
|
||||
### Renewal and lifecycle
|
||||
|
||||
| Identifier | Renewal / validity | Lifecycle driver |
|
||||
| --- | --- | --- |
|
||||
| LEI | Annual renewal required | GLEIF / LOU reaffirmation |
|
||||
| DUNS | No annual renewal; record updates | D&B data maintenance |
|
||||
| UEI | Persistent in SAM.gov | Entity registration status |
|
||||
| Company reg number | Jurisdiction-specific | Annual report / dissolution |
|
||||
| ALEI / IBRN | Tied to registry filing status | Government register |
|
||||
| VAT / tax ID | Jurisdiction-specific | Tax authority |
|
||||
|
||||
Renewal semantics belong on **Registry Identifier** lifecycle state, not on the
|
||||
Organization actor.
|
||||
|
||||
### Cross-registry linking
|
||||
|
||||
Same legal entity may hold LEI + DUNS + UEI + national company number.
|
||||
**Synonymity Assertion** (`same_as`, strong or authoritative) links Registry
|
||||
Identifiers when evidenced by registry crosswalk, LOU verification, or operator
|
||||
confirmation. Do not silently merge Commercial Records.
|
||||
|
||||
EITI and Open Ownership recommend **reliable organizational identifiers**
|
||||
(especially authoritative registration numbers) in beneficial ownership datasets
|
||||
to disambiguate corporate vehicles.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Registry Identifier | Identifier issued under a registered scheme with known authority. |
|
||||
| ICD | ISO 6523 International Code Designator for a scheme. |
|
||||
| ALEI | Authoritative Legal Entity Identifier (government register). |
|
||||
| Proxy identifier | Commercial or overlay ID not from incorporating authority. |
|
||||
| LOU | Local Operating Unit issuing LEIs. |
|
||||
| Renewal | Periodic reaffirmation of identifier validity (esp. LEI). |
|
||||
| Crosswalk | Mapping between identifiers for same entity. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Registry Identifier is an Identifier subtype**, not a Record layer entity.
|
||||
The registry **record** (GLEIF entry, D&B profile, SAM registration) maps to
|
||||
Commercial Record or Identity Record.
|
||||
- **Authority class** matters more than brand name (LEI vs. DUNS vs. company reg).
|
||||
- **Renewal is optional metadata** — present for LEI, absent for DUNS.
|
||||
- **ICD code** is the preferred `scheme` key for ISO 6523-aligned identifiers.
|
||||
- **Proxy Commercial Identifier** is a Registry Identifier with
|
||||
`authority_class: commercial_proxy` for DUNS-like schemes.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
### Resolved: Registry Identifier subtype
|
||||
|
||||
Add **Registry Identifier** as an Identifier specialization in the Reference layer.
|
||||
|
||||
**Recommended fields:**
|
||||
|
||||
- `scheme`: ICD code or well-known scheme URI (e.g., `0199` for LEI, `0060` for DUNS)
|
||||
- `authority`: issuing body (GLEIF LOU, D&B, SAM.gov, Companies House, etc.)
|
||||
- `authority_class`: `government_registry` | `regulatory_global` | `commercial_proxy` | `tax`
|
||||
- `jurisdiction`: ISO country/subdivision when applicable
|
||||
- `value`: the identifier string
|
||||
- `renewal_required`: boolean
|
||||
- `lifecycle_state`: active, lapsed, revoked, expired, superseded
|
||||
- `last_renewed_at` / `expires_at`: when renewal applies
|
||||
- `evidence_source`: registry lookup, LOU issuance, API verification
|
||||
|
||||
### Proxy Commercial Identifier
|
||||
|
||||
**Proxy Commercial Identifier** is a Registry Identifier with
|
||||
`authority_class: commercial_proxy` — vendor-operated business keys (DUNS) used
|
||||
for credit and procurement but not legal incorporation. Keeps DUNS mapping
|
||||
explicit without conflating with ALEI or company registration numbers.
|
||||
|
||||
### Mapping table
|
||||
|
||||
| Source identifier | Canonical mapping |
|
||||
| --- | --- |
|
||||
| LEI code | Registry Identifier (`scheme: 0199`, `authority_class: regulatory_global`) |
|
||||
| DUNS | Proxy Commercial Identifier (`scheme: 0060`) |
|
||||
| UEI (SAM.gov) | Registry Identifier (`authority_class: government_registry`, US federal) |
|
||||
| Company registration number | Registry Identifier (`authority_class: government_registry`, jurisdiction-local) |
|
||||
| ALEI / IBRN | Registry Identifier (`authority_class: government_registry`, ISO 8000-116 format) |
|
||||
| VAT / EIN / tax ID | Registry Identifier (`authority_class: tax`) |
|
||||
| GLEIF registry entry | Commercial Record or Identity Record + Evidence Source |
|
||||
| D&B business profile | Commercial Record + PAYDEX as Evidence Source |
|
||||
| Same entity, multiple IDs | Synonymity Assertion between Registry Identifiers |
|
||||
|
||||
### Relationship to Beneficial Ownership
|
||||
|
||||
BO datasets should reference **Organization/Legal Entity** via Registry Identifier
|
||||
(authoritative company reg preferred; LEI as strong cross-border key). Beneficial
|
||||
Ownership Relationships attach to the entity actor, not to the identifier — but
|
||||
identifier quality affects Evidence strength on BO filings.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Legal entity (LEI)** vs. **Organization (canon)**: LEI subset ⊂ organizations
|
||||
with financial/regulatory participation.
|
||||
- **DUNS business entity** vs. **Legal Entity**: D&B may assign DUNS to locations
|
||||
or branches not identical to juridical persons.
|
||||
- **Identifier** vs. **Commercial Record**: Stripe `customer_id` is scoped
|
||||
system Identifier; LEI is registry Identifier — different authority classes.
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- `authority_class` includes `industry_association` (NCAGE, GS1 GLN).
|
||||
- LEI↔DUNS medium; LEI↔company reg/ALEI/UEI strong; crosswalk table in settlement note.
|
||||
- OPI → Organization Unit / branch Registry Identifier with `organization_part_id`.
|
||||
|
||||
## References
|
||||
|
||||
- ISO/IEC 6523 — https://www.iso.org/standard/25773.html
|
||||
- ISO 17442 (LEI) — https://www.iso.org/standard/78829.html
|
||||
- ISO 8000-116 (ALEI) — https://www.iso.org/standard/75117.html
|
||||
- GLEIF, Introducing the LEI — https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei
|
||||
- iso6523.info ICD list — http://iso6523.info/icd_list.pdf
|
||||
- PEPPOL ICD codelist — https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/
|
||||
- GSA, Unique Entity Identifier — https://www.gsa.gov/about-us/organization/federal-acquisition-service/fas-initiatives/integrated-award-environment/iae-systems-information-kit/unique-entity-identifier-update
|
||||
- EITI, Organisational identifiers guidance — https://eiti.org/sites/default/files/2023-11/Technical%20Guidance%20%E2%80%93%20Organisational%20identifiers%20guidance%20%20WEB.pdf
|
||||
- Open Ownership, reliable identifiers — https://www.openownership.org/en/publications/using-reliable-identifiers-for-corporate-vehicles-in-beneficial-ownership-data/
|
||||
- Internal: `lei-gleif-legal-entity-identifier.md`, `duns-commercial-credit-identity.md`
|
||||
|
|
@ -0,0 +1,242 @@
|
|||
# Reputation and Counterparty Assurance Gradient
|
||||
|
||||
## Source Type
|
||||
|
||||
Cross-domain synthesis. Online reputation systems, credit reporting, contract
|
||||
bonding theory, payment dispute automation, and alternative dispute resolution
|
||||
(ADR) / litigation practice.
|
||||
|
||||
## Domain
|
||||
|
||||
How counterparties move from weak social proof to enforceable commercial reliance
|
||||
— and how identity-canon should model that journey without collapsing tiers.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
"Reputation" is overloaded: a five-star Yelp review, a D&B PAYDEX score, a
|
||||
performance bond, and a court judgment all influence whether a counterparty is
|
||||
trusted — but they differ radically in **evidence quality**, **gaming risk**,
|
||||
**attribution strength**, and **enforceability**. Software often stores them in
|
||||
one "rating" field. Canon must preserve the gradient so downstream systems do not
|
||||
treat gamable opinion as legal fact or ignore contractual stakes already modeled
|
||||
elsewhere.
|
||||
|
||||
## The Assurance Gradient (Journey)
|
||||
|
||||
Counterparty assurance typically escalates through four tiers. Higher tiers do
|
||||
not replace lower ones; they **constrain** how much weight lower tiers may carry
|
||||
for a given decision.
|
||||
|
||||
```text
|
||||
Tier 1 OPINION Star ratings, reviews, karma, badges
|
||||
(weak/gamable) Low cost to fake; Sybil-prone; scope-local
|
||||
|
||||
Tier 2 OBSERVED PAYDEX, on-time %, chargeback rate, audit logs,
|
||||
(evidence) verified transaction history, KYC outcome
|
||||
|
||||
Tier 3 COMMITTED Contract, bond, escrow, guarantee, insurance,
|
||||
(financial) SLA penalties, payment mandate, subscription lock-in
|
||||
|
||||
Tier 4 ADJUDICATED Arbitration award, court judgment, regulator action,
|
||||
(legal) enforced settlement, lien, bankruptcy filing
|
||||
```
|
||||
|
||||
### Tier 1 — Opinion signals (weak, gamable)
|
||||
|
||||
**Examples:** Amazon/Yelp star ratings, eBay feedback scores, Stack Overflow
|
||||
reputation, Uber driver rating, Trustpilot reviews, Airbnb host score.
|
||||
|
||||
**Properties:**
|
||||
|
||||
- **Low cost of manipulation** — fake reviews, review bombing, sock puppets,
|
||||
Sybil accounts (Jøsang reputation attack taxonomy).
|
||||
- **Scope-local** — reputation on eBay does not transfer to Etsy without
|
||||
explicit portability (reputation bank problem).
|
||||
- **Voluntary participation bias** — satisfied and angry customers over-represent;
|
||||
silent majority absent.
|
||||
- **Identity attribution weak** — reviewer may be unverified persona; linkage to
|
||||
Natural Person or Organization often absent.
|
||||
- **Economic effect real but bounded** — eBay seller ratings correlate with price
|
||||
premium, but platforms add escrow and buyer protection because ratings alone
|
||||
insufficient.
|
||||
|
||||
**Canon mapping:** **Reputation Signal** — an **Evidence Source** with
|
||||
`assurance_tier: opinion`. Attach to **Profile**, **Commercial Record**, or
|
||||
**Actor** with explicit **Scope** (platform namespace). Default synonymity and
|
||||
trust strength: **weak**. Do not promote to Commercial Commitment.
|
||||
|
||||
**Gaming defenses (downstream):** verified-purchase flags, rate limits, graph
|
||||
analysis, moderation — model as separate Evidence Source metadata, not as tier
|
||||
upgrade by itself.
|
||||
|
||||
### Tier 2 — Observed metrics (evidence-based)
|
||||
|
||||
**Examples:** D&B PAYDEX, business credit scores, platform completion rate,
|
||||
on-time delivery statistics, SLA attainment dashboards, chargeback ratio,
|
||||
sanctions-screen clear result, KYC pass, LEI renewal status.
|
||||
|
||||
**Properties:**
|
||||
|
||||
- **Grounded in observable events** — payment dates, shipment scans, registry
|
||||
lookups, transaction logs.
|
||||
- **Stronger attribution** — usually tied to **Registry Identifier**, **Commercial
|
||||
Record**, or verified **Account** history.
|
||||
- **Third-party or platform issuer** — D&B, credit bureaus, marketplace operator,
|
||||
KYC vendor acts as **Evidence Source** issuer.
|
||||
- **Still revisable** — metrics update; disputes may correct; not legally
|
||||
conclusive.
|
||||
- **Monitoring lifecycle** — ongoing CDD and PAYDEX refresh mirror **Lifecycle
|
||||
State** on evidence, not one-time truth.
|
||||
|
||||
**Canon mapping:** **Performance Evidence** — **Evidence Source** with
|
||||
`assurance_tier: observed`. Link to **Commercial Record** / **Organization** via
|
||||
**Registry Identifier** or **Commercial Relationship**. Supports **Trust
|
||||
Relationship** with medium-to-strong confidence when issuer is authoritative.
|
||||
|
||||
### Tier 3 — Committed stakes (contractual / financial)
|
||||
|
||||
**Examples:** Performance bonds, surety bonds, letters of credit, escrow deposits,
|
||||
service-level agreements with liquidated damages, signed MSAs, active subscription
|
||||
with payment mandate, insurance certificates, qualified electronic seals on
|
||||
contracts (eIDAS).
|
||||
|
||||
**Properties:**
|
||||
|
||||
- **Costly to breach** — Klein-Leffler bonding: quality assurance through
|
||||
market forces when reputation alone insufficient; hostages and penalties.
|
||||
- **Explicit parties** — **Legal Person** / **Organization** actors bound via
|
||||
**Commercial Commitment** and **Representation** chains.
|
||||
- **Automated enforcement partial** — smart-contract escrow, Stripe retention,
|
||||
auto-renewal billing, SLA breach triggers — automation executes **committed**
|
||||
rules without yet reaching court.
|
||||
- **Identity stakes rise** — counterparties need stable **Registry Identifier**,
|
||||
**Commercial Record**, and often **Beneficial Ownership Relationship** because
|
||||
liability is real.
|
||||
|
||||
**Canon mapping:** **Commercial Commitment** (contract, subscription, payment
|
||||
mandate, bond) with **Evidence Source** attesting execution. Assurance tier:
|
||||
`committed`. **Trust Relationship** here should cite the commitment ID, not
|
||||
opinion aggregates.
|
||||
|
||||
**Distinction:** A five-star rating is not a bond. A bond is not a review.
|
||||
Model separately; combine only in downstream risk engines with explicit weighting.
|
||||
|
||||
### Tier 4 — Adjudicated outcomes (automated dispute → legal resolution)
|
||||
|
||||
**Escalation path:**
|
||||
|
||||
1. **Platform automation** — chargeback dispute rules, marketplace arbitration
|
||||
(eBay Money Back Guarantee), payment processor outcome.
|
||||
2. **Contractual ADR** — mandatory arbitration clause (AAA, ICC, JAMS); neutral
|
||||
award binding per contract and statute.
|
||||
3. **Courts** — breach of contract, fraud, collections, judgment lien, bankruptcy.
|
||||
|
||||
**Properties:**
|
||||
|
||||
- **Third-party or state authority** — arbitrator, court, regulator issues outcome.
|
||||
- **High attribution** — parties identified in proceeding; ties to **Legal Entity**.
|
||||
- **Enforceable beyond platform** — judgments attach to legal persons; credit
|
||||
reporting may follow.
|
||||
- **Lifecycle durable** — satisfied, appealed, vacated, enforced — explicit
|
||||
**Lifecycle State**.
|
||||
|
||||
**Canon mapping:** **Adjudication Outcome** — **Evidence Source** with
|
||||
`assurance_tier: adjudicated`. May trigger **Commercial Commitment** state change
|
||||
(breached, fulfilled), **Trust Relationship** revocation, or **Lifecycle State**
|
||||
on **Commercial Record**. Do not model as "bad review."
|
||||
|
||||
## Cross-Tier Dynamics
|
||||
|
||||
| Transition | What changes | Canon event |
|
||||
| --- | --- | --- |
|
||||
| Opinion → Observed | Platform verifies purchase; metric computed from logs | New Performance Evidence; optional Synonymity link reviewer Account to transaction |
|
||||
| Observed → Committed | Parties sign contract / post bond | Commercial Commitment created; Trust Relationship cites commitment |
|
||||
| Committed → Adjudicated | Breach → ADR/court | Adjudication Outcome Evidence; commitment lifecycle update |
|
||||
| Adjudicated → Observed | Judgment paid; credit file updated | Performance Evidence refresh (credit bureau) |
|
||||
|
||||
**De-escalation:** Adjudicated fraud finding may **invalidate** opinion signals
|
||||
(moderation) but should not silently delete Evidence — supersede with lifecycle.
|
||||
|
||||
**Identity coupling:** Higher tiers require stronger **actor attribution**.
|
||||
Opinion may attach to **Persona**; adjudication attaches to **Legal Entity** +
|
||||
**Registry Identifier**.
|
||||
|
||||
## Relationship to Existing Canon
|
||||
|
||||
| Concept | Role in assurance gradient |
|
||||
| --- | --- |
|
||||
| Evidence Source | Carrier for all tiers; use `assurance_tier` metadata |
|
||||
| Trust Relationship | Counterparty reliance; must cite tier basis |
|
||||
| Commercial Commitment | Tier 3 anchor |
|
||||
| Commercial Relationship | Scope for which assurance applies |
|
||||
| Registry Identifier | Attribution for tiers 2–4 |
|
||||
| Beneficial Ownership Relationship | Liability chain for tier 3–4 entity customers |
|
||||
| Assurance Level (NIST) | Orthogonal — identity/auth proofing, not commercial performance |
|
||||
| Synonymity Assertion | Link platform persona to legal entity when tiers mix |
|
||||
|
||||
## Reputation Systems Literature (Practical)
|
||||
|
||||
Jøsang survey and Resnick criteria for effective reputation systems:
|
||||
|
||||
1. Long-lived entities with predictable future interaction.
|
||||
2. Capture and distribute feedback from prior interactions.
|
||||
3. Use feedback to guide trust.
|
||||
|
||||
**Implication for canon:** Tier 1 only works when **Scope** is stable and
|
||||
interaction history is modeled as Evidence with temporal bounds. Reputation
|
||||
**capital** (economic value of good history) is aggregate **Performance Evidence**
|
||||
over time — not a separate ontological root.
|
||||
|
||||
**Attacks:** self-promotion, Sybil, slandering, whitewashing — map to
|
||||
`integrity_risk` metadata on opinion-tier Evidence; downstream concern, but canon
|
||||
should flag tier-1 default weakness.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Source artifact | Canonical mapping |
|
||||
| --- | --- |
|
||||
| Star rating / review | Reputation Signal (Evidence Source, tier: opinion) |
|
||||
| Verified purchase review | Reputation Signal + Performance Evidence link |
|
||||
| PAYDEX / credit score | Performance Evidence (tier: observed) |
|
||||
| SLA dashboard | Performance Evidence on Commercial Relationship |
|
||||
| Signed MSA / bond | Commercial Commitment + Evidence Source (tier: committed) |
|
||||
| Escrow release | Commercial Commitment lifecycle event |
|
||||
| Arbitration award | Adjudication Outcome (tier: adjudicated) |
|
||||
| Court judgment | Adjudication Outcome + may affect Legal Entity lifecycle |
|
||||
| "Trust score" UI | Downstream projection — not canonical root |
|
||||
|
||||
## Resolved Canon Question
|
||||
|
||||
**Do not add Reputation as a first-class entity.**
|
||||
|
||||
Instead:
|
||||
|
||||
1. **Counterparty Assurance Gradient** — modeling pattern (four tiers).
|
||||
2. **Evidence Source** specializations by tier: **Reputation Signal** (opinion),
|
||||
**Performance Evidence** (observed), **Adjudication Outcome** (adjudicated);
|
||||
tier 3 uses existing **Commercial Commitment**.
|
||||
3. **Trust Relationship** carries `assurance_basis` referencing tier + evidence IDs.
|
||||
|
||||
**Convenience term only:** "Reputation" in prose — resolve to specific tier and
|
||||
Evidence Source before modeling.
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- `assurance_tier` primary; optional `numeric_score` + `score_scale` downstream.
|
||||
- Segregated escrow → Commercial Commitment `commitment_type: escrow`.
|
||||
- Reputation portability → Synonymity `linked_to`, weak default.
|
||||
- Oracle release → observed; ADR/court → adjudicated.
|
||||
|
||||
## References
|
||||
|
||||
- Josang, "A survey of trust and reputation systems for online service provision" — https://doi.org/10.1016/j.dss.2005.05.019
|
||||
- Hoffman et al., "A survey of attack and defense techniques for reputation systems" — ACM Computing Surveys
|
||||
- Klein and Leffler (1981), quality assurance through bonding / price premiums
|
||||
- RFC 7070, An Architecture for Reputation Reporting — https://www.rfc-editor.org/rfc/rfc7070
|
||||
- Wikipedia, Reputation system — https://en.wikipedia.org/wiki/Reputation_system
|
||||
- Internal: `commercial-trust-binding-theory.md`, `duns-commercial-credit-identity.md`,
|
||||
`legal-person-agency-contract.md`, `kyc-aml-commercial-identity-binding.md`
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
# Salesforce CRM Commercial Record Model
|
||||
|
||||
## Source Type
|
||||
|
||||
Product data model reference. Salesforce Account, Contact, Lead, and B2B relationship patterns.
|
||||
|
||||
## Domain
|
||||
|
||||
CRM, sales operations, commercial customer records, and B2B account hierarchies.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Salesforce **Account** is the archetypal **commercial record** in enterprise software:
|
||||
a company or household you sell to, distinct from **Contact** (people) and **User**
|
||||
(login). It operationalizes commercial identity separate from authentication.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Account**: company, household, or partner organization in CRM; core commercial record.
|
||||
- **Contact**: person associated with accounts; human relationship endpoint.
|
||||
- **Lead**: unqualified prospect before conversion to Account/Contact.
|
||||
- **Opportunity**: potential revenue deal tied to Account.
|
||||
- **Account hierarchy**: parent-child account relationships (global HQ → subsidiaries).
|
||||
- **Account-Contact Relationship**: many-to-many person-to-account roles (ACR).
|
||||
- **Person Account**: B2C pattern merging person and account for individual consumers.
|
||||
- **Partner / Customer / Competitor**: account type labels for commercial role hints.
|
||||
- **User (Salesforce)**: internal login for CRM operators, not customer identity.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Account | CRM commercial entity record. |
|
||||
| Contact | Person linked to accounts. |
|
||||
| Lead | Pre-qualification prospect. |
|
||||
| ACR | Account-Contact Relationship with roles. |
|
||||
| Account hierarchy | Parent/child commercial structure. |
|
||||
| Person Account | B2C combined person+account pattern. |
|
||||
| Customer account (informal) | Often means CRM Account object. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Commercial party (Account) ≠ login User**; sales data outlives individual logins.
|
||||
- **Multiple contacts** represent people acting for commercial account (agency in practice).
|
||||
- **Hierarchy models corporate structure** for roll-up revenue and ownership context.
|
||||
- **Lead → Account conversion** is fluid-to-bound transition in commercial funnel.
|
||||
- **Person Account** blurs person/account boundary for B2C — convenient but risky for canon purity.
|
||||
- **Account type** hints customer/vendor/partner but is not authorization.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Salesforce **Account** maps to **Commercial Record** linked to **Organization**
|
||||
(B2B) or **Natural Person** (person account).
|
||||
- **Contact** maps to **Natural Person** + **Affiliation** or **Representation** to Organization.
|
||||
- **ACR** maps to **Membership** or **Representation** with role metadata.
|
||||
- **Account hierarchy** maps to Organization parent/child structural relationships.
|
||||
- **Lead** maps to provisional Identity/Commercial prospect with weak evidence until conversion.
|
||||
- **User** maps to internal **Account** (employee), not customer.
|
||||
- Validates Commercial Record concept from Customer Account resolution work.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Account (CRM)** vs. **Account (login)**: Salesforce naming collision.
|
||||
- **Customer account** language vs. **Account object**: product uses Account for all.
|
||||
- **Person Account** vs. **P2 separation**: B2C shortcut vs. canon layers.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Salesforce concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Account (B2B) | Commercial Record + Organization |
|
||||
| Contact | Natural Person |
|
||||
| Account-Contact Relationship | Affiliation / Representation |
|
||||
| Account hierarchy | Organization structure Relationship |
|
||||
| Lead | Prospective Commercial Record (weak) |
|
||||
| Opportunity | Pipeline Pursuit (promotes to Commercial Commitment on binding trigger) |
|
||||
| User | Account (internal operator) |
|
||||
| Person Account | Commercial Record + Natural Person (combined projection) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Opportunity → **Pipeline Pursuit**; binding triggers and renewal/amendment rules.
|
||||
- Person Account → split Natural Person + Commercial Record; adapter `projection_mode`
|
||||
only on export.
|
||||
|
||||
## References
|
||||
|
||||
- Salesforce Account object reference — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_account.htm
|
||||
- Shellblack, Leads vs Account and Contacts — https://www.shellblack.com/whiteboard/overview-of-leads-account-and-contacts-the-salesforce-data-model/
|
||||
- SalesforceBen, Account best practices — https://www.salesforceben.com/best-practices-salesforce-account-object/
|
||||
|
|
@ -0,0 +1,102 @@
|
|||
# B2B SaaS Subscriber and Organization Tenancy
|
||||
|
||||
## Source Type
|
||||
|
||||
Product documentation and industry practice synthesis. Auth0 Organizations and
|
||||
B2B SaaS multi-tenancy guidance; Stytch B2B Auth School org-tenancy model.
|
||||
|
||||
## Domain
|
||||
|
||||
B2B SaaS identity, organization tenancy, subscriber administration, and
|
||||
vendor/customer delineation in IAM products.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
IAM vendors explicitly separate the subscribing party (customer/subscriber) from
|
||||
login accounts and from billing records. This source clarifies why "customer
|
||||
account" overloads identity, commercial, and access semantics.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Subscriber**: Auth0-preferred term for the immediate B2B customer — the
|
||||
party that holds a provisioned tenant and subscription.
|
||||
- **Vendor**: provider of the B2B SaaS application (platform operator).
|
||||
- **Organization tenancy**: architecture where organizations are first-class
|
||||
entities; members are scoped to their organization.
|
||||
- **Member**: end user with membership in an organization (Stytch); distinct
|
||||
from platform-wide user identity.
|
||||
- **Tenant / tenancy holder**: operational partition occupied by a subscriber.
|
||||
- **Org discovery**: determining which organization a user authenticates into.
|
||||
- **Membership control**: granting/revoking which users may access a subscriber's
|
||||
tenant.
|
||||
- **Identity isolation**: per-subscriber credential and IdP configuration vs.
|
||||
platform-wide user population.
|
||||
- **B2B2C / B2B2B variants**: additional "customer" and "consumer" layers below
|
||||
the subscribing organization.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Subscriber | B2B customer occupying a tenant; Auth0 avoids "customer" label. |
|
||||
| Vendor | SaaS platform provider. |
|
||||
| Organization | First-class customer entity; "the organization is the customer" (Stytch). |
|
||||
| Member | Employee or invited user within an organization. |
|
||||
| Tenant | Isolation boundary for subscriber data, branding, and config. |
|
||||
| Customer (informal) | Often used interchangeably with subscriber or organization. |
|
||||
| User | Login identity; may belong to multiple organizations. |
|
||||
| Consumer | End user in B2B2C scenarios below the subscriber org. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **The subscribing company is modeled as an organization**, not as a user
|
||||
account or billing record.
|
||||
- **One human can be a member of multiple subscriber organizations** (contractors,
|
||||
agencies).
|
||||
- **Platform stores users globally**; membership scopes them to subscriber orgs.
|
||||
- **Billing is subscription-based** but handled outside core IAM in most products.
|
||||
- **Vendor administration** may cross tenant boundaries with subscriber consent;
|
||||
subscriber administration does not.
|
||||
- **No IAM product defines "Customer Account"** as a separate entity type.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- **Subscriber** maps to **Organization** actor in **Customer Relationship**
|
||||
with vendor + **Tenant** Scope — not a canonical noun.
|
||||
- **Member** maps to **Account** + **Membership Relationship** to Organization.
|
||||
- **Vendor** maps to **Vendor Relationship** role on vendor Organization actor.
|
||||
- Supports S04, S05 without Customer Account concept.
|
||||
- Individual (B2C-style) subscriber maps to **Natural Person** + **Tenant**
|
||||
Scope, still without Customer Account.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Customer vs. Subscriber vs. Organization**: three labels for overlapping B2B
|
||||
party; IAM prefers organization or subscriber.
|
||||
- **Customer vs. Consumer**: B2B2C uses both; subscriber org vs. end consumer.
|
||||
- **Tenant vs. Organization**: Stytch equates customer to organization; tenant
|
||||
is the isolation fabric they occupy.
|
||||
- **Account**: must not be used for subscriber org or billing party.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| B2B SaaS IAM concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Subscriber | Organization + Customer Relationship role |
|
||||
| Organization (tenant holder) | Organization + Tenant Scope |
|
||||
| Member | Account + Membership Relationship |
|
||||
| Vendor (platform) | Organization + Vendor Relationship role |
|
||||
| Tenant | Tenant (Scope) |
|
||||
| User (login) | Account |
|
||||
| Consumer (B2B2C) | Natural Person or Account (context-dependent) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- None blocking Customer Account resolution. Commercial billing layer documented
|
||||
separately in `stripe-customer-billing.md`.
|
||||
|
||||
## References
|
||||
|
||||
- Auth0: Demystifying Multi-Tenancy in B2B SaaS — https://auth0.com/blog/demystifying-multi-tenancy-in-b2b-saas/
|
||||
- Auth0 Organizations — https://auth0.com/docs/manage-users/organizations
|
||||
- Stytch: Organization tenancy — https://stytch.com/blog/organization-tenancy/
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
# Stripe Customer and Subscription Billing
|
||||
|
||||
## Source Type
|
||||
|
||||
Product API documentation and SaaS architecture practice. Stripe Customer object
|
||||
and B2B subscription billing integration patterns.
|
||||
|
||||
## Domain
|
||||
|
||||
Commercial billing, payment methods, subscriptions, and tenant-to-billing linkage
|
||||
in multi-tenant SaaS.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Stripe's Customer object is the most widely deployed example of a **billing
|
||||
customer** that is explicitly not a login account. It demonstrates why
|
||||
"customer account" must be split into commercial records vs. identity records.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Customer (Stripe)**: billing entity with email, name, payment methods,
|
||||
subscriptions, balance, and invoice settings.
|
||||
- **Subscription**: recurring billing agreement tied to a Customer.
|
||||
- **Payment method**: card or bank source attached to Customer for charges.
|
||||
- **Metadata**: key-value pairs linking Stripe Customer to app tenant ID.
|
||||
- **Delinquent**: billing health flag on Customer from invoice state.
|
||||
- **Business name / individual name**: Customer may represent company or person.
|
||||
- **customer_account (Stripe API)**: newer field referencing an Account object
|
||||
representing a customer — explicit split from legacy Customer.
|
||||
- **Webhook-driven sync**: Stripe owns payment state; app database owns business
|
||||
state; webhooks bridge them.
|
||||
- **Tenant mapping**: standard pattern stores `stripe_customer_id` on tenant record.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Customer | Stripe billing object; not authentication identity. |
|
||||
| Subscription | Recurring charge agreement. |
|
||||
| Invoice | Bill document; drives delinquent state. |
|
||||
| Payment method | Stored payment instrument. |
|
||||
| Balance | Credit or amount owed on Customer. |
|
||||
| Metadata | App-defined correlation (e.g., tenant_id). |
|
||||
| customer_account | Stripe Account representing customer (newer API). |
|
||||
| Tenant (app) | Application isolation unit linked via metadata. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Billing state lives in payment provider**; app caches plan/feature access.
|
||||
- **One Stripe Customer per tenant** is the common B2B pattern (not per login user).
|
||||
- **B2B Customer** often has `business_name`; B2C may use `individual_name`.
|
||||
- **Customer email** is billing contact, not necessarily login email.
|
||||
- **Commercial identity can exist without Organization** (sole proprietor, individual
|
||||
plan).
|
||||
- **CRM "Account"** (Salesforce-style) follows similar commercial-record pattern.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Stripe **Customer** maps to **Commercial Record** in Record layer — not Account,
|
||||
not Customer Account, not Organization.
|
||||
- Link Commercial Record to **Tenant** Scope and/or **Organization** / **Natural
|
||||
Person** actor via **Commercial Relationship** or Identifier binding.
|
||||
- Stripe **customer_account** field reinforces separate commercial vs. identity
|
||||
account split at API level.
|
||||
- **Subscription state** is Lifecycle State on Commercial Record (downstream).
|
||||
- Supports S04 when billing is modeled alongside vendor/customer orgs.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Customer (Stripe) vs. Customer (relationship role)**: same word, different
|
||||
layers — billing object vs. vendor/customer commercial role.
|
||||
- **Customer vs. Account**: Stripe uses "customer" and emerging "customer_account"
|
||||
deliberately separate from login accounts.
|
||||
- **Customer vs. Tenant**: integration stores stripe ID on tenant; not same entity.
|
||||
- **CRM Account vs. Account (login)**: Salesforce Account = commercial record.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Stripe / billing concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Customer object | Commercial Record |
|
||||
| Subscription | Commercial Record lifecycle / entitlement metadata |
|
||||
| Payment method | Payment Instrument Reference (not Credential) |
|
||||
| SetupIntent / mandate | Payment Mandate (Commercial Commitment) |
|
||||
| Metadata.tenant_id | Identifier binding to Tenant Scope |
|
||||
| business_name | Commercial Record attribute |
|
||||
| individual_name | Commercial Record attribute (person-backed) |
|
||||
| customer_account (API) | Commercial Record variant / provider projection |
|
||||
| Delinquent / balance | Lifecycle State on Commercial Record |
|
||||
| Webhook event | Evidence Source for billing state change |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Does sole-proprietor billing (person-backed Commercial Record without
|
||||
Organization) need a distinct pattern in scenario tests?
|
||||
|
||||
## Resolved (see payment-credential-pci-boundary.md)
|
||||
|
||||
- Payment methods → **Payment Instrument Reference**; mandates → **Payment Mandate**.
|
||||
CHD out of canon; not **Credential**.
|
||||
|
||||
## References
|
||||
|
||||
- Stripe Customer object — https://docs.stripe.com/api/customers/object
|
||||
- Stripe Billing — https://docs.stripe.com/billing
|
||||
- Stripe org customer sharing — https://docs.stripe.com/get-started/account/orgs/sharing/customers-payment-methods
|
||||
|
|
@ -0,0 +1,138 @@
|
|||
# Keycloak Organizations
|
||||
|
||||
## Source Type
|
||||
|
||||
Product documentation and implementation reference for Keycloak 26+ organization
|
||||
features and core realm/user/group/role model.
|
||||
|
||||
## Domain
|
||||
|
||||
Multi-tenant IAM, B2B/B2B2C organization management, and OIDC/SAML federation.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Keycloak organizations, realms, groups, roles, clients, and B2B/B2B2C
|
||||
organization management terminology.
|
||||
|
||||
Keycloak is a widely deployed open-source IAM product. Its newer Organizations
|
||||
feature adds first-class B2B org semantics on top of the classic realm model,
|
||||
making it a live vocabulary source for tenant/org/customer overlap.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Realm**: top-level administrative and security namespace; owns users,
|
||||
clients, identity providers, roles, groups, and authentication flows.
|
||||
- **User**: realm-local account with credentials, attributes, group/role
|
||||
mappings, and federation links.
|
||||
- **Organization** (26+): B2B entity with members, domains, identity providers,
|
||||
and invited users; supports multi-org membership per user.
|
||||
- **Organization member**: user linked to an organization with membership
|
||||
metadata (roles within the org context).
|
||||
- **Group**: realm-level hierarchical collection for user grouping and role
|
||||
mapping.
|
||||
- **Role**: realm role or client role; assigned directly, via group, or via
|
||||
composite roles.
|
||||
- **Client**: OIDC/SAML application registered in a realm; may represent a
|
||||
tenant application or service.
|
||||
- **Identity Provider (IdP)**: federated authentication source brokering
|
||||
external identities into realm users.
|
||||
- **User federation**: LDAP/AD/Kerberos bridge supplying or syncing users.
|
||||
- **Attribute**: key-value metadata on users, clients, or organizations.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Realm | Hard identity/admin boundary; separate user namespace per realm. |
|
||||
| User | Realm-local login account with credentials and profile attributes. |
|
||||
| Organization | B2B org actor within a realm; has domains, members, and IdP config. |
|
||||
| Member | User belonging to an organization. |
|
||||
| Group | Realm hierarchy node; users inherit roles through group membership. |
|
||||
| Role | Named permission bundle at realm or client scope. |
|
||||
| Client | Application or service consuming tokens from the realm. |
|
||||
| Identity Provider | External auth source; may assert identities into realm users. |
|
||||
| Domain (org) | Email domain associated with an organization for discovery/broker routing. |
|
||||
| Federated identity | Link between realm user and external IdP identity. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Realm is the primary isolation boundary** for users, credentials, and
|
||||
admin policy.
|
||||
- **User means account** in product vocabulary; one realm user per login
|
||||
identity within that realm.
|
||||
- **Organization is a B2B overlay** within a realm, not a replacement for
|
||||
realm or tenant infrastructure boundaries.
|
||||
- **Groups carry authorization semantics** through role mapping, not just
|
||||
social grouping.
|
||||
- **Roles are permission bundles**, assignable directly or transitively via
|
||||
groups and composites.
|
||||
- **Federation links** connect external IdP identities to local users via
|
||||
brokered login.
|
||||
- **Multi-org membership** is supported: one user can belong to multiple
|
||||
organizations in the same realm.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Keycloak **Realm** maps to **Realm** (Scope specialization) with hard
|
||||
namespace boundaries.
|
||||
- Keycloak **User** maps to **Account** in a realm Scope; not **Natural
|
||||
Person**.
|
||||
- Keycloak **Organization** maps to **Organization** collective actor with
|
||||
**Membership Relationship** to member Accounts.
|
||||
- **Group** maps to **Group** with Membership edges; role inheritance is
|
||||
authorization projection.
|
||||
- **Role** maps to **Role** (authorization projection), not membership.
|
||||
- **Client** maps to application **Scope** or registered resource in
|
||||
authorization domain.
|
||||
- **Federated identity** link maps to **Synonymity Assertion** or
|
||||
**Identifier Binding** between external IdP identifier and local Account.
|
||||
- **Domain** on organization is an **Identifier** used for discovery routing.
|
||||
- Supports scenarios S03 (enterprise orgs), S04 (vendor/customer B2B), S05
|
||||
(delegated admins via roles/groups).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Realm vs. Tenant**: Keycloak realm is both issuer namespace and admin
|
||||
partition; products often call this "tenant."
|
||||
- **User vs. Member**: org member is still a realm User; membership is a
|
||||
relationship overlay.
|
||||
- **Organization vs. Group**: both exist; org has B2B semantics (domains, IdP),
|
||||
group is generic hierarchy.
|
||||
- **Role vs. Membership**: group membership implies role inheritance;
|
||||
conflates relationship types.
|
||||
- **Client vs. Tenant**: clients are applications, not customer isolation
|
||||
boundaries.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Keycloak concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Realm | Realm (Scope) |
|
||||
| User | Account |
|
||||
| Organization | Organization |
|
||||
| Organization membership | Membership Relationship |
|
||||
| Group | Group |
|
||||
| Group membership | Membership Relationship |
|
||||
| Role (realm/client) | Role (authorization projection) |
|
||||
| Client | Application Scope / registered client |
|
||||
| Identity Provider | Trust Relationship + external issuer Scope |
|
||||
| Federated identity link | Synonymity Assertion / Identifier Binding |
|
||||
| User attribute | Profile attribute or Claim |
|
||||
| Organization domain | Identifier (email domain) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should Keycloak Realm remain a **Realm** specialization or absorb **Tenant**
|
||||
semantics when used as SaaS isolation?
|
||||
- How should multi-org user membership be modeled when the same Account holds
|
||||
Membership edges to multiple Organizations?
|
||||
- Does Keycloak Organization domain verification warrant a **Claim** or
|
||||
**Evidence Source** in canon?
|
||||
- Should composite roles be modeled as Role aggregation or as derived
|
||||
authorization projection only?
|
||||
|
||||
## References
|
||||
|
||||
- Keycloak Organizations documentation — https://www.keycloak.org/docs/latest/server_admin/#_organizations
|
||||
- Keycloak Server Administration Guide — https://www.keycloak.org/docs/latest/server_admin/
|
||||
- Keycloak Realm concepts — https://www.keycloak.org/docs/latest/server_admin/#_create-realm
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
# ZITADEL Organizations and Projects
|
||||
|
||||
## Source Type
|
||||
|
||||
Product documentation and implementation reference for ZITADEL's multi-instance
|
||||
organization, project, and grant model.
|
||||
|
||||
## Domain
|
||||
|
||||
Cloud-native IAM, multi-tenancy, B2B SaaS identity, and fine-grained
|
||||
authorization grants.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
ZITADEL organizations, projects, roles, grants, and multi-tenancy concepts.
|
||||
|
||||
ZITADEL is designed for multi-tenant SaaS from the ground up. Its org →
|
||||
project → grant hierarchy provides a live product vocabulary for separating
|
||||
customer organizations, application projects, and role grants.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Instance**: ZITADEL deployment; top-level operational boundary.
|
||||
- **Organization**: primary tenant/customer entity; owns users, projects,
|
||||
policies, and branding.
|
||||
- **Project**: application or service scope within an organization; owns roles,
|
||||
applications, and grants.
|
||||
- **Application**: OIDC/SAML/API client registered under a project.
|
||||
- **User**: human identity within an organization with authentication methods
|
||||
and profile.
|
||||
- **Machine user / service user**: non-human identity for API access.
|
||||
- **Grant**: assignment of project roles to a user or organization (including
|
||||
cross-org grants for B2B).
|
||||
- **Role**: project-scoped permission label granted via grants.
|
||||
- **Organization domain**: verified domain for org discovery and policy.
|
||||
- **User grant vs. org grant**: direct user-to-project role vs. org-wide
|
||||
project access.
|
||||
- **Actions / Flows**: customizable authentication and provisioning pipelines.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Organization | Customer or business entity; primary multi-tenant partition. |
|
||||
| Project | Application or product scope within an org. |
|
||||
| Grant | Role assignment linking user or org to a project. |
|
||||
| Role | Named capability within a project. |
|
||||
| User | Human identity record within an organization. |
|
||||
| Machine user | Service identity for programmatic access. |
|
||||
| Application | Registered client (OIDC/SAML/API) under a project. |
|
||||
| Instance | ZITADEL deployment boundary. |
|
||||
| Org grant | Organization-level access to a project's roles. |
|
||||
| Domain verification | Proof that an org controls an email domain. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Organization is the primary customer/tenant boundary** for users and
|
||||
admin delegation.
|
||||
- **Project separates applications** within an org; roles are project-scoped.
|
||||
- **Grants are the authorization assignment mechanism**, not group membership.
|
||||
- **Users belong to exactly one organization** (per current product model);
|
||||
cross-org access is via grants to shared projects.
|
||||
- **Machine users are first-class** identities distinct from human users.
|
||||
- **B2B** is modeled by granting one organization's project roles to another
|
||||
organization's users or to the org itself.
|
||||
- **Branding and login policy** are org-scoped configuration.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- ZITADEL **Organization** maps to **Organization** actor and/or **Tenant**
|
||||
Scope depending on deployment (often both: org as actor, org as tenant
|
||||
boundary).
|
||||
- **Project** maps to **Application Scope** or child **Scope** under tenant.
|
||||
- **User** maps to **Account** (human); **Machine user** maps to **Service
|
||||
Account**.
|
||||
- **Grant** maps to **Role** assignment via **Delegation** or Membership-like
|
||||
relationship with authorization implication.
|
||||
- **Role** maps to **Role** (authorization projection).
|
||||
- **Application** maps to registered client within Application Scope.
|
||||
- **Domain verification** maps to **Claim** or **Evidence Source** for org
|
||||
domain ownership.
|
||||
- Product vocabulary strongly supports S04 (vendor/customer) and S05
|
||||
(delegated admin via grants).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Organization vs. Tenant**: ZITADEL uses "organization" for what SaaS
|
||||
products often call "tenant."
|
||||
- **Grant vs. Membership**: grants assign roles; no generic group concept at
|
||||
project level.
|
||||
- **User vs. Account**: product says "user" but means org-local identity
|
||||
record with credentials.
|
||||
- **Project vs. Application**: project is container; application is client;
|
||||
both compete with "tenant" in other products.
|
||||
- **Role vs. Grant**: role is definition; grant is assignment; IAM products
|
||||
often collapse these.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| ZITADEL concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Instance | Scope (deployment boundary) |
|
||||
| Organization | Organization + Tenant Scope |
|
||||
| Project | Application Scope |
|
||||
| User | Account |
|
||||
| Machine user | Service Account |
|
||||
| Application | Registered client / Application Scope |
|
||||
| Role | Role (authorization projection) |
|
||||
| Grant | Role assignment relationship (Delegation-like) |
|
||||
| Org grant | Membership or Delegation at org level |
|
||||
| Domain verification | Claim + Evidence Source |
|
||||
| User profile | Profile |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- When ZITADEL Organization serves as both commercial actor and isolation
|
||||
boundary, should canon use one node with dual typing or separate Organization
|
||||
+ Tenant linked by Ownership?
|
||||
- How should cross-org project grants map: **Delegation**, **Trust**, or a
|
||||
vendor-specific **Grant Relationship**?
|
||||
- Does single-org-per-user constraint affect canon modeling of multi-org
|
||||
persons (S02)?
|
||||
- Should Machine user always map to Service Account, or sometimes to
|
||||
Artificial Agent?
|
||||
|
||||
## References
|
||||
|
||||
- ZITADEL documentation — https://zitadel.com/docs
|
||||
- ZITADEL Organizations — https://zitadel.com/docs/guides/manage/console/organizations
|
||||
- ZITADEL Projects and roles — https://zitadel.com/docs/guides/manage/console/projects
|
||||
|
|
@ -0,0 +1,194 @@
|
|||
# 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.
|
||||
|
|
@ -0,0 +1,230 @@
|
|||
# Terminology Conflict Map
|
||||
|
||||
Status: draft. Revised after IDENTITY-WP-0003 corpus backfill. Each conflict
|
||||
includes source-backed examples from populated research notes.
|
||||
|
||||
## Conflict: User
|
||||
|
||||
Problem: `user` can mean a person, account, login credential holder,
|
||||
application profile, authorization subject, or product-facing actor.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- SCIM User = provisionable Identity Record (`scim-rfc7643-rfc7644.md`)
|
||||
- Keycloak/ZITADEL User = Account with credentials (`keycloak-organizations.md`,
|
||||
`zitadel-organizations-projects.md`)
|
||||
- OpenFGA `user:` tuple prefix = Authorization Principal id (`openfga-modeling.md`)
|
||||
- OIDC End-User = implied Natural Person, not modeled (`oidc-core-subject-identifiers.md`)
|
||||
|
||||
Canonical stance: do not use `user` as a root concept.
|
||||
|
||||
Current mapping rule:
|
||||
|
||||
- Provisioning record (SCIM/LDAP) → Identity Record
|
||||
- Login-enabled product record → Account
|
||||
- Public/local display → Profile
|
||||
- Access evaluation → Principal or Authenticated Subject
|
||||
- Human being → Natural Person
|
||||
|
||||
## Conflict: Identity
|
||||
|
||||
Problem: `identity` can mean selfhood, a directory record, an issuer-bound
|
||||
subject, a set of claims, a DID, a credential, a profile, or an account.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Kratos Identity = traits + credentials (`ory-kratos-keto.md`)
|
||||
- OIDC developers conflate `sub` with "identity" (`oidc-core-subject-identifiers.md`)
|
||||
- DID is identifier, not identity record (`did-core.md`)
|
||||
- VC credentialSubject = claims about subject (`vc-data-model-2.md`)
|
||||
|
||||
Canonical stance: avoid bare `identity`. Prefer Identity Record, Identifier,
|
||||
Claim, Credential, Profile, Persona, or Synonymity Assertion.
|
||||
|
||||
## Conflict: Account
|
||||
|
||||
Problem: account can mean login account, customer billing account, social
|
||||
media handle, service account, or FOAF online presence.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- FOAF OnlineAccount is service presence, explicitly not Person (`foaf-agent-person-group-onlineaccount.md`)
|
||||
- LDAP posixAccount is attribute bundle on person entry (`ldap-rfc4519-inetorgperson-rfc2798.md`)
|
||||
- ActivityPub `acct:` URI suggests account but actor is richer (`activitypub-actors-followers.md`)
|
||||
- ZITADEL machine user = Service Account (`zitadel-organizations-projects.md`)
|
||||
|
||||
Canonical stance: Account is operational access record in a scope. Billing
|
||||
records map to Commercial Record; commercial parties use Customer/Vendor roles
|
||||
and Commercial Relationship.
|
||||
|
||||
## Conflict: Subject, Principal, Actor
|
||||
|
||||
Problem: protocols, authorization engines, and social models overload these terms.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- OIDC Subject = issuer-scoped identifier (`oidc-core-subject-identifiers.md`)
|
||||
- SAML Principal = authenticated subject in assertion (`saml-nameid-federation.md`)
|
||||
- Cedar Principal = typed entity in authorization request (`cedar-principal-action-resource-context.md`)
|
||||
- Zanzibar/OpenFGA Subject = opaque authz participant (`zanzibar-rebac.md`)
|
||||
- ActivityPub Actor = server-hosted social entity (`activitypub-actors-followers.md`)
|
||||
- FOAF Agent = actionable entity, includes Person (`foaf-agent-person-group-onlineaccount.md`)
|
||||
- GDPR Data Subject = natural person (`gdpr-pseudonymization.md`)
|
||||
|
||||
Canonical stance:
|
||||
|
||||
- Actor = conceptual participant
|
||||
- Authenticated Subject = issuer/protocol view
|
||||
- Authorization Principal = decision-engine projection
|
||||
|
||||
## Conflict: Tenant, Realm, Organization, Customer
|
||||
|
||||
Problem: multi-tenant products collapse isolation boundaries and commercial actors.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Keycloak Realm = hard namespace; Organization = B2B overlay (`keycloak-organizations.md`)
|
||||
- ZITADEL Organization = customer boundary + org actor (`zitadel-organizations-projects.md`)
|
||||
- SCIM has no tenant; org is string attribute (`scim-rfc7643-rfc7644.md`)
|
||||
- Schema.org Organization = collective actor (`schema-org-person-organization-membership.md`)
|
||||
|
||||
Canonical stance:
|
||||
|
||||
- Tenant = administrative/isolation scope
|
||||
- Realm = issuer/admin namespace (Scope specialization)
|
||||
- Organization = collective actor
|
||||
- Customer = commercial relationship role
|
||||
|
||||
Model relationships among them; do not synonymize.
|
||||
|
||||
## Conflict: Group, Role, Team, Community
|
||||
|
||||
Problem: IAM groups, collaboration teams, social communities, and authz member
|
||||
relations use overlapping labels.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- LDAP/SCIM Group = entry with member references (`ldap`, `scim` notes)
|
||||
- ActivityPub Group actor = collective social actor (`activitypub-actors-followers.md`)
|
||||
- Zanzibar `group#member@user` = authz tuple (`zanzibar-rebac.md`)
|
||||
- Cerbos derived role from group attribute (`cerbos-abac-derived-roles.md`)
|
||||
- Schema.org Organization subtypes include SportsTeam (`schema-org` note)
|
||||
|
||||
Canonical stance:
|
||||
|
||||
- Group = named collection with membership
|
||||
- Role = capability bundle or relationship label
|
||||
- Team = collaboration group or org unit
|
||||
- Community = participation-oriented collective actor
|
||||
|
||||
## Conflict: Member, Follower, Affiliate
|
||||
|
||||
Problem: membership, following, affiliation, and authz member relations hide
|
||||
distinct semantics behind `member`.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- ActivityPub Follow ≠ membership (`activitypub-actors-followers.md`)
|
||||
- Schema.org affiliation looser than memberOf (`schema-org-person-organization-membership.md`)
|
||||
- OpenFGA organization#member = authz projection (`openfga-modeling.md`)
|
||||
- FOAF member = group membership; knows = acquaintance (`foaf` note)
|
||||
|
||||
Canonical stance: use typed relationships with scope and evidence.
|
||||
|
||||
## Conflict: Profile And Persona
|
||||
|
||||
Problem: profiles are account records, RDF documents, public pages, or VC subjects.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- WebID profile document = RDF at URI (`webid-solid-profile.md`)
|
||||
- Kratos traits often called profile informally (`ory-kratos-keto.md`)
|
||||
- ActivityPub actor profile = public actor representation
|
||||
- Persona for pairwise/pseudonymous scoped presentation (OIDC, GDPR notes)
|
||||
|
||||
Canonical stance:
|
||||
|
||||
- Profile = presentation surface in scope
|
||||
- Persona = deliberate contextual presentation with privacy boundaries
|
||||
|
||||
## Conflict: Identifier, Credential, Claim
|
||||
|
||||
Problem: tokens and documents bundle all three.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- OIDC ID Token contains sub (identifier) and claims (`oidc-core-subject-identifiers.md`)
|
||||
- VC = signed claims with proof (`vc-data-model-2.md`)
|
||||
- DID verification method = cryptographic credential (`did-core.md`)
|
||||
- SAML AttributeStatement = claims; NameID = identifier (`saml-nameid-federation.md`)
|
||||
|
||||
Canonical stance: identifier refers; credential proves; claim states.
|
||||
|
||||
## Conflict: Synonymity, Linking, Matching, Merge
|
||||
|
||||
Problem: systems collapse probabilistic matches, verified links, and destructive
|
||||
merges into one feature.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
|
||||
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
|
||||
- Schema.org sameAs = weak web equivalence (`schema-org` note)
|
||||
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
|
||||
- MDM golden record merge = downstream anti-pattern (`deterministic` note)
|
||||
|
||||
Canonical stance: synonymity is scoped, evidenced, revocable assertion.
|
||||
|
||||
## Conflict: Credential (Auth) vs. Verifiable Credential
|
||||
|
||||
Problem: "credential" means password, OIDC token, or W3C VC.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- NIST authenticator/credential (`nist-800-63-4.md`)
|
||||
- VC Data Model verifiable credential (`vc-data-model-2.md`)
|
||||
- OpenID4VC bridges OAuth credential terminology with VCs (`openid4vc.md`)
|
||||
|
||||
Canonical stance: use Credential with context. VC maps to Credential containing
|
||||
Claims; login secrets map to Credential (authentication factor).
|
||||
|
||||
## Conflict: Issuer
|
||||
|
||||
Problem: issuer means OIDC OP, VC issuer, SAML IdP, or CSP.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- OIDC iss claim defines subject namespace (`oidc-core-subject-identifiers.md`)
|
||||
- VC issuer signs credential (`vc-data-model-2.md`)
|
||||
- NIST CSP performs proofing (`nist-800-63-4.md`)
|
||||
|
||||
Canonical stance: Issuer = Scope authority + Trust Relationship; specify protocol
|
||||
role when mapping.
|
||||
|
||||
## Conflict: Customer Account
|
||||
|
||||
Problem: `customer account` collapses login account, B2B subscriber organization,
|
||||
Stripe billing customer, and CRM account into one product noun.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Auth0 uses Subscriber for tenant holder, not customer account (`b2b-saas-subscriber-tenancy.md`)
|
||||
- Stytch: organization is the customer (`b2b-saas-subscriber-tenancy.md`)
|
||||
- Stripe Customer is billing object with subscriptions, not login (`stripe-customer-billing.md`)
|
||||
- ZITADEL/Keycloak org-as-tenant has no Customer Account type (`zitadel`, `keycloak` notes)
|
||||
|
||||
Canonical stance: **reject Customer Account** as canonical term. Resolve by layer:
|
||||
|
||||
- login/access → Account;
|
||||
- subscribing company → Organization + Customer role + Tenant;
|
||||
- billing/CRM → Commercial Record;
|
||||
- vendor↔customer link → Commercial Relationship.
|
||||
|
||||
## Review Queue
|
||||
|
||||
- [x] Customer Account — resolved; use Commercial Record + Commercial Relationship.
|
||||
- [ ] Decide Realm specialization — Keycloak evidence supports Realm as Scope
|
||||
specialization; promote in glossary if scenario review confirms.
|
||||
- [ ] Split authz `member` relation from social Membership in downstream adapters.
|
||||
- [ ] Classify schema.org sameAs default strength — corpus says weak only.
|
||||
- [ ] Standardize assurance dimensions — NIST IAL/AAL/FAL as orthogonal metadata.
|
||||
|
|
@ -0,0 +1,162 @@
|
|||
# Terminology Inventory
|
||||
|
||||
Status: draft. Updated after IDENTITY-WP-0003 corpus backfill. Mappings remain
|
||||
candidate until reviewed against `canon/CanonicalGlossary.md` and scenario
|
||||
tests.
|
||||
|
||||
## Use
|
||||
|
||||
Use this file to collect source terms and their current candidate canonical
|
||||
home. Use `terminology/TerminologyConflictMap.md` when a term is overloaded or
|
||||
has incompatible meanings across source families.
|
||||
|
||||
## Inventory
|
||||
|
||||
| Term | Candidate canonical concept | Source families | Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| actor | Actor | ActivityPub, FOAF, Cedar, proposal | Participation root. ActivityPub actor is server-hosted; FOAF Agent includes persons. |
|
||||
| natural person | Natural Person | FOAF, Schema.org, NIST, GDPR | Human being; FOAF Person and Schema.org Person align strongly. |
|
||||
| user | Convenience label only | SCIM, LDAP, Keycloak, ZITADEL, apps | Overloaded. Map by context: SCIM/LDAP User → Identity Record; Keycloak/ZITADEL User → Account. |
|
||||
| account | Account | SCIM, LDAP posixAccount, FOAF OnlineAccount, Keycloak | Operational access record in a scope. FOAF separates account from person explicitly. |
|
||||
| identity | Identity Record or Claim | Kratos, OIDC, DID, VC, apps | Kratos Identity = traits + credentials. Avoid bare `identity` as root noun. |
|
||||
| identifier | Identifier | OIDC sub, SAML NameID, LDAP DN, DID, WebID | Value referring within or across scopes. See Scoped Identifier when correlation is limited. |
|
||||
| scoped identifier | Scoped Identifier | OIDC pairwise, SAML transient, pseudonyms | Meaning limited to RP, sector, tenant, or session. |
|
||||
| credential | Credential | NIST, Kratos, OIDC token, VC, DID keys | Proof material. Distinguish VC (claim container) from password/WebAuthn. |
|
||||
| subject | Authenticated Subject | OIDC, SAML, SSF events | Protocol/security view after issuer identification. Not Actor or Principal. |
|
||||
| principal | Authorization Principal | Cedar, Cerbos, Zanzibar, OpenFGA | Decision-engine participant. OpenFGA `user:` prefix is not a human user. |
|
||||
| end-user | Natural Person (inferred) | OIDC | OIDC names the human implicitly; does not model as entity. |
|
||||
| profile | Profile | FOAF, WebID/Solid, SCIM attrs, ActivityPub | Presentation or attribute surface. Solid profile is user-controlled data. |
|
||||
| persona | Persona | proposal, privacy patterns | Contextual presentation; pairwise/pseudonymous profiles map here. |
|
||||
| agent | Actor or Artificial Agent | FOAF, ActivityPub, WebID | FOAF Agent includes humans; ActivityPub Service = Artificial Agent. |
|
||||
| bot | Artificial Agent | ActivityPub Service, apps | Automated actor; may use Service Account. |
|
||||
| service account | Service Account | Keycloak, ZITADEL machine user, Kratos | Non-human login or API identity. ZITADEL machine user, Kratos service patterns. |
|
||||
| machine user | Service Account | ZITADEL | Product term for non-human org identity. |
|
||||
| organization | Organization | Schema.org, Keycloak Orgs, ZITADEL, SCIM ext | Collective actor. SCIM `organization` attribute is not an Organization actor. |
|
||||
| legal entity | Legal Entity | business, compliance | Organization recognized under law; separate from tenant. |
|
||||
| customer | Customer (relationship role) | SaaS, vendor models | B2B subscriber org → Organization + Customer role + Tenant. Not Stripe Customer. |
|
||||
| vendor | Vendor (relationship role) | SaaS, multi-vendor | Provider role; not realm or tenant. |
|
||||
| subscriber | Organization + Customer role | Auth0 B2B SaaS | Convenience label only; not canonical. |
|
||||
| stripe customer | Commercial Record | Stripe, billing | Billing object; link to Tenant via metadata. Not Account. |
|
||||
| payment method / pm_xxx | Payment Instrument Reference | Stripe, Adyen | Tokenized provider reference; not Credential; not CHD in canon. |
|
||||
| payment mandate / setup intent | Payment Mandate (Commercial Commitment) | Stripe, SEPA | Authorization to charge; commitment_type payment_mandate. |
|
||||
| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
|
||||
| opportunity (crm) | Pipeline Pursuit | Salesforce, HubSpot | In-flight deal; not Commercial Commitment until binding trigger. |
|
||||
| forecast commit (salesforce) | Pipeline Pursuit metadata | Salesforce | Sales forecast category; not Commercial Commitment. |
|
||||
| closed won | Pipeline Pursuit lifecycle + optional commitment | CRM | Won stage alone does not auto-create active commitment. |
|
||||
| quote accepted / loi signed | Commercial Commitment (proposed) | CPQ, sales | Binding trigger with document evidence. |
|
||||
| crm account | Commercial Record | Salesforce, CRM | Commercial record; not login Account. |
|
||||
| customer account | Resolve by layer | billing, IAM, CRM | Not canonical — see TerminologyConflictMap. |
|
||||
| commercial record | Commercial Record | Stripe, CRM, billing | Record layer; payment/subscription/commerce state. |
|
||||
| commercial relationship | Commercial Relationship | vendor/customer SaaS | Vendor-to-customer typed relationship. |
|
||||
| commercial commitment | Commercial Commitment | contracts, subscriptions, KYC | Binding obligation raising identity stakes. |
|
||||
| beneficial owner | Beneficial Owner + Beneficial Ownership Relationship | KYC/AML, FinCEN CDD, FATF R24 | Natural person behind legal entity customer; dedicated relationship type with ownership/control prongs. |
|
||||
| beneficial ownership | Beneficial Ownership Relationship | FinCEN CDD, BOI, Open Ownership | Regulated Natural Person → Organization/Legal Entity linkage; not Ownership subtype. |
|
||||
| lei | Registry Identifier (regulatory_global) | GLEIF, ISO 17442, ICD 0199 | Legal entity identifier with annual renewal. |
|
||||
| duns | Proxy Commercial Identifier | D&B, ICD 0060 | Commercial-proxy registry identifier. |
|
||||
| uei | Registry Identifier (government_registry) | SAM.gov | US federal entity identifier. |
|
||||
| company registration number | Registry Identifier (government_registry) | national registers, ALEI | Authoritative incorporating-register identifier. |
|
||||
| alei / ibrn | Registry Identifier (government_registry) | ISO 8000-116 | Authoritative legal entity identifier from government register. |
|
||||
| iso 6523 / icd | Registry Identifier scheme | ISO/IEC 6523, PEPPOL | ICD + organization identifier encoding. |
|
||||
| legal person | Legal Person | eIDAS, civil law, agency | Natural or juridical person under law. |
|
||||
| paydex | Performance Evidence | D&B | Observed-tier payment performance metric. |
|
||||
| reputation | Resolve by assurance tier | marketplaces, credit | Not canonical — see Counterparty Assurance Gradient. |
|
||||
| star rating / review | Reputation Signal | Yelp, Amazon, App Store | Opinion-tier Evidence Source; weak, gamable. |
|
||||
| feedback score | Reputation Signal | eBay, Uber | Platform-local opinion tier. |
|
||||
| credit score | Performance Evidence | bureaus, D&B | Observed-tier counterparty metric. |
|
||||
| performance bond / surety | Commercial Commitment | construction, procurement | Committed-tier financial assurance. |
|
||||
| escrow | Commercial Commitment | marketplaces, Stripe | Committed-tier funds segregation. |
|
||||
| arbitration award | Adjudication Outcome | AAA, ICC, JAMS | Adjudicated-tier dispute result. |
|
||||
| court judgment | Adjudication Outcome | courts | Adjudicated-tier enforcement outcome. |
|
||||
| assurance gradient | Counterparty Assurance Gradient | commercial identity | Four-tier reliance model (opinion → adjudicated). |
|
||||
| control_basis | Beneficial Ownership Relationship metadata | FinCEN CDD, EU AMLD | Settled role enum (chief_executive, managing_member, …). |
|
||||
| binding_trigger | Pipeline Pursuit promotion | CRM adapters | Settled enum (quote_accepted, contract_executed, …). |
|
||||
| fincen id | Registry Identifier (government_registry) | BOI | Natural person government registry ID. |
|
||||
| person account | Natural Person + Commercial Record | Salesforce B2C | Adapter projection_mode person_account_combined only. |
|
||||
| ncage / cage | Registry Identifier (industry_association) | defense procurement | Industry association authority class. |
|
||||
| network token | Payment Instrument Reference | Visa VTS, MDES | instrument_type network_token. |
|
||||
| escrow (platform) | Commercial Commitment (escrow) | marketplaces | Committed tier when funds segregated. |
|
||||
| kyc / cip | Evidence Source + Assurance | FinCEN, FATF | Regulated commercial identity onboarding. |
|
||||
| crm account | Commercial Record | Salesforce | Company/household commercial record. |
|
||||
| fluid identity | Persona / weak binding | theory | Low commercial stake; intentional mutability. |
|
||||
| bound identity | Commercial Commitment present | theory | High counterparty reliance; stable identifiers. |
|
||||
| tenant | Tenant | ZITADEL org, SaaS, Keycloak (informal) | Administrative/isolation scope. Keycloak realm sometimes called tenant. |
|
||||
| realm | Realm | Keycloak | Hard identity/admin namespace. Candidate Scope specialization. |
|
||||
| scope | Scope | OIDC, Cerbos, OpenFGA store, proposal | Boundary for meaning, policy, or correlation. |
|
||||
| namespace | Scope | LDAP dc, Keto/OpenFGA, DID method | Naming or authorization partition. |
|
||||
| instance | Scope | ZITADEL | Deployment-level boundary above organizations. |
|
||||
| project | Application Scope | ZITADEL | Application/product container within org. |
|
||||
| community | Community | ActivityPub Group, proposal | Participation-oriented collective. ActivityPub Group may be Community or Group. |
|
||||
| family | Family or Household | proposal, GDPR-sensitive | Guardian/dependent semantics; privacy-sensitive. |
|
||||
| household | Family or Household | family accounts | Co-residence unit; may differ from legal family. |
|
||||
| group | Group | LDAP, SCIM, FOAF, ActivityPub, Cedar | Named collection. LDAP/SCIM group ≠ social community without context. |
|
||||
| team | Group or Organization Unit | Schema.org, collaboration | Collaboration unit; may be org sub-unit. |
|
||||
| role | Role | Keycloak, ZITADEL, Cedar, Cerbos, Schema.org OrganizationRole | Capability bundle or relationship label. Cerbos derived role may hide Ownership. |
|
||||
| grant | Role assignment | ZITADEL | Project role assignment; map to Delegation-like relationship. |
|
||||
| member | Membership Relationship | SCIM, LDAP, FOAF, Schema.org, Zanzibar | Relationship edge, not a noun for the participant. |
|
||||
| affiliation | Affiliation Relationship | Schema.org, FOAF knows | Looser than membership. FOAF knows is weak social affiliation. |
|
||||
| follower | Following Relationship | ActivityPub | Directed social subscription; not membership or authz. |
|
||||
| follow | Following Relationship | ActivityPub | Activity establishing follower edge. |
|
||||
| owner | Ownership Relationship | Zanzibar, Cerbos derived | Control/responsibility. Cerbos may encode as attribute not relationship. |
|
||||
| administrator | Administration Relationship | IAM, ZITADEL grants | Delegated management in scope. |
|
||||
| delegation | Delegation Relationship | Cedar context, agents | Bounded authority grant. Cedar context may carry delegatedBy. |
|
||||
| representation | Representation Relationship | SCIM manager, DID controller | Acting on behalf of another. DID controller may differ from subject. |
|
||||
| trust | Trust Relationship | federation, VC, DID | Reliance on issuer/verifier; federation metadata trust. |
|
||||
| claim | Claim | OIDC, SAML attributes, VC | Statement by issuer. SAML AttributeStatement → Claim. |
|
||||
| evidence | Evidence Source | NIST proofing, entity resolution, SSF | Supports claims and synonymity. SSF SET = event Evidence Source. |
|
||||
| assurance | Assurance Level | NIST IAL/AAL/FAL | Orthogonal identity, authentication, federation confidence. |
|
||||
| identifier binding | Identifier Binding | OIDC iss+sub, WebID-OIDC, SAML | Assertion that identifier refers to target in scope. |
|
||||
| synonymity | Synonymity Assertion | entity resolution, OIDC linking, schema.org sameAs | Scoped evidenced equivalence. sameAs is weak by default. |
|
||||
| weak match | Weak Synonymity Assertion | probabilistic matching | Probabilistic link; never destructive merge. |
|
||||
| strong link | Strong Synonymity Assertion | deterministic match, verified linking | Authoritative or verified; still scoped. |
|
||||
| same_as | Synonymity Assertion (strong) | synonymity model | High-confidence equivalence relation type. |
|
||||
| probably_same_as | Synonymity Assertion (weak) | probabilistic matching | Probabilistic equivalence relation type. |
|
||||
| linked_to | Synonymity Assertion (operational) | account linking | Convenience link without semantic sameness claim. |
|
||||
| pseudonym | Pseudonymous Identifier | GDPR, OIDC pairwise | Limits cross-scope correlation. |
|
||||
| pairwise subject | Scoped Identifier | OIDC | RP-specific sub preventing global correlation. |
|
||||
| relationship tuple | Relationship Tuple | Zanzibar, OpenFGA, Keto | Authz projection: subject#relation@object. |
|
||||
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
|
||||
| lifecycle state | Lifecycle State | SCIM active, SSF/RISC events, VC status | Applies to records, credentials, relationships, assertions. |
|
||||
| subscriber | Account / Identity Record | NIST | Enrolled party at CSP; not synonymous with Natural Person until IAL binding. |
|
||||
| issuer | Scope + Trust Relationship | OIDC iss, VC issuer, SAML IdP | Namespace authority for identifiers and claims. |
|
||||
| relying party | Scope | OIDC RP, SAML SP, NIST | Consumer of assertions; RP-local account binding. |
|
||||
| nameid | Identifier | SAML | Format attribute determines persistence and privacy semantics. |
|
||||
| distinguished name | Identifier | LDAP | Compound locator in directory namespace. |
|
||||
| externalid | Identifier | SCIM | Client-supplied cross-system correlation key. |
|
||||
| traits | Profile attributes | Kratos | Schema-validated identity attributes. |
|
||||
| verification method | Credential | DID Core | Cryptographic key in DID document. |
|
||||
| verifiable credential | Credential + Claim | VC Data Model | Signed claim set; distinct from login credential. |
|
||||
| holder | Actor (custody role) | VC, OpenID4VC | Party possessing VC; may differ from subject. |
|
||||
| verifier | Scope (evaluation role) | VC, OpenID4VC | Validates presentations. |
|
||||
| did | Identifier | DID Core | Decentralized identifier with method-specific resolution. |
|
||||
| webid | Identifier | WebID/Solid | HTTP URI identifying agent with dereferenceable profile. |
|
||||
| data subject | Natural Person | GDPR | Identifiable natural person for privacy regulation. |
|
||||
| pseudonymization | Processing pattern | GDPR | Technique; maps to Scoped Identifier + separated re-id key. |
|
||||
| controller | Organization (legal role) | GDPR | Downstream legal role; not canonical identity root. |
|
||||
| tuple (authz) | Relationship Tuple | Zanzibar | Authorization fact, not social relationship. |
|
||||
| userset | Authorization Principal (indirect) | Zanzibar, OpenFGA | Subject referenced via relation chain. |
|
||||
| derived role | Role (computed) | Cerbos | Role from attributes; should trace to Relationship when possible. |
|
||||
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
|
||||
| sameas | Weak Synonymity Assertion | Schema.org | Informal web equivalence; not strong link without evidence. |
|
||||
| organizationrole | Role + Membership | Schema.org | Temporal role with start/end dates. |
|
||||
| assurance level change | Assurance Level update | SSF/CAEP | Event affecting IAL/AAL/FAL metadata. |
|
||||
|
||||
## Source Note Citations
|
||||
|
||||
Terms above are grounded in backfilled notes under:
|
||||
|
||||
- `research/identity-provisioning/` (5 notes)
|
||||
- `research/authentication-federation/` (4 notes)
|
||||
- `research/authorization-relationships/` (4 notes)
|
||||
- `research/social-community-graphs/` (4 notes)
|
||||
- `research/verifiable-claims/` (3 notes)
|
||||
- `research/entity-resolution-privacy/` (3 notes)
|
||||
- `research/commercial-subscription/` (2 notes)
|
||||
- `research/commercial-identity/` (8 notes)
|
||||
|
||||
## Remaining Backfill Needs
|
||||
|
||||
- Split `group` into authorization group vs. social collective where sources
|
||||
disagree (OpenFGA member vs. ActivityPub follower).
|
||||
- Add product-version qualifiers when Keycloak/ZITADEL models evolve.
|
||||
- Promote stable mappings to `canon/CanonicalGlossary.md` after scenario
|
||||
review.
|
||||
636
infospace/assimilation/canon-federation/views/counterparty.md
Normal file
636
infospace/assimilation/canon-federation/views/counterparty.md
Normal file
|
|
@ -0,0 +1,636 @@
|
|||
# counterparty provenance reading index
|
||||
|
||||
Historical input only. Current canon and ADR-006 override superseded assertions.
|
||||
|
||||
- [research/CorpusIndex.md](../source/research/CorpusIndex.md) — d110cd1f6653.
|
||||
- [research/README.md](../source/research/README.md) — 1ab93b1176ac.
|
||||
- [research/ResearchSeed.md](../source/research/ResearchSeed.md) — 1e432ff04d17.
|
||||
- [research/commercial-identity/beneficial-ownership-kyc-boi.md](../source/research/commercial-identity/beneficial-ownership-kyc-boi.md) — 602aad062291.
|
||||
- [research/commercial-identity/commercial-identity-nuance-settlement.md](../source/research/commercial-identity/commercial-identity-nuance-settlement.md) — cabb54601ee7.
|
||||
- [research/commercial-identity/commercial-identity-synthesis.md](../source/research/commercial-identity/commercial-identity-synthesis.md) — ac70ecdb2046.
|
||||
- [research/commercial-identity/commercial-trust-binding-theory.md](../source/research/commercial-identity/commercial-trust-binding-theory.md) — fc7be6f0641b.
|
||||
- [research/commercial-identity/crm-pipeline-commitment-threshold.md](../source/research/commercial-identity/crm-pipeline-commitment-threshold.md) — 459828097e09.
|
||||
- [research/commercial-identity/duns-commercial-credit-identity.md](../source/research/commercial-identity/duns-commercial-credit-identity.md) — b33b789b047f.
|
||||
- [research/commercial-identity/eidas-eudi-legal-person-wallet.md](../source/research/commercial-identity/eidas-eudi-legal-person-wallet.md) — be8b05990cd0.
|
||||
- [research/commercial-identity/kyc-aml-commercial-identity-binding.md](../source/research/commercial-identity/kyc-aml-commercial-identity-binding.md) — 5d3f63465cd7.
|
||||
- [research/commercial-identity/legal-person-agency-contract.md](../source/research/commercial-identity/legal-person-agency-contract.md) — c3110cc62b49.
|
||||
- [research/commercial-identity/lei-gleif-legal-entity-identifier.md](../source/research/commercial-identity/lei-gleif-legal-entity-identifier.md) — ef2ba7156f6d.
|
||||
- [research/commercial-identity/payment-credential-pci-boundary.md](../source/research/commercial-identity/payment-credential-pci-boundary.md) — bcacaee7090c.
|
||||
- [research/commercial-identity/registry-identifier-subtypes.md](../source/research/commercial-identity/registry-identifier-subtypes.md) — 1a621787a869.
|
||||
- [research/commercial-identity/reputation-assurance-gradient.md](../source/research/commercial-identity/reputation-assurance-gradient.md) — 0c992d05657d.
|
||||
- [research/commercial-identity/salesforce-crm-commercial-record.md](../source/research/commercial-identity/salesforce-crm-commercial-record.md) — 52bf8c8dbbd7.
|
||||
- [research/commercial-subscription/b2b-saas-subscriber-tenancy.md](../source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md) — 133bf4325a7c.
|
||||
- [research/commercial-subscription/stripe-customer-billing.md](../source/research/commercial-subscription/stripe-customer-billing.md) — bb5c8fe3cab7.
|
||||
- [research/identity-provisioning/keycloak-organizations.md](../source/research/identity-provisioning/keycloak-organizations.md) — 09c43cdc9ecf.
|
||||
- [research/identity-provisioning/zitadel-organizations-projects.md](../source/research/identity-provisioning/zitadel-organizations-projects.md) — f4b1b6f4cce3.
|
||||
- [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) — 400641667064.
|
||||
- [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) — 06c8134a399a.
|
||||
- [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) — 5d22816b0bfe.
|
||||
|
||||
## Shared terminology and scenario fragments
|
||||
|
||||
|
||||
### S03. Enterprise With Sub-Organizations
|
||||
|
||||
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 36–47; SHA-256 `76282210f7df6bf26635ede205ed08215908eb82f8c84d411178bc01516a3f4d`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
## 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
|
||||
|
||||
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 48–59; SHA-256 `f674aa6466c45664d941359e2016a5f43a9ef58f58f1299f1ecb39003ef9a0c3`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
## 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
|
||||
|
||||
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 60–70; SHA-256 `40271bc925011808c60854faf342853ed48ff737afc7885921b62696b02c69d3`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
## 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.
|
||||
|
||||
```
|
||||
|
||||
### S07. Spontaneous Interest Group
|
||||
|
||||
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 83–93; SHA-256 `b4d3ed3df96d57dfc9defcb0395c134e500c79375972ccb978c2abfb64da7247`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
## 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.
|
||||
|
||||
```
|
||||
|
||||
### S15. Organization Represented By A Legal Entity And Operational Tenants
|
||||
|
||||
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 173–184; SHA-256 `a809f4bae8f243f9034887ad2c16903449999ae695c2fc1c4fc089cf9b7020a0`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
## 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.
|
||||
|
||||
```
|
||||
|
||||
### Conflict: Account
|
||||
|
||||
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 44–59; SHA-256 `5bc5a473a54d20d4cbba778d5f4508e0655cb755d118583715873b2ca81533a2`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
## Conflict: Account
|
||||
|
||||
Problem: account can mean login account, customer billing account, social
|
||||
media handle, service account, or FOAF online presence.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- FOAF OnlineAccount is service presence, explicitly not Person (`foaf-agent-person-group-onlineaccount.md`)
|
||||
- LDAP posixAccount is attribute bundle on person entry (`ldap-rfc4519-inetorgperson-rfc2798.md`)
|
||||
- ActivityPub `acct:` URI suggests account but actor is richer (`activitypub-actors-followers.md`)
|
||||
- ZITADEL machine user = Service Account (`zitadel-organizations-projects.md`)
|
||||
|
||||
Canonical stance: Account is operational access record in a scope. Billing
|
||||
records map to Commercial Record; commercial parties use Customer/Vendor roles
|
||||
and Commercial Relationship.
|
||||
|
||||
```
|
||||
|
||||
### Conflict: Tenant, Realm, Organization, Customer
|
||||
|
||||
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 80–99; SHA-256 `3e920b787354989a9cce48cc7b45c915150b215b4fcdfe054b854d9cc9748191`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
## Conflict: Tenant, Realm, Organization, Customer
|
||||
|
||||
Problem: multi-tenant products collapse isolation boundaries and commercial actors.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Keycloak Realm = hard namespace; Organization = B2B overlay (`keycloak-organizations.md`)
|
||||
- ZITADEL Organization = customer boundary + org actor (`zitadel-organizations-projects.md`)
|
||||
- SCIM has no tenant; org is string attribute (`scim-rfc7643-rfc7644.md`)
|
||||
- Schema.org Organization = collective actor (`schema-org-person-organization-membership.md`)
|
||||
|
||||
Canonical stance:
|
||||
|
||||
- Tenant = administrative/isolation scope
|
||||
- Realm = issuer/admin namespace (Scope specialization)
|
||||
- Organization = collective actor
|
||||
- Customer = commercial relationship role
|
||||
|
||||
Model relationships among them; do not synonymize.
|
||||
|
||||
```
|
||||
|
||||
### Conflict: Synonymity, Linking, Matching, Merge
|
||||
|
||||
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 163–177; SHA-256 `a714d30d2c1bedfcfe3020fa277c5a6226ec408eebd65efc33aadcba9b825ddf`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
## Conflict: Synonymity, Linking, Matching, Merge
|
||||
|
||||
Problem: systems collapse probabilistic matches, verified links, and destructive
|
||||
merges into one feature.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
|
||||
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
|
||||
- Schema.org sameAs = weak web equivalence (`schema-org` note)
|
||||
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
|
||||
- MDM golden record merge = downstream anti-pattern (`deterministic` note)
|
||||
|
||||
Canonical stance: synonymity is scoped, evidenced, revocable assertion.
|
||||
|
||||
```
|
||||
|
||||
### Conflict: Customer Account
|
||||
|
||||
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 204–222; SHA-256 `f88abdae039caa5135f7acfb7545747a141fe84703b23f45c918c209d1b73654`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
## Conflict: Customer Account
|
||||
|
||||
Problem: `customer account` collapses login account, B2B subscriber organization,
|
||||
Stripe billing customer, and CRM account into one product noun.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Auth0 uses Subscriber for tenant holder, not customer account (`b2b-saas-subscriber-tenancy.md`)
|
||||
- Stytch: organization is the customer (`b2b-saas-subscriber-tenancy.md`)
|
||||
- Stripe Customer is billing object with subscriptions, not login (`stripe-customer-billing.md`)
|
||||
- ZITADEL/Keycloak org-as-tenant has no Customer Account type (`zitadel`, `keycloak` notes)
|
||||
|
||||
Canonical stance: **reject Customer Account** as canonical term. Resolve by layer:
|
||||
|
||||
- login/access → Account;
|
||||
- subscribing company → Organization + Customer role + Tenant;
|
||||
- billing/CRM → Commercial Record;
|
||||
- vendor↔customer link → Commercial Relationship.
|
||||
|
||||
```
|
||||
|
||||
### legal entity
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 35–35; SHA-256 `da327d376e38707f55e5a1fbcdd4dee8f76bfc6cb4ec2e8468a90079f2ca1a5a`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| legal entity | Legal Entity | business, compliance | Organization recognized under law; separate from tenant. |
|
||||
```
|
||||
|
||||
### customer
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 36–36; SHA-256 `3e7b01c8abe4d58617b4902063eb4f5f14e7cac5da49a8ff778c33f9bc4716a9`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| customer | Customer (relationship role) | SaaS, vendor models | B2B subscriber org → Organization + Customer role + Tenant. Not Stripe Customer. |
|
||||
```
|
||||
|
||||
### vendor
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 37–37; SHA-256 `68a088043e8cb63172b4c57325022708379566e12a9cf605400179c16a4f46b7`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| vendor | Vendor (relationship role) | SaaS, multi-vendor | Provider role; not realm or tenant. |
|
||||
```
|
||||
|
||||
### subscriber
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 38–38; SHA-256 `3194121265ab0f7be752878e2168006b71c72b9f200f1e5e02aac4f078de5bf4`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| subscriber | Organization + Customer role | Auth0 B2B SaaS | Convenience label only; not canonical. |
|
||||
```
|
||||
|
||||
### stripe customer
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 39–39; SHA-256 `925da008d6dd0d1187f038d5bce0a3d6b6d52709672c0c7393f5b538eb65a389`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| stripe customer | Commercial Record | Stripe, billing | Billing object; link to Tenant via metadata. Not Account. |
|
||||
```
|
||||
|
||||
### payment method / pm_xxx
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 40–40; SHA-256 `1877175fcb5e0ce79e8d9145afd4ea37c10cbe9b03a4896568e868a2c38ae9ed`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| payment method / pm_xxx | Payment Instrument Reference | Stripe, Adyen | Tokenized provider reference; not Credential; not CHD in canon. |
|
||||
```
|
||||
|
||||
### payment mandate / setup intent
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 41–41; SHA-256 `aa0254f7ed95210d23dfad3d21c41c7bbe00cc32cf083e496477790f8172872a`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| payment mandate / setup intent | Payment Mandate (Commercial Commitment) | Stripe, SEPA | Authorization to charge; commitment_type payment_mandate. |
|
||||
```
|
||||
|
||||
### pan / cvv / chd
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 42–42; SHA-256 `84eacf96d9ff1a172086a00c1ecf31e94f5b594ee4dce3559e8ccd2525ab6b9c`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
|
||||
```
|
||||
|
||||
### opportunity (crm)
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 43–43; SHA-256 `640774866a49c042fefbd875643f674f087994baea3ae5c6d08566cd20fd05d4`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| opportunity (crm) | Pipeline Pursuit | Salesforce, HubSpot | In-flight deal; not Commercial Commitment until binding trigger. |
|
||||
```
|
||||
|
||||
### forecast commit (salesforce)
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 44–44; SHA-256 `812350a40d1fe20c5018bf1a505190133fa19466a47fc779bd60521551fba7e2`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| forecast commit (salesforce) | Pipeline Pursuit metadata | Salesforce | Sales forecast category; not Commercial Commitment. |
|
||||
```
|
||||
|
||||
### closed won
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 45–45; SHA-256 `945b08bd82ff22f0ac37487ec88482fbe4981779cdf62838cc47f3447a278017`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| closed won | Pipeline Pursuit lifecycle + optional commitment | CRM | Won stage alone does not auto-create active commitment. |
|
||||
```
|
||||
|
||||
### quote accepted / loi signed
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 46–46; SHA-256 `030a9e0caf4d46aab85d60e5941d5ae867e7cec24398c0208e4a9de4888f6edf`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| quote accepted / loi signed | Commercial Commitment (proposed) | CPQ, sales | Binding trigger with document evidence. |
|
||||
```
|
||||
|
||||
### crm account
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 47–47; SHA-256 `fae0815710a180822daf1af506d5fc59210049f8c5e2382e4094326b64a3e47f`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| crm account | Commercial Record | Salesforce, CRM | Commercial record; not login Account. |
|
||||
```
|
||||
|
||||
### customer account
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 48–48; SHA-256 `86c081e76edc36dd60d4c7c2db34ba23506e1e5b1e174459cd68eb65b913cfa2`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| customer account | Resolve by layer | billing, IAM, CRM | Not canonical — see TerminologyConflictMap. |
|
||||
```
|
||||
|
||||
### commercial record
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 49–49; SHA-256 `f509ef49a28b685208eb550efdd95c8dd53ae73ad0d19de697352288fc7bc953`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| commercial record | Commercial Record | Stripe, CRM, billing | Record layer; payment/subscription/commerce state. |
|
||||
```
|
||||
|
||||
### commercial relationship
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 50–50; SHA-256 `295a513939a88bc3fe49df82b43a20b0e89409b1969672a9a627fc63e6265f4c`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| commercial relationship | Commercial Relationship | vendor/customer SaaS | Vendor-to-customer typed relationship. |
|
||||
```
|
||||
|
||||
### commercial commitment
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 51–51; SHA-256 `3363732de312241bd3561fec75ec03893666439f63e5a38f005f729749769b7f`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| commercial commitment | Commercial Commitment | contracts, subscriptions, KYC | Binding obligation raising identity stakes. |
|
||||
```
|
||||
|
||||
### beneficial owner
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 52–52; SHA-256 `5c1d61373f92b79b054fe3d605a5d8171b2af91ebc9b3636f7b07015b3ce85f0`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| beneficial owner | Beneficial Owner + Beneficial Ownership Relationship | KYC/AML, FinCEN CDD, FATF R24 | Natural person behind legal entity customer; dedicated relationship type with ownership/control prongs. |
|
||||
```
|
||||
|
||||
### beneficial ownership
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 53–53; SHA-256 `8520301fabb9a30b9055f47f6b8b957636038fe4f6ec4a34761cfd233780d40a`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| beneficial ownership | Beneficial Ownership Relationship | FinCEN CDD, BOI, Open Ownership | Regulated Natural Person → Organization/Legal Entity linkage; not Ownership subtype. |
|
||||
```
|
||||
|
||||
### lei
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 54–54; SHA-256 `30a480ef227a05028bea2c34eb48bd0e892095df0f69ab496827932e67578b10`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| lei | Registry Identifier (regulatory_global) | GLEIF, ISO 17442, ICD 0199 | Legal entity identifier with annual renewal. |
|
||||
```
|
||||
|
||||
### duns
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 55–55; SHA-256 `e0b1fc126792ef64cf0a52bc555df0d32fee966a8a092cfdc3a93020d4feb7d9`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| duns | Proxy Commercial Identifier | D&B, ICD 0060 | Commercial-proxy registry identifier. |
|
||||
```
|
||||
|
||||
### uei
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 56–56; SHA-256 `20ba5293b13576bc0a7f5a1abde3a3eed2a056d43e34f2451196b9100e8338a3`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| uei | Registry Identifier (government_registry) | SAM.gov | US federal entity identifier. |
|
||||
```
|
||||
|
||||
### company registration number
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 57–57; SHA-256 `837e7698d5f10320661deea52464e849bcfb001472056c75563aded71989c8c4`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| company registration number | Registry Identifier (government_registry) | national registers, ALEI | Authoritative incorporating-register identifier. |
|
||||
```
|
||||
|
||||
### alei / ibrn
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 58–58; SHA-256 `222c1e86c484f60381795e6ba63bbbd684ce1b81eea5d2452ff3ec5a5bdf1dc3`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| alei / ibrn | Registry Identifier (government_registry) | ISO 8000-116 | Authoritative legal entity identifier from government register. |
|
||||
```
|
||||
|
||||
### iso 6523 / icd
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 59–59; SHA-256 `03da1b9755c903ab6c7d865a98c27223f9d7477629602c635394956f3404dc31`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| iso 6523 / icd | Registry Identifier scheme | ISO/IEC 6523, PEPPOL | ICD + organization identifier encoding. |
|
||||
```
|
||||
|
||||
### legal person
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 60–60; SHA-256 `5138cf572034760b21f365bcae5e73346acf6d88c2f65cee751d6b02454d9766`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| legal person | Legal Person | eIDAS, civil law, agency | Natural or juridical person under law. |
|
||||
```
|
||||
|
||||
### paydex
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 61–61; SHA-256 `e33cf7abce1daa982bf86f27307ac02eb6ae0c731c01a2b12f772f79195244f3`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| paydex | Performance Evidence | D&B | Observed-tier payment performance metric. |
|
||||
```
|
||||
|
||||
### reputation
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 62–62; SHA-256 `58cb7704debc05962d158b83e08d874c0c8a90112f1c6306c2977aad9c4a0765`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| reputation | Resolve by assurance tier | marketplaces, credit | Not canonical — see Counterparty Assurance Gradient. |
|
||||
```
|
||||
|
||||
### star rating / review
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 63–63; SHA-256 `3dbb10a8ab536c181da9205e3cfb4fae3031e0fd007fb4bb6205bb532e1959f1`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| star rating / review | Reputation Signal | Yelp, Amazon, App Store | Opinion-tier Evidence Source; weak, gamable. |
|
||||
```
|
||||
|
||||
### feedback score
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 64–64; SHA-256 `331ee6c8952359a690858c0265a784bd3c988f064e14e926c0abc020f5da8043`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| feedback score | Reputation Signal | eBay, Uber | Platform-local opinion tier. |
|
||||
```
|
||||
|
||||
### credit score
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 65–65; SHA-256 `0f724902241a45a7afc6f2fcd1667c19ddfbd32f5cb0d86e5a22031733a3ac70`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| credit score | Performance Evidence | bureaus, D&B | Observed-tier counterparty metric. |
|
||||
```
|
||||
|
||||
### performance bond / surety
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 66–66; SHA-256 `bf0fa441fbe0c7d96001a794d52dba447fd6c38bcd9e91e75fd4fcd70facd1cb`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| performance bond / surety | Commercial Commitment | construction, procurement | Committed-tier financial assurance. |
|
||||
```
|
||||
|
||||
### escrow
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 67–67; SHA-256 `143cdd47e48a1fe59fbf3d5070f82ee380b12332eebf3f2d2588dacdb4aa9752`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| escrow | Commercial Commitment | marketplaces, Stripe | Committed-tier funds segregation. |
|
||||
```
|
||||
|
||||
### assurance gradient
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 70–70; SHA-256 `315b682b202e367b0e9e455b6f686a95a6551ef797affa873cf666d6b1e15daf`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| assurance gradient | Counterparty Assurance Gradient | commercial identity | Four-tier reliance model (opinion → adjudicated). |
|
||||
```
|
||||
|
||||
### control_basis
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 71–71; SHA-256 `7923f00e6a10cdd05fd7b3bc8a5013fc837a36bd1f984fb84fc8f4447e147a7c`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| control_basis | Beneficial Ownership Relationship metadata | FinCEN CDD, EU AMLD | Settled role enum (chief_executive, managing_member, …). |
|
||||
```
|
||||
|
||||
### binding_trigger
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 72–72; SHA-256 `3b5a26c47324d97abaca610e75743903c27ab8ff1d8a69cb5c63d178bfe6ffc5`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| binding_trigger | Pipeline Pursuit promotion | CRM adapters | Settled enum (quote_accepted, contract_executed, …). |
|
||||
```
|
||||
|
||||
### fincen id
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 73–73; SHA-256 `f0bfb45e5363934041ff910a44cd0d69b578679f9c22719365fb0319b314fb78`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| fincen id | Registry Identifier (government_registry) | BOI | Natural person government registry ID. |
|
||||
```
|
||||
|
||||
### person account
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 74–74; SHA-256 `b75fc9b5ca6ef2146e019e342f8565d138eeefccc4b2ee845f010c835d5567eb`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| person account | Natural Person + Commercial Record | Salesforce B2C | Adapter projection_mode person_account_combined only. |
|
||||
```
|
||||
|
||||
### ncage / cage
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 75–75; SHA-256 `cadfb882fc19bda7c60bb8c75e0ed7e2e2b63974037ff07947a8a427d852b9b2`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| ncage / cage | Registry Identifier (industry_association) | defense procurement | Industry association authority class. |
|
||||
```
|
||||
|
||||
### network token
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 76–76; SHA-256 `a5c98ca7a1d5c4561951a88521194c57622622444be59eda1f534a2d4025120c`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| network token | Payment Instrument Reference | Visa VTS, MDES | instrument_type network_token. |
|
||||
```
|
||||
|
||||
### escrow (platform)
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 77–77; SHA-256 `d94b1eae6180f51c462ad52ce0cf8391f303fa035479d3b28d66047cab3dd29d`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| escrow (platform) | Commercial Commitment (escrow) | marketplaces | Committed tier when funds segregated. |
|
||||
```
|
||||
|
||||
### crm account
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 79–79; SHA-256 `9b1dcdfbe61b780895d51b439da2dffc0df0df7cc4dfb4d57de7dd3f8eb30d0e`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| crm account | Commercial Record | Salesforce | Company/household commercial record. |
|
||||
```
|
||||
|
||||
### bound identity
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 81–81; SHA-256 `18eccf5c41c7f60f38e0daa21762e9a88b6a5b829d4166c6b653c970e6f17061`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| bound identity | Commercial Commitment present | theory | High counterparty reliance; stable identifiers. |
|
||||
```
|
||||
|
||||
### policy
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 117–117; SHA-256 `13bcf330fb1989abf5ba4d7c673d2c3a646480236f81792abadb74afa660b983`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
|
||||
```
|
||||
|
||||
### contextual tuple
|
||||
|
||||
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 138–138; SHA-256 `5b1c5f8c2795fc54d61f319bd4c6238538588fa4026e779d0ed615e998133218`.
|
||||
Historical wording; this is not a current model definition.
|
||||
|
||||
```text
|
||||
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
|
||||
```
|
||||
|
|
@ -68,7 +68,7 @@ New content starts with a named consumer's signal in [demand](../../demand/).
|
|||
Implementation belongs in repository workplans. A model must declare its owned
|
||||
concepts, explicit imports, provenance, and examples before registry publication.
|
||||
Validate assignments against the federation ledger and review for duplicate
|
||||
ownership. Preserve historical source material until T07 records its disposition.
|
||||
ownership. Historical source material is preserved in the [T07 provenance workspace](../assimilation/canon-federation/README.md).
|
||||
|
||||
[Repository layout](../../docs/RepositoryLayout.md) explains content placement.
|
||||
T08 owns reciprocal interface cards once models and imports are established.
|
||||
|
|
|
|||
58
workplans/COMMERCE-WP-0003-corpus-provenance.md
Normal file
58
workplans/COMMERCE-WP-0003-corpus-provenance.md
Normal file
|
|
@ -0,0 +1,58 @@
|
|||
---
|
||||
id: COMMERCE-WP-0003
|
||||
type: workplan
|
||||
title: "Federation corpus provenance distribution"
|
||||
domain: financials
|
||||
repo: commerce-canon
|
||||
status: finished
|
||||
owner: codex
|
||||
topic_slug: commerce-canon
|
||||
created: "2026-09-06"
|
||||
updated: "2026-09-06"
|
||||
---
|
||||
|
||||
# Federation corpus provenance distribution
|
||||
|
||||
Implements CFED-WP-0001-T07; observe completed research without adopting new canon.
|
||||
|
||||
## Freeze and route the source material
|
||||
|
||||
```task
|
||||
id: COMMERCE-WP-0003-T01
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Preserve originals and place destination snapshots with source Git revision and
|
||||
hashes. Index sources by inherited concepts and retain context for shared notes.
|
||||
|
||||
## Split mixed material into traceable reading views
|
||||
|
||||
```task
|
||||
id: COMMERCE-WP-0003-T02
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Route exact terminology rows, conflict sections and scenarios by destination
|
||||
interest. Mark historical conflicts and reuse accepted ownership mappings.
|
||||
|
||||
## Verify and reconcile
|
||||
|
||||
```task
|
||||
id: COMMERCE-WP-0003-T03
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Verify full corpus coverage, immutable copies and fragment hashes, local links,
|
||||
assimilation metadata and repository checks. CFED T08/T09/T10 retain live interface,
|
||||
fleet and residual work. No new model adoption is claimed.
|
||||
|
||||
## Verification — 2026-09-06
|
||||
|
||||
G6 validator passes: all 45 sources routed, 69 byte-identical destination copies,
|
||||
153 exact fragments and 479 workspace links checked; originals unchanged.
|
||||
InfoTechCanon make check passes all 46 tests plus generated, canon and profile
|
||||
validation. Federation ownership validator passes.
|
||||
See [project evidence](../../prj-canon-federation/docs/evidence/2026-09-06-corpus-distribution.md).
|
||||
Loading…
Add table
Add a link
Reference in a new issue