From 372f671eef861e3f180eb5f9fc2fbd8c479ef8b7 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 6 Sep 2026 00:44:37 +0200 Subject: [PATCH] Distribute frozen federation corpus by concept destination Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b --- CHANGELOG.md | 7 + WORK-RECORDS.md | 4 + canon.yaml | 7 +- infospace/agent/global-agent-brief.md | 4 +- infospace/agent/retrieval-index.json | 43 +- infospace/agent/retrieval-index.md | 12 +- infospace/agent/retrieval-index.yaml | 28 +- infospace/artifacts/index.yaml | 19 + .../canon-federation/ASSIMILATION.md | 40 + .../assimilation/canon-federation/README.md | 10 + .../canon-federation/assimilation.yaml | 61 + .../canon-federation/comparison-matrix.md | 67 + .../canon-federation/distribution.json | 3247 +++++++++++++++++ .../canon-federation/extracted-concepts.yaml | 429 +++ .../canon-federation/mappings.yaml | 488 +++ .../canon-federation/open-questions.md | 13 + .../canon-federation/proposed-changes.md | 6 + .../canon-federation/source-summary.md | 13 + .../source/research/CorpusIndex.md | 105 + .../source/research/README.md | 10 + .../source/research/ResearchSeed.md | 549 +++ .../nist-800-63-4.md | 129 + .../oidc-core-subject-identifiers.md | 125 + .../saml-nameid-federation.md | 128 + .../shared-signals-caep-risc.md | 125 + ...cedar-principal-action-resource-context.md | 114 + .../cerbos-abac-derived-roles.md | 114 + .../openfga-modeling.md | 111 + .../zanzibar-rebac.md | 111 + .../beneficial-ownership-kyc-boi.md | 183 + .../commercial-identity-nuance-settlement.md | 240 ++ .../commercial-identity-synthesis.md | 153 + .../commercial-trust-binding-theory.md | 119 + .../crm-pipeline-commitment-threshold.md | 157 + .../duns-commercial-credit-identity.md | 91 + .../eidas-eudi-legal-person-wallet.md | 102 + .../kyc-aml-commercial-identity-binding.md | 105 + .../legal-person-agency-contract.md | 111 + .../lei-gleif-legal-entity-identifier.md | 95 + .../payment-credential-pci-boundary.md | 171 + .../registry-identifier-subtypes.md | 186 + .../reputation-assurance-gradient.md | 242 ++ .../salesforce-crm-commercial-record.md | 94 + .../b2b-saas-subscriber-tenancy.md | 102 + .../stripe-customer-billing.md | 106 + ...deterministic-vs-probabilistic-matching.md | 109 + .../gdpr-pseudonymization.md | 114 + .../synonymity-assertions.md | 106 + .../keycloak-organizations.md | 138 + .../ldap-rfc4519-inetorgperson-rfc2798.md | 130 + .../identity-provisioning/ory-kratos-keto.md | 138 + .../scim-rfc7643-rfc7644.md | 133 + .../zitadel-organizations-projects.md | 130 + .../activitypub-actors-followers.md | 114 + .../foaf-agent-person-group-onlineaccount.md | 113 + ...hema-org-person-organization-membership.md | 112 + .../webid-solid-profile.md | 108 + .../research/verifiable-claims/did-core.md | 109 + .../research/verifiable-claims/openid4vc.md | 106 + .../verifiable-claims/vc-data-model-2.md | 110 + .../source/scenarios/ScenarioTests.md | 194 + .../terminology/TerminologyConflictMap.md | 230 ++ .../terminology/TerminologyInventory.md | 162 + .../canon-federation/views/family-area.md | 111 + .../canon-federation/views/itc-access.md | 301 ++ .../canon-federation/views/itc-evid.md | 156 + .../canon-federation/views/itc-gov.md | 77 + .../canon-federation/views/itc-ident.md | 1439 ++++++++ .../canon-federation/views/itc-org.md | 905 +++++ infospace/indexes/artifact-tree.yaml | 185 +- infospace/indexes/concept-ownership.yaml | 6 +- infospace/indexes/import-matrix.yaml | 13 + infospace/views/by-concept.md | 3 +- infospace/views/by-mapping-target.md | 5 + infospace/views/import-matrix.md | 163 +- infospace/views/kernel-overview.md | 6 +- infospace/views/repository-tree.md | 63 +- tests/test_cli.py | 2 +- tests/test_service.py | 8 +- workplans/INFO-WP-0024-corpus-provenance.md | 62 + workplans/index.yaml | 8 + 81 files changed, 14146 insertions(+), 99 deletions(-) create mode 100644 infospace/assimilation/canon-federation/ASSIMILATION.md create mode 100644 infospace/assimilation/canon-federation/README.md create mode 100644 infospace/assimilation/canon-federation/assimilation.yaml create mode 100644 infospace/assimilation/canon-federation/comparison-matrix.md create mode 100644 infospace/assimilation/canon-federation/distribution.json create mode 100644 infospace/assimilation/canon-federation/extracted-concepts.yaml create mode 100644 infospace/assimilation/canon-federation/mappings.yaml create mode 100644 infospace/assimilation/canon-federation/open-questions.md create mode 100644 infospace/assimilation/canon-federation/proposed-changes.md create mode 100644 infospace/assimilation/canon-federation/source-summary.md create mode 100644 infospace/assimilation/canon-federation/source/research/CorpusIndex.md create mode 100644 infospace/assimilation/canon-federation/source/research/README.md create mode 100644 infospace/assimilation/canon-federation/source/research/ResearchSeed.md create mode 100644 infospace/assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md create mode 100644 infospace/assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md create mode 100644 infospace/assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md create mode 100644 infospace/assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md create mode 100644 infospace/assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md create mode 100644 infospace/assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md create mode 100644 infospace/assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md create mode 100644 infospace/assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md create mode 100644 infospace/assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md create mode 100644 infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md create mode 100644 infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md create mode 100644 infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md create mode 100644 infospace/assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md create mode 100644 infospace/assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md create mode 100644 infospace/assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md create mode 100644 infospace/assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md create mode 100644 infospace/assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md create mode 100644 infospace/assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md create mode 100644 infospace/assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md create mode 100644 infospace/assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md create mode 100644 infospace/assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md create mode 100644 infospace/assimilation/canon-federation/source/research/verifiable-claims/did-core.md create mode 100644 infospace/assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md create mode 100644 infospace/assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md create mode 100644 infospace/assimilation/canon-federation/source/scenarios/ScenarioTests.md create mode 100644 infospace/assimilation/canon-federation/source/terminology/TerminologyConflictMap.md create mode 100644 infospace/assimilation/canon-federation/source/terminology/TerminologyInventory.md create mode 100644 infospace/assimilation/canon-federation/views/family-area.md create mode 100644 infospace/assimilation/canon-federation/views/itc-access.md create mode 100644 infospace/assimilation/canon-federation/views/itc-evid.md create mode 100644 infospace/assimilation/canon-federation/views/itc-gov.md create mode 100644 infospace/assimilation/canon-federation/views/itc-ident.md create mode 100644 infospace/assimilation/canon-federation/views/itc-org.md create mode 100644 workplans/INFO-WP-0024-corpus-provenance.md diff --git a/CHANGELOG.md b/CHANGELOG.md index a8e9bf2..f8affa9 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -344,3 +344,10 @@ relationships, 0 consistency cycles, coverage 1.0, redundancy 0.0). Seed kernel: kernel documents, eleven domain models, three standards, the infospace scaffold, service surface (CLI / JSON / API), generated views and agent briefs. See `workplans/` ITC-WP-0001 through ITC-WP-0012 for the history. + +## 0.11.1 — 2026-09-06 + +Change: register observed canon-federation research provenance and generated +reading indexes (INFO-WP-0024 / CFED T07). Rationale: preserve source context and +make destination evidence traceable. No concept or identifier changes; no source +claims promoted. Supersedes no frozen input. Review on a revised source intake. diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 83d8552..9e384af 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -14,6 +14,7 @@ | workplan | INFO-WP-0021 | finished | — | workplans/INFO-WP-0021-identity-model.md | | workplan | INFO-WP-0022 | finished | — | workplans/INFO-WP-0022-social-collectives.md | | workplan | INFO-WP-0023 | finished | — | workplans/INFO-WP-0023-family-seed.md | +| workplan | INFO-WP-0024 | finished | — | workplans/INFO-WP-0024-corpus-provenance.md | | workplan | ITC-WP-0001 | finished | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md | | workplan | ITC-WP-0002 | finished | — | workplans/ITC-WP-0002-service-surface-cli-json-api.md | | workplan | ITC-WP-0003 | finished | — | workplans/ITC-WP-0003-validation-indexes-and-generated-views.md | @@ -52,6 +53,9 @@ | task | INFO-WP-0022-T03 | done | — | workplans/INFO-WP-0022-social-collectives.md | | task | INFO-WP-0023-T01 | done | — | workplans/INFO-WP-0023-family-seed.md | | task | INFO-WP-0023-T02 | done | — | workplans/INFO-WP-0023-family-seed.md | +| task | INFO-WP-0024-T01 | done | — | workplans/INFO-WP-0024-corpus-provenance.md | +| task | INFO-WP-0024-T02 | done | — | workplans/INFO-WP-0024-corpus-provenance.md | +| task | INFO-WP-0024-T03 | done | — | workplans/INFO-WP-0024-corpus-provenance.md | | task | ITC-WP-0001-T01 | done | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md | | task | ITC-WP-0001-T02 | done | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md | | task | ITC-WP-0001-T03 | done | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md | diff --git a/canon.yaml b/canon.yaml index c8f73a5..33d93e6 100644 --- a/canon.yaml +++ b/canon.yaml @@ -1,7 +1,7 @@ repository: info-tech-canon title: InfoTechCanon status: service-baseline -version: 0.11.0 +version: 0.11.1 description: > An evolving, markdown-first canon for building interoperable, adaptable, and extensible information-processing systems. @@ -192,6 +192,11 @@ assimilation: practice: infospace/assimilation/intake-and-assimilation-practice.md intake_dir: incoming/ records: + - id: assimilation/canon-federation + source: Completed identity-canon research corpus + disposition: observe + status: closed + path: infospace/assimilation/canon-federation/ - id: assimilation/it-capability-canon source: Information Technology Capability Canon (ITCC) v0.1 disposition: adapt diff --git a/infospace/agent/global-agent-brief.md b/infospace/agent/global-agent-brief.md index bb2ef62..86d4b2a 100644 --- a/infospace/agent/global-agent-brief.md +++ b/infospace/agent/global-agent-brief.md @@ -5,8 +5,8 @@ This brief summarizes the current canon service surface for agents. - Infospace slug: `canon` -- Artifact count: 79 -- Retrieval index items: 79 +- Artifact count: 80 +- Retrieval index items: 80 - Primary confidence command: `make validate` - Refresh generated indexes and views with: `make index` - Refresh agent briefs and interface templates with: `make agent-briefs` diff --git a/infospace/agent/retrieval-index.json b/infospace/agent/retrieval-index.json index 6f4e606..88cd449 100644 --- a/infospace/agent/retrieval-index.json +++ b/infospace/agent/retrieval-index.json @@ -60,8 +60,49 @@ } ], "infospace": "canon", - "item_count": 79, + "item_count": 80, "items": [ + { + "canonical_path": "assimilation/canon-federation/ASSIMILATION.md", + "id": "assimilation/canon-federation", + "imports": [ + "concept-area/family", + "model/access-control", + "model/evidence", + "model/identity", + "model/organization" + ], + "kind": "assimilation", + "owned_concepts": [ + "Canon federation research provenance" + ], + "relationships": [ + { + "target": "model/identity", + "type": "uses" + }, + { + "target": "model/evidence", + "type": "uses" + }, + { + "target": "model/organization", + "type": "uses" + }, + { + "target": "model/access-control", + "type": "uses" + }, + { + "target": "concept-area/family", + "type": "uses" + } + ], + "source_path": "infospace/assimilation/canon-federation/source/research/CorpusIndex.md", + "summary": "Canon artifact: Canon federation research provenance.", + "title": "Canon federation research provenance", + "warnings": [] + }, { "canonical_path": "assimilation/emission-cadence/ASSIMILATION.md", "id": "assimilation/emission-cadence", diff --git a/infospace/agent/retrieval-index.md b/infospace/agent/retrieval-index.md index 83d9128..b358f6c 100644 --- a/infospace/agent/retrieval-index.md +++ b/infospace/agent/retrieval-index.md @@ -4,7 +4,7 @@ Schema: `info-tech-canon.retrieval-index.v1` Infospace: `canon` -Items: **79** +Items: **80** ## Common Distinctions @@ -17,6 +17,16 @@ Items: **79** ## Items +### Canon federation research provenance + +- ID: `assimilation/canon-federation` +- Kind: `assimilation` +- Canonical path: `assimilation/canon-federation/ASSIMILATION.md` +- Source path: `infospace/assimilation/canon-federation/source/research/CorpusIndex.md` +- Summary: Canon artifact: Canon federation research provenance. +- Imports and anchors: `concept-area/family`, `model/access-control`, `model/evidence`, `model/identity`, `model/organization` +- Owned concepts: `Canon federation research provenance` + ### Assimilation — EmissionCadenceDeclaration handover - ID: `assimilation/emission-cadence` diff --git a/infospace/agent/retrieval-index.yaml b/infospace/agent/retrieval-index.yaml index 060b40e..2729e47 100644 --- a/infospace/agent/retrieval-index.yaml +++ b/infospace/agent/retrieval-index.yaml @@ -1,7 +1,33 @@ schema: info-tech-canon.retrieval-index.v1 infospace: canon -item_count: 79 +item_count: 80 items: +- id: assimilation/canon-federation + kind: assimilation + title: Canon federation research provenance + canonical_path: assimilation/canon-federation/ASSIMILATION.md + source_path: infospace/assimilation/canon-federation/source/research/CorpusIndex.md + summary: 'Canon artifact: Canon federation research provenance.' + owned_concepts: + - Canon federation research provenance + imports: + - concept-area/family + - model/access-control + - model/evidence + - model/identity + - model/organization + relationships: + - type: uses + target: model/identity + - type: uses + target: model/evidence + - type: uses + target: model/organization + - type: uses + target: model/access-control + - type: uses + target: concept-area/family + warnings: [] - id: assimilation/emission-cadence kind: assimilation title: "Assimilation \u2014 EmissionCadenceDeclaration handover" diff --git a/infospace/artifacts/index.yaml b/infospace/artifacts/index.yaml index 16c88a0..8db0e0c 100644 --- a/infospace/artifacts/index.yaml +++ b/infospace/artifacts/index.yaml @@ -1,4 +1,23 @@ artifacts: + - id: assimilation/canon-federation + path: assimilation/canon-federation/ASSIMILATION.md + kind: assimilation + title: Canon federation research provenance + provenance: + source_path: infospace/assimilation/canon-federation/source/research/CorpusIndex.md + placement: observed + placement_workplan: INFO-WP-0024 + relationships: + - type: uses + target: model/identity + - type: uses + target: model/evidence + - type: uses + target: model/organization + - type: uses + target: model/access-control + - type: uses + target: concept-area/family - id: concept-area/family path: concepts/family/FamilySeed.md kind: concept-area-seed diff --git a/infospace/assimilation/canon-federation/ASSIMILATION.md b/infospace/assimilation/canon-federation/ASSIMILATION.md new file mode 100644 index 0000000..9514188 --- /dev/null +++ b/infospace/assimilation/canon-federation/ASSIMILATION.md @@ -0,0 +1,40 @@ +# Canon federation research provenance + +Status: closed provenance distribution. Disposition: observe. Native workplan: +INFO-WP-0024; 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 + +45 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. diff --git a/infospace/assimilation/canon-federation/README.md b/infospace/assimilation/canon-federation/README.md new file mode 100644 index 0000000..9736b3a --- /dev/null +++ b/infospace/assimilation/canon-federation/README.md @@ -0,0 +1,10 @@ +# Research provenance entry point + +Read [ASSIMILATION.md](ASSIMILATION.md) before using historical sources. + +- [itc-ident](views/itc-ident.md) +- [itc-org](views/itc-org.md) +- [itc-access](views/itc-access.md) +- [itc-gov](views/itc-gov.md) +- [itc-evid](views/itc-evid.md) +- [family-area](views/family-area.md) diff --git a/infospace/assimilation/canon-federation/assimilation.yaml b/infospace/assimilation/canon-federation/assimilation.yaml new file mode 100644 index 0000000..0e9bb75 --- /dev/null +++ b/infospace/assimilation/canon-federation/assimilation.yaml @@ -0,0 +1,61 @@ +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/authentication-federation/nist-800-63-4.md +- source/research/authentication-federation/oidc-core-subject-identifiers.md +- source/research/authentication-federation/saml-nameid-federation.md +- source/research/authentication-federation/shared-signals-caep-risc.md +- source/research/authorization-relationships/cedar-principal-action-resource-context.md +- source/research/authorization-relationships/cerbos-abac-derived-roles.md +- source/research/authorization-relationships/openfga-modeling.md +- source/research/authorization-relationships/zanzibar-rebac.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/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md +- source/research/entity-resolution-privacy/gdpr-pseudonymization.md +- source/research/entity-resolution-privacy/synonymity-assertions.md +- source/research/identity-provisioning/keycloak-organizations.md +- source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md +- source/research/identity-provisioning/ory-kratos-keto.md +- source/research/identity-provisioning/scim-rfc7643-rfc7644.md +- source/research/identity-provisioning/zitadel-organizations-projects.md +- source/research/social-community-graphs/activitypub-actors-followers.md +- source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md +- source/research/social-community-graphs/schema-org-person-organization-membership.md +- source/research/social-community-graphs/webid-solid-profile.md +- source/research/verifiable-claims/did-core.md +- source/research/verifiable-claims/openid4vc.md +- source/research/verifiable-claims/vc-data-model-2.md +- source/scenarios/ScenarioTests.md +- source/terminology/TerminologyConflictMap.md +- source/terminology/TerminologyInventory.md +status: closed +disposition: observe +impacts: +- itc-ident +- itc-org +- itc-access +- itc-gov +- itc-evid +- family-area +workplan: INFO-WP-0024 diff --git a/infospace/assimilation/canon-federation/comparison-matrix.md b/infospace/assimilation/canon-federation/comparison-matrix.md new file mode 100644 index 0000000..afceab2 --- /dev/null +++ b/infospace/assimilation/canon-federation/comparison-matrix.md @@ -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 | diff --git a/infospace/assimilation/canon-federation/distribution.json b/infospace/assimilation/canon-federation/distribution.json new file mode 100644 index 0000000..feac3f0 --- /dev/null +++ b/infospace/assimilation/canon-federation/distribution.json @@ -0,0 +1,3247 @@ +{ + "schema_version": 1, + "source_repository": "commerce-canon", + "source_commit": "8a07292dd78d094151f165d3ac1dfc7512114308", + "files": [ + { + "source_path": "research/CorpusIndex.md", + "sha256": "d110cd1f665392ad7c5069c4432375d888290fa2786b5e0bb89f75b0597784ad", + "source_area": "shared-context", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area", + "counterparty" + ], + "rationale": "Shared source context and cross-model terminology/scenarios.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/CorpusIndex.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/CorpusIndex.md" + } + ] + }, + { + "source_path": "research/README.md", + "sha256": "1ab93b1176acaa499bbad9fd82a2d631356f1d131e63423ff26a0372cbc7cbc2", + "source_area": "shared-context", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area", + "counterparty" + ], + "rationale": "Shared source context and cross-model terminology/scenarios.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/README.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/README.md" + } + ] + }, + { + "source_path": "research/ResearchSeed.md", + "sha256": "1e432ff04d17f8cc27e4723931ce67b09eab28ba41da1ea62d08c26b74c03e0f", + "source_area": "shared-context", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area", + "counterparty" + ], + "rationale": "Shared source context and cross-model terminology/scenarios.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/ResearchSeed.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/ResearchSeed.md" + } + ] + }, + { + "source_path": "research/authentication-federation/nist-800-63-4.md", + "sha256": "8697b739399c59bce96683aabeedd22eaf847bd09245d00176e896df734c802f", + "source_area": "authentication-federation", + "applicable_models": [ + "itc-ident", + "itc-access", + "itc-evid" + ], + "rationale": "Route authentication-federation provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md" + } + ] + }, + { + "source_path": "research/authentication-federation/oidc-core-subject-identifiers.md", + "sha256": "e1a0bf8a27540c7f417a3878d3e07060738c1c8521101d7e807082823e15ef8e", + "source_area": "authentication-federation", + "applicable_models": [ + "itc-ident", + "itc-access", + "itc-evid" + ], + "rationale": "Route authentication-federation provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md" + } + ] + }, + { + "source_path": "research/authentication-federation/saml-nameid-federation.md", + "sha256": "394457cf75d2a993c0de62be6542f5948d96519315d60a4297cd6cffee8547f7", + "source_area": "authentication-federation", + "applicable_models": [ + "itc-ident", + "itc-access", + "itc-evid" + ], + "rationale": "Route authentication-federation provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md" + } + ] + }, + { + "source_path": "research/authentication-federation/shared-signals-caep-risc.md", + "sha256": "7303fd449a83d3398d0baa686fc9ae9c69c3e6eb1897dc1c8987ee3ff390f499", + "source_area": "authentication-federation", + "applicable_models": [ + "itc-ident", + "itc-access", + "itc-evid" + ], + "rationale": "Route authentication-federation provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md" + } + ] + }, + { + "source_path": "research/authorization-relationships/cedar-principal-action-resource-context.md", + "sha256": "1932a8632dd36a245ec26dec06100887d1d27a7c00df8d5861a7cf78da0ad110", + "source_area": "authorization-relationships", + "applicable_models": [ + "itc-access", + "itc-ident", + "itc-org" + ], + "rationale": "Route authorization-relationships provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md" + } + ] + }, + { + "source_path": "research/authorization-relationships/cerbos-abac-derived-roles.md", + "sha256": "c35f15042d45a83b6825ed43accf0f4c1249d35fa0ea87910af1df17bc31ce13", + "source_area": "authorization-relationships", + "applicable_models": [ + "itc-access", + "itc-ident", + "itc-org" + ], + "rationale": "Route authorization-relationships provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md" + } + ] + }, + { + "source_path": "research/authorization-relationships/openfga-modeling.md", + "sha256": "e2d03ddfa7bee192a1e6dba39931adc02a97b93d7a8e305c2479809d9569b442", + "source_area": "authorization-relationships", + "applicable_models": [ + "itc-access", + "itc-ident", + "itc-org" + ], + "rationale": "Route authorization-relationships provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md" + } + ] + }, + { + "source_path": "research/authorization-relationships/zanzibar-rebac.md", + "sha256": "1f736195ab4b2d7b0639198cee687b25d5a2a7576388c75c400cc02ab0189be7", + "source_area": "authorization-relationships", + "applicable_models": [ + "itc-access", + "itc-ident", + "itc-org" + ], + "rationale": "Route authorization-relationships provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md" + } + ] + }, + { + "source_path": "research/commercial-identity/beneficial-ownership-kyc-boi.md", + "sha256": "602aad0622915b5a87fc1faa85f1378ef81cf1d988c1d44420c5f51be165aa43", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md" + } + ] + }, + { + "source_path": "research/commercial-identity/commercial-identity-nuance-settlement.md", + "sha256": "cabb54601ee7d005f33ce71252f9003137e0bb64cb297ac65c1e4e13cad4ace9", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md" + } + ] + }, + { + "source_path": "research/commercial-identity/commercial-identity-synthesis.md", + "sha256": "ac70ecdb2046820a740ea72cfecc64f0add9acc25697fc04261fd60fba8fd3c8", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md" + } + ] + }, + { + "source_path": "research/commercial-identity/commercial-trust-binding-theory.md", + "sha256": "fc7be6f0641bf7fe88aee918c060c1f31643ed582b181f775133762245477e2e", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md" + } + ] + }, + { + "source_path": "research/commercial-identity/crm-pipeline-commitment-threshold.md", + "sha256": "459828097e09d3c1fc0ea3c9febaee13f2be96e68a0fdd14aec4983b63eec8e1", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md" + } + ] + }, + { + "source_path": "research/commercial-identity/duns-commercial-credit-identity.md", + "sha256": "b33b789b047ff8ea53c4518f7c3f4933921c4289afb21e2fb8121e971f1e1740", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md" + } + ] + }, + { + "source_path": "research/commercial-identity/eidas-eudi-legal-person-wallet.md", + "sha256": "be8b05990cd05f8d157c1cf56604649db5abcfbeb9f376f8e9db45c0d3e3466e", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md" + } + ] + }, + { + "source_path": "research/commercial-identity/kyc-aml-commercial-identity-binding.md", + "sha256": "5d3f63465cd786e76bbd067894ad94ab8c424733800bcae44f50362668bf5071", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md" + } + ] + }, + { + "source_path": "research/commercial-identity/legal-person-agency-contract.md", + "sha256": "c3110cc62b493138d359489d6fb99c8306edc0f117b5f8d9863cc1af97bf14d1", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md" + } + ] + }, + { + "source_path": "research/commercial-identity/lei-gleif-legal-entity-identifier.md", + "sha256": "ef2ba7156f6dffd799f84ef482d4848dc800dce8854acf06aa4a43da48596354", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md" + } + ] + }, + { + "source_path": "research/commercial-identity/payment-credential-pci-boundary.md", + "sha256": "bcacaee7090ca32060cbaca19327471b123bb7e3f7b1ddc1dd6afa53bf98e787", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md" + } + ] + }, + { + "source_path": "research/commercial-identity/registry-identifier-subtypes.md", + "sha256": "1a621787a86962c907e2eb943aef4002ff86c53e8e1877e3a5aed36a8470f4fb", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md" + } + ] + }, + { + "source_path": "research/commercial-identity/reputation-assurance-gradient.md", + "sha256": "0c992d05657d71e0208ab15e16348b49e522b37ea8248a579e2afaaf0d0aeb4c", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md" + } + ] + }, + { + "source_path": "research/commercial-identity/salesforce-crm-commercial-record.md", + "sha256": "52bf8c8dbbd787f42d6f088ccd65cf21cf7f5360448b81d5f9c5fd96c55409a4", + "source_area": "commercial-identity", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-evid", + "itc-org", + "itc-gov" + ], + "rationale": "Route commercial-identity provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md" + } + ] + }, + { + "source_path": "research/commercial-subscription/b2b-saas-subscriber-tenancy.md", + "sha256": "133bf4325a7cdd96af010bb682e7e1825a947418aa8c0ac9f1af10e44f9e8aa6", + "source_area": "commercial-subscription", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-org" + ], + "rationale": "Route commercial-subscription provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md" + } + ] + }, + { + "source_path": "research/commercial-subscription/stripe-customer-billing.md", + "sha256": "bb5c8fe3cab7421e952b518421fe517e8e007d65f3f67536d5c65e7fe841331c", + "source_area": "commercial-subscription", + "applicable_models": [ + "counterparty", + "itc-ident", + "itc-org" + ], + "rationale": "Route commercial-subscription provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md" + } + ] + }, + { + "source_path": "research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md", + "sha256": "12585f844728d3d18ff582c386b6cdc2610c8ce0112d5e1ff62055d3d8663985", + "source_area": "entity-resolution-privacy", + "applicable_models": [ + "itc-ident", + "itc-evid" + ], + "rationale": "Route entity-resolution-privacy provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md" + } + ] + }, + { + "source_path": "research/entity-resolution-privacy/gdpr-pseudonymization.md", + "sha256": "de2bfcf7f52b37d2040b31236ed4a70da10f12fed753ec2f7f0e28c3f2fd4c70", + "source_area": "entity-resolution-privacy", + "applicable_models": [ + "itc-ident", + "itc-evid" + ], + "rationale": "Route entity-resolution-privacy provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md" + } + ] + }, + { + "source_path": "research/entity-resolution-privacy/synonymity-assertions.md", + "sha256": "6ba40ec3722185e8ca3fce6d2af95f504f4bd5e4bb602138460906d13c9378b1", + "source_area": "entity-resolution-privacy", + "applicable_models": [ + "itc-ident", + "itc-evid" + ], + "rationale": "Route entity-resolution-privacy provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md" + } + ] + }, + { + "source_path": "research/identity-provisioning/keycloak-organizations.md", + "sha256": "09c43cdc9ecf28437b3440ed180ec47892d38077d531b20a803ca6a97b68b606", + "source_area": "identity-provisioning", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-evid", + "counterparty" + ], + "rationale": "Route identity-provisioning provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md" + } + ] + }, + { + "source_path": "research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md", + "sha256": "c3f3323a3f25bd0bde0b4ba5010223ad45cc50bbf353b2662d4eead86b1d6e06", + "source_area": "identity-provisioning", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-evid" + ], + "rationale": "Route identity-provisioning provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md" + } + ] + }, + { + "source_path": "research/identity-provisioning/ory-kratos-keto.md", + "sha256": "5cd12c38f8d3c18c600c3648bc8126e51c88a9fe4a3ea2932ff110942a9f1db1", + "source_area": "identity-provisioning", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-evid" + ], + "rationale": "Route identity-provisioning provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md" + } + ] + }, + { + "source_path": "research/identity-provisioning/scim-rfc7643-rfc7644.md", + "sha256": "c5c03952ac2f8025ab44b9ac7877183fc97d82da97ee9ebd1da8481a63dd47d9", + "source_area": "identity-provisioning", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-evid" + ], + "rationale": "Route identity-provisioning provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md" + } + ] + }, + { + "source_path": "research/identity-provisioning/zitadel-organizations-projects.md", + "sha256": "f4b1b6f4cce3c114ae17bb8dcfb3e81a218cfe8aa3a02ed1f84c994fda3699ef", + "source_area": "identity-provisioning", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-evid", + "counterparty" + ], + "rationale": "Route identity-provisioning provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md" + } + ] + }, + { + "source_path": "research/social-community-graphs/activitypub-actors-followers.md", + "sha256": "8b28bfc385d112bc7afc8115300eafac3c52015d66f2c6c801ed3eb900dd7310", + "source_area": "social-community-graphs", + "applicable_models": [ + "itc-ident", + "itc-org" + ], + "rationale": "Route social-community-graphs provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md" + } + ] + }, + { + "source_path": "research/social-community-graphs/foaf-agent-person-group-onlineaccount.md", + "sha256": "4131e7685da56ee240b302c513ef51aebd791a78e438042d356769dc86abb2d6", + "source_area": "social-community-graphs", + "applicable_models": [ + "itc-ident", + "itc-org" + ], + "rationale": "Route social-community-graphs provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md" + } + ] + }, + { + "source_path": "research/social-community-graphs/schema-org-person-organization-membership.md", + "sha256": "bc274f7cf1ff237ed25fbc0a975ab04520f69936dc0262da0cd88b10e66fb755", + "source_area": "social-community-graphs", + "applicable_models": [ + "itc-ident", + "itc-org" + ], + "rationale": "Route social-community-graphs provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md" + } + ] + }, + { + "source_path": "research/social-community-graphs/webid-solid-profile.md", + "sha256": "abf0c62e23b030eb186a1eac992cc2b0c53e8ee46c4415d2c9a067a3ce9f297f", + "source_area": "social-community-graphs", + "applicable_models": [ + "itc-ident", + "itc-org" + ], + "rationale": "Route social-community-graphs provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md" + } + ] + }, + { + "source_path": "research/verifiable-claims/did-core.md", + "sha256": "cbe5fd46e093c9b98339ca40cad143878b4796bc488b223b0a2662d539e65e3f", + "source_area": "verifiable-claims", + "applicable_models": [ + "itc-ident", + "itc-evid", + "itc-org" + ], + "rationale": "Route verifiable-claims provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/verifiable-claims/did-core.md" + } + ] + }, + { + "source_path": "research/verifiable-claims/openid4vc.md", + "sha256": "e6fcc06121460464cc945fca5b174175c794a63c3134650543029d0b28c23e15", + "source_area": "verifiable-claims", + "applicable_models": [ + "itc-ident", + "itc-evid", + "itc-org" + ], + "rationale": "Route verifiable-claims provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md" + } + ] + }, + { + "source_path": "research/verifiable-claims/vc-data-model-2.md", + "sha256": "dae7bc679c6c4e9df4e18e109ac0d069bf8036c1d7606c3e1d189c37351d5ee5", + "source_area": "verifiable-claims", + "applicable_models": [ + "itc-ident", + "itc-evid", + "itc-org", + "family-area" + ], + "rationale": "Route verifiable-claims provenance to its commercial assignments and/or imported technical concepts; no new definitions adopted.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md" + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "sha256": "4006416670649528dbf0a9e064f4b2a4e2817c89370ce395e2882761ad2d473e", + "source_area": "shared-context", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area", + "counterparty" + ], + "rationale": "Shared source context and cross-model terminology/scenarios.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/scenarios/ScenarioTests.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/scenarios/ScenarioTests.md" + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "sha256": "06c8134a399a7377e108a975c69f03cf0ad4aa57dc7c67dbf97eb6e48f2aee11", + "source_area": "shared-context", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area", + "counterparty" + ], + "rationale": "Shared source context and cross-model terminology/scenarios.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/terminology/TerminologyConflictMap.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/terminology/TerminologyConflictMap.md" + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "sha256": "5d22816b0bfe8671dc57f1d2cd5bd13dd0b6d15a77fcab7e4157d1f05dcfa4e1", + "source_area": "shared-context", + "applicable_models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area", + "counterparty" + ], + "rationale": "Shared source context and cross-model terminology/scenarios.", + "destinations": [ + { + "repo": "info-tech-canon", + "path": "infospace/assimilation/canon-federation/source/terminology/TerminologyInventory.md" + }, + { + "repo": "commerce-canon", + "path": "infospace/assimilation/canon-federation/source/terminology/TerminologyInventory.md" + } + ] + } + ], + "views": [ + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 13, + "end_line": 24, + "title": "S01. Single Person With One Local Account", + "sha256": "0040dd866009ad1199e89f89267e3aab86894859f6ae6d07f393e4f0b8cdb6f5", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 25, + "end_line": 35, + "title": "S02. Person With Multiple Accounts Across Scopes", + "sha256": "69cabdc1680936fffd25378d9a1fcaa129c258eeca03663a3c9e9718def6fd59", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 36, + "end_line": 47, + "title": "S03. Enterprise With Sub-Organizations", + "sha256": "76282210f7df6bf26635ede205ed08215908eb82f8c84d411178bc01516a3f4d", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 48, + "end_line": 59, + "title": "S04. Vendor Tenant Serving Customer Tenants", + "sha256": "f674aa6466c45664d941359e2016a5f43a9ef58f58f1299f1ecb39003ef9a0c3", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 60, + "end_line": 70, + "title": "S05. Customer Organization With Delegated Administrators", + "sha256": "40271bc925011808c60854faf342853ed48ff737afc7885921b62696b02c69d3", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 71, + "end_line": 82, + "title": "S06. Family With Guardian And Dependent Accounts", + "sha256": "a3f0705f7168974632f544891e08403fdcdaa2b205f40ae899bc0483af445106", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "family-area", + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 83, + "end_line": 93, + "title": "S07. Spontaneous Interest Group", + "sha256": "b4d3ed3df96d57dfc9defcb0395c134e500c79375972ccb978c2abfb64da7247", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 94, + "end_line": 105, + "title": "S08. Community With Members, Moderators, And Followers", + "sha256": "83de4820c3662f015970f7360ceb1278bca3fa8bf63037826316d63643e580ae", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 106, + "end_line": 116, + "title": "S09. Social Media Follower Graph", + "sha256": "fd342efc3924c194784c48d937333426addcac7e8404a1834881e284937777b3", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 117, + "end_line": 127, + "title": "S10. Bot Or Service Account Acting For An Organization", + "sha256": "b7671fae9cd9c0c2070588558e72fc34e6a40a449b088738761253df23955228", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 128, + "end_line": 139, + "title": "S11. AI Agent Acting Under Delegated Authority", + "sha256": "c26e3ad239e21e320a65dcee09b95260db582d26ff08c3b7cf537577c9501275", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 140, + "end_line": 150, + "title": "S12. Weak Identity Match From Imported Data", + "sha256": "b5f26ea04922d59bfe1c7dd240a2348e4afc6cc45a257ea5dfbb733e614649d5", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-evid", + "itc-ident" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 151, + "end_line": 161, + "title": "S13. Strong Account Link After Explicit Verification", + "sha256": "4d4ec21f4e4a70bd1095e0baa7691c39497f970fab42a073683a0200c5ee5949", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 162, + "end_line": 172, + "title": "S14. Pseudonymous Profile Linked Only Within A Restricted Scope", + "sha256": "01618fb5fc15400461ceb46402bc5c908fdd3555c3e2aa04adb964faf466bab1", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "scenarios/ScenarioTests.md", + "start_line": 173, + "end_line": 184, + "title": "S15. Organization Represented By A Legal Entity And Operational Tenants", + "sha256": "a809f4bae8f243f9034887ad2c16903449999ae695c2fc1c4fc089cf9b7020a0", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 6, + "end_line": 28, + "title": "Conflict: User", + "sha256": "03cc685a840d47b36bf124aa8c1465216dfcb1c463f911dbe5e934b7fa81e3b6", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 29, + "end_line": 43, + "title": "Conflict: Identity", + "sha256": "acf3297ff3ac425a535639c97c8e9368833d0e4e78225679263bcd5ab6ecbbed", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 44, + "end_line": 59, + "title": "Conflict: Account", + "sha256": "5bc5a473a54d20d4cbba778d5f4508e0655cb755d118583715873b2ca81533a2", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 60, + "end_line": 79, + "title": "Conflict: Subject, Principal, Actor", + "sha256": "5f7282450703c7ab38c6d6b044bf99731c274974dd8ece1785de74bdc1365feb", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 80, + "end_line": 99, + "title": "Conflict: Tenant, Realm, Organization, Customer", + "sha256": "3e920b787354989a9cce48cc7b45c915150b215b4fcdfe054b854d9cc9748191", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 100, + "end_line": 119, + "title": "Conflict: Group, Role, Team, Community", + "sha256": "0a8cd0ebc16563b59014cbaf3e026ae6633f24aa8f26dabe1c2bfebf70b4f3d4", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 120, + "end_line": 133, + "title": "Conflict: Member, Follower, Affiliate", + "sha256": "59c522c4fa0602246033c3d4bf91b91d718119bc116ad60df9f9c7fda616cefc", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 134, + "end_line": 149, + "title": "Conflict: Profile And Persona", + "sha256": "7e0380ec397e1c991a40391d366913e7087b4a3f45d416b92c068e34a71450b8", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 150, + "end_line": 162, + "title": "Conflict: Identifier, Credential, Claim", + "sha256": "ff9f6502a126229aa65ea20817e698285a74df128aa35ea286cf24f87462216e", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 163, + "end_line": 177, + "title": "Conflict: Synonymity, Linking, Matching, Merge", + "sha256": "a714d30d2c1bedfcfe3020fa277c5a6226ec408eebd65efc33aadcba9b825ddf", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 178, + "end_line": 190, + "title": "Conflict: Credential (Auth) vs. Verifiable Credential", + "sha256": "ba22d9bb343b383c489c3887a36dafea1c1b93cbed3d9b799727eb5f2a03ecac", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 191, + "end_line": 203, + "title": "Conflict: Issuer", + "sha256": "e7ca901947a8931fb1c427fa217f22bac361c15aa6c57da67580d799676980a7", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyConflictMap.md", + "start_line": 204, + "end_line": 222, + "title": "Conflict: Customer Account", + "sha256": "f88abdae039caa5135f7acfb7545747a141fe84703b23f45c918c209d1b73654", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 17, + "end_line": 17, + "title": "actor", + "sha256": "6ceb7d60a09ca5471237860930d88dd8367e7bbda1cd4605eee58d89f9a5bd72", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 18, + "end_line": 18, + "title": "natural person", + "sha256": "973e4a0177d5241ce7090eb6e36e29cb8036bd3b23c3c4b793bfdc476ccbbb39", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 19, + "end_line": 19, + "title": "user", + "sha256": "0a171d978928b2781f3b7b7f28485e6d6ec53e8fe7808f42629ea7375101ec3c", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 20, + "end_line": 20, + "title": "account", + "sha256": "1901d71fbc43e06b5134161854710bf0f653141bc626bf67d95d4cfd3db0e10f", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 21, + "end_line": 21, + "title": "identity", + "sha256": "779546411717fd6156a3dd3a39eb0869c68d36b10b64fff51e2dc4db9031b422", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 22, + "end_line": 22, + "title": "identifier", + "sha256": "53e9132ea78c16e691b6b0e05371a99aed178d52df6d1e48704b43a40f3193cc", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 23, + "end_line": 23, + "title": "scoped identifier", + "sha256": "e4d333b9c4c275397cbeccd5e0b2eed27b457dff23cca482b42a086885cd2578", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 24, + "end_line": 24, + "title": "credential", + "sha256": "c9d2a6c53d2e11f93234cc4fffde742aa82990efc2cb6b83024b929616030248", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 25, + "end_line": 25, + "title": "subject", + "sha256": "904b2af8c84d271ad315098c387b00d51eef6463d3d4343c16469844f65f9cd5", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 26, + "end_line": 26, + "title": "principal", + "sha256": "3ab8b5d536f3e1da3f172f95431751a51786291480592b7e2e784338466657ba", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 27, + "end_line": 27, + "title": "end-user", + "sha256": "74c3cc32b9d4ce44cf2b61a4673ea73073be69d31900f302937110ab74c43c4c", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 28, + "end_line": 28, + "title": "profile", + "sha256": "f332b51b59675a5ce79ed19eb9b6ab8d7bbe4e1d651f56099068a1596669db24", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 29, + "end_line": 29, + "title": "persona", + "sha256": "8815441b1d1f825051d8208b5a126c28d1b0a0cec1dc92fc6550b6a79f38eb2d", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 30, + "end_line": 30, + "title": "agent", + "sha256": "30a826d21d04b01e4de5648711bdd38e1e106bbb25d2ab2f1f611912d0f7b3b1", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 31, + "end_line": 31, + "title": "bot", + "sha256": "827962be82a98f1c17ffb62c4f4cd943a66a753d67e5cca0fc8ef77756e8ffad", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 32, + "end_line": 32, + "title": "service account", + "sha256": "64c7a3372e658872cc40799f62c5c3d7d9a8b319340a8134a829ee0a6f6082b0", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 33, + "end_line": 33, + "title": "machine user", + "sha256": "5012066796bdd788383852ec7bc34a06a2fa82433dac3afbeca5f625f8b8df13", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 34, + "end_line": 34, + "title": "organization", + "sha256": "b3deaa2097bfa8f94206f0d599bf434e202e1a3a72ff5ff0ac556ab9ad00efe3", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 35, + "end_line": 35, + "title": "legal entity", + "sha256": "da327d376e38707f55e5a1fbcdd4dee8f76bfc6cb4ec2e8468a90079f2ca1a5a", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 36, + "end_line": 36, + "title": "customer", + "sha256": "3e7b01c8abe4d58617b4902063eb4f5f14e7cac5da49a8ff778c33f9bc4716a9", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 37, + "end_line": 37, + "title": "vendor", + "sha256": "68a088043e8cb63172b4c57325022708379566e12a9cf605400179c16a4f46b7", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 38, + "end_line": 38, + "title": "subscriber", + "sha256": "3194121265ab0f7be752878e2168006b71c72b9f200f1e5e02aac4f078de5bf4", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 39, + "end_line": 39, + "title": "stripe customer", + "sha256": "925da008d6dd0d1187f038d5bce0a3d6b6d52709672c0c7393f5b538eb65a389", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 40, + "end_line": 40, + "title": "payment method / pm_xxx", + "sha256": "1877175fcb5e0ce79e8d9145afd4ea37c10cbe9b03a4896568e868a2c38ae9ed", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 42, + "end_line": 42, + "title": "pan / cvv / chd", + "sha256": "84eacf96d9ff1a172086a00c1ecf31e94f5b594ee4dce3559e8ccd2525ab6b9c", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 47, + "end_line": 47, + "title": "crm account", + "sha256": "fae0815710a180822daf1af506d5fc59210049f8c5e2382e4094326b64a3e47f", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 48, + "end_line": 48, + "title": "customer account", + "sha256": "86c081e76edc36dd60d4c7c2db34ba23506e1e5b1e174459cd68eb65b913cfa2", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 50, + "end_line": 50, + "title": "commercial relationship", + "sha256": "295a513939a88bc3fe49df82b43a20b0e89409b1969672a9a627fc63e6265f4c", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 52, + "end_line": 52, + "title": "beneficial owner", + "sha256": "5c1d61373f92b79b054fe3d605a5d8171b2af91ebc9b3636f7b07015b3ce85f0", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 53, + "end_line": 53, + "title": "beneficial ownership", + "sha256": "8520301fabb9a30b9055f47f6b8b957636038fe4f6ec4a34761cfd233780d40a", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 54, + "end_line": 54, + "title": "lei", + "sha256": "30a480ef227a05028bea2c34eb48bd0e892095df0f69ab496827932e67578b10", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 55, + "end_line": 55, + "title": "duns", + "sha256": "e0b1fc126792ef64cf0a52bc555df0d32fee966a8a092cfdc3a93020d4feb7d9", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 56, + "end_line": 56, + "title": "uei", + "sha256": "20ba5293b13576bc0a7f5a1abde3a3eed2a056d43e34f2451196b9100e8338a3", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 57, + "end_line": 57, + "title": "company registration number", + "sha256": "837e7698d5f10320661deea52464e849bcfb001472056c75563aded71989c8c4", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 58, + "end_line": 58, + "title": "alei / ibrn", + "sha256": "222c1e86c484f60381795e6ba63bbbd684ce1b81eea5d2452ff3ec5a5bdf1dc3", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 59, + "end_line": 59, + "title": "iso 6523 / icd", + "sha256": "03da1b9755c903ab6c7d865a98c27223f9d7477629602c635394956f3404dc31", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 60, + "end_line": 60, + "title": "legal person", + "sha256": "5138cf572034760b21f365bcae5e73346acf6d88c2f65cee751d6b02454d9766", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 63, + "end_line": 63, + "title": "star rating / review", + "sha256": "3dbb10a8ab536c181da9205e3cfb4fae3031e0fd007fb4bb6205bb532e1959f1", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-evid" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 68, + "end_line": 68, + "title": "arbitration award", + "sha256": "5631838512e0e0b5452b591adc1f4f77f380df18cecf4e6164dab0546207ef67", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-evid" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 69, + "end_line": 69, + "title": "court judgment", + "sha256": "ba21ec0155b991faea17beea69f8fbcaa4489f51e522ced3b2ded31fe06f4c3e", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-evid" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 71, + "end_line": 71, + "title": "control_basis", + "sha256": "7923f00e6a10cdd05fd7b3bc8a5013fc837a36bd1f984fb84fc8f4447e147a7c", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 73, + "end_line": 73, + "title": "fincen id", + "sha256": "f0bfb45e5363934041ff910a44cd0d69b578679f9c22719365fb0319b314fb78", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 74, + "end_line": 74, + "title": "person account", + "sha256": "b75fc9b5ca6ef2146e019e342f8565d138eeefccc4b2ee845f010c835d5567eb", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 75, + "end_line": 75, + "title": "ncage / cage", + "sha256": "cadfb882fc19bda7c60bb8c75e0ed7e2e2b63974037ff07947a8a427d852b9b2", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 78, + "end_line": 78, + "title": "kyc / cip", + "sha256": "489f788d80be6f2e796a116a2338e697145669829f355c121e18975dbbfbf13f", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-evid" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 79, + "end_line": 79, + "title": "crm account", + "sha256": "9b1dcdfbe61b780895d51b439da2dffc0df0df7cc4dfb4d57de7dd3f8eb30d0e", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "family-area", + "itc-ident", + "itc-org" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 80, + "end_line": 80, + "title": "fluid identity", + "sha256": "3c171e79b1f6966812977a4de526300db7dea729ac4bef4f86737575e836d54e", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 82, + "end_line": 82, + "title": "tenant", + "sha256": "8ea48ff21a23148aea6923f844adb270f01af86f334bd9fd2e6642e6ac35dc40", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 83, + "end_line": 83, + "title": "realm", + "sha256": "faaa0b5ee2eee0c243c2eda3a90df392858d974bfc1df02422a8df0b71276980", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 84, + "end_line": 84, + "title": "scope", + "sha256": "05dc1d57cb500d7c30328b063db392cb4e4be19479c2596f739b474e640ec6bb", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 85, + "end_line": 85, + "title": "namespace", + "sha256": "348ff0b2f98a4a7b53947188a958999ec7779c636bb8fcca133075dabe031750", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 86, + "end_line": 86, + "title": "instance", + "sha256": "a091b4ac6ab9f52f953832634e1f942fd000ead687ce46a57d4983fd7e79f33d", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 87, + "end_line": 87, + "title": "project", + "sha256": "329b17d1d24ed30b039ced9d3e3277cb23e49ea59f4c7ac7acf9ddae3e83dfc7", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 88, + "end_line": 88, + "title": "community", + "sha256": "0511a75af9b3a29cc2519527193f01cf70d04c0b0e04546127b14a7bd2ec5c8a", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 89, + "end_line": 89, + "title": "family", + "sha256": "b1494107b59c6ed89546a86eeb073414ee575a2376f3c695ecb23b5c2668e32d", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "family-area", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 90, + "end_line": 90, + "title": "household", + "sha256": "0719bdf791feaaf5a70b1990b2ea38f730312c1addbbdd6562ddb0b7abbb75ed", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "family-area", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 91, + "end_line": 91, + "title": "group", + "sha256": "46830fccca86caeda6623d000dc25708edfbc3fbce2be1d4746a7b4d3482dd43", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 92, + "end_line": 92, + "title": "team", + "sha256": "ad2667febbf25827e07ad34d4f413f4165078eda36f90fccd92361b88bc56737", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 93, + "end_line": 93, + "title": "role", + "sha256": "bf4b3c078725e3a9b4c661c358df673204d21865de9386223c00682de7a76d2a", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 94, + "end_line": 94, + "title": "grant", + "sha256": "ca2c9b2882bd176716d5f40b570f7d142e820881529353bdd9829ca2fff5acfd", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 95, + "end_line": 95, + "title": "member", + "sha256": "a6600f7dd9604883a0c366467ad89a90ceee68aefbe6aca09067ada754baae23", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 96, + "end_line": 96, + "title": "affiliation", + "sha256": "06170379083ad57eb7ec1dee172d3f2e370140f32c1e8b3ccf5a700c3fffdb66", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 97, + "end_line": 97, + "title": "follower", + "sha256": "62256899610e66f10a97b6f7011d52ff02ce79f6d4060c0d403bc8a520f3e6ff", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 98, + "end_line": 98, + "title": "follow", + "sha256": "1c77e34bdf1206d046ef8eee40d4a94393faf67a5af97821834b12b9f9bcea81", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 99, + "end_line": 99, + "title": "owner", + "sha256": "78b48373de87a79fc4d67b68b30f7a16c2fbab573b24ddd44f8cfb13487e6896", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 100, + "end_line": 100, + "title": "administrator", + "sha256": "8325a4edc6753be9dadce60ad0fcfd5b46ad0528e0efc0ea9ad3a8d116a93f76", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 101, + "end_line": 101, + "title": "delegation", + "sha256": "538948038bf8b7c7e6c562238017e8efd2c4d2112e542bc9cb7d1d47d521df09", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 102, + "end_line": 102, + "title": "representation", + "sha256": "1a93d64d4e3f608806754d3889b9655d0083e2f5ce92db14780c8513fbfff419", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 103, + "end_line": 103, + "title": "trust", + "sha256": "3a652a6f5721c7c3616ea4fb93db81e7514538d1f2052eb00cd3333e881dd3c6", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 104, + "end_line": 104, + "title": "claim", + "sha256": "1ce7bcc854285f598ad1927182e0821d7db9e9fb2a09cbd0d7e743549ca2b37e", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 105, + "end_line": 105, + "title": "evidence", + "sha256": "f6a2c13eb05ca9f7299d1e704815b2dbf0a2d0c8ca75a032bc4aaca087b28b86", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-evid" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 106, + "end_line": 106, + "title": "assurance", + "sha256": "130c61dcb0687328ed992999688e1f37c07958e258a96db49787d1d9fce90dad", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 107, + "end_line": 107, + "title": "identifier binding", + "sha256": "384043ffa3353df53a5a4769971853cedccf232fe72d1a8044d1dd3b53cfc378", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 108, + "end_line": 108, + "title": "synonymity", + "sha256": "58d9d36c18fda3e8df9a74af3c2fae1f3103a6f62df39d0b5db951ce3b6fe5e3", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 109, + "end_line": 109, + "title": "weak match", + "sha256": "3f35848a32547aa86fe3ec9e7e755e4fd6392d71ef3d683953df7b08a5c1dd95", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 110, + "end_line": 110, + "title": "strong link", + "sha256": "5f0902c8bed0e10535d0f76427677ac135a5c09b10b223aa49dbe05d8fc6c468", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 111, + "end_line": 111, + "title": "same_as", + "sha256": "9236ea638789b858a465b91a73dfb82c2f91434f04d7fe3bb0bcdfa623c6e951", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 112, + "end_line": 112, + "title": "probably_same_as", + "sha256": "1ce7ba621eeb91881b9be16c1e87ce7a78a2a1dd26a0ff7da82b6d3fa04f2069", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 113, + "end_line": 113, + "title": "linked_to", + "sha256": "33b998acec8a52176199992c4d0f5d1ca9016d586682e8fa5d18dbdd27957181", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 114, + "end_line": 114, + "title": "pseudonym", + "sha256": "01ebfceff32122591e256df20f312f68881ef3e6d4ebfc5738cdfa4cc28d3d69", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 115, + "end_line": 115, + "title": "pairwise subject", + "sha256": "508a529137ad7a0e7f1409063b306cad3bb1f8aa1c9c15f179c21ab657f46d33", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 116, + "end_line": 116, + "title": "relationship tuple", + "sha256": "3cab1bbb2dfc5afd3dcde230e104ddd95e67ccddc46fb2bbcc38f99103a55f49", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 117, + "end_line": 117, + "title": "policy", + "sha256": "13bcf330fb1989abf5ba4d7c673d2c3a646480236f81792abadb74afa660b983", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 118, + "end_line": 118, + "title": "lifecycle state", + "sha256": "b39c636369a3c10a22a75c8c686d145f54addfd5720ae90da49321571406d6c6", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 119, + "end_line": 119, + "title": "subscriber", + "sha256": "778a574609c40787ae9fec045e791faafd3d39b49fd187b3c10bc6dad0133e4c", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 120, + "end_line": 120, + "title": "issuer", + "sha256": "036456fa64e621bcbf2df81938ec5e5bce4af61c757456935846ef3c2c026282", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 121, + "end_line": 121, + "title": "relying party", + "sha256": "36a83f3b965a6b2e71938360eb02a5ed64bd665797952d5f592b535e73cfa436", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 122, + "end_line": 122, + "title": "nameid", + "sha256": "dbe31e5c4483f1b3f8c83c7abe1239137c7da04456f601d8550035a0c308df12", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 123, + "end_line": 123, + "title": "distinguished name", + "sha256": "ac1bda1aaeb885049b4ae754e1a507b1e872321069f4ca1a3fc3617660d90454", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 124, + "end_line": 124, + "title": "externalid", + "sha256": "e1872cf38aa8e72a824036d017710553cf8ea6f990ef05217c2e972e77c6a978", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 125, + "end_line": 125, + "title": "traits", + "sha256": "aadb34d5ce8bc3500c5a4d49641d87b11b5da9a481b27dbe0d436d5c0e95117f", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 126, + "end_line": 126, + "title": "verification method", + "sha256": "ade6d356c8a8d8db36f1991f72e711738d9281166feda19b6bf5a5ef341d2f10", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 127, + "end_line": 127, + "title": "verifiable credential", + "sha256": "10b80fe4d8c1fd5880c5fb3f626bfff061b2fa2457d93bcaeaa9a6c5d27a69d3", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 128, + "end_line": 128, + "title": "holder", + "sha256": "1e57bb144bb8a072a4180be14a8a91f8126c4f958397a8fd62e12c63db8806b6", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 129, + "end_line": 129, + "title": "verifier", + "sha256": "d37d10d4b1113114369aa128754a243e56f9ee71e5f95d5d9f966d75fe94088b", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 130, + "end_line": 130, + "title": "did", + "sha256": "4de4b5bba75e89eb1ad4dc0525dc0eeb3eb1102e26c3535c0e85c41a68a68551", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 131, + "end_line": 131, + "title": "webid", + "sha256": "e08c6ed7932919efd4c8f8ae55161be7a02e983d667cf3359fcff0affde44a1b", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 132, + "end_line": 132, + "title": "data subject", + "sha256": "2aae43d6df259e4678d0a2d27fcf4efd546ecd99201d1a3e573cef845e78a822", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 133, + "end_line": 133, + "title": "pseudonymization", + "sha256": "157015a6434ede26ec98e5b223c0d07e1cbf3f9e791ede4c11b8b2958bb67963", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 134, + "end_line": 134, + "title": "controller", + "sha256": "161324c016daae2806cd837b82beceffd4ea2b3ce981683b5ed39f58132b19e8", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 135, + "end_line": 135, + "title": "tuple (authz)", + "sha256": "89a5e53a0468189c92022352aac36ccf34b62a8a34b49c13241eb5fa91aa830c", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access", + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 136, + "end_line": 136, + "title": "userset", + "sha256": "6ad9832f81b69b4e039e5bb2c0e8751894d408412f573668619adfa74cde2e8c", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-access" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 137, + "end_line": 137, + "title": "derived role", + "sha256": "cbfaa9a627d2d32e194e4301e908fd193eb67c788ac3afad98079ce92e898fce", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 138, + "end_line": 138, + "title": "contextual tuple", + "sha256": "5b1c5f8c2795fc54d61f319bd4c6238538588fa4026e779d0ed615e998133218", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident", + "itc-org", + "itc-access", + "itc-gov", + "itc-evid", + "family-area" + ] + }, + { + "repo": "commerce-canon", + "models": [ + "counterparty" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 139, + "end_line": 139, + "title": "sameas", + "sha256": "be040500605effc4252c681b4b06d22cc0a7f37fbf622b0987690f4f8d39c86a", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 140, + "end_line": 140, + "title": "organizationrole", + "sha256": "ca2eda7a31f21b54ff220456146ef06584ab01844034832e519a9c9c0febf576", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-org" + ] + } + ] + }, + { + "source_path": "terminology/TerminologyInventory.md", + "start_line": 141, + "end_line": 141, + "title": "assurance level change", + "sha256": "1b1531452b8b67df5a400492a351662c05da740832cc507356df0f1414b40c2b", + "destinations": [ + { + "repo": "info-tech-canon", + "models": [ + "itc-ident" + ] + } + ] + } + ] +} diff --git a/infospace/assimilation/canon-federation/extracted-concepts.yaml b/infospace/assimilation/canon-federation/extracted-concepts.yaml new file mode 100644 index 0000000..38db665 --- /dev/null +++ b/infospace/assimilation/canon-federation/extracted-concepts.yaml @@ -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 diff --git a/infospace/assimilation/canon-federation/mappings.yaml b/infospace/assimilation/canon-federation/mappings.yaml new file mode 100644 index 0000000..6f13fc2 --- /dev/null +++ b/infospace/assimilation/canon-federation/mappings.yaml @@ -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 diff --git a/infospace/assimilation/canon-federation/open-questions.md b/infospace/assimilation/canon-federation/open-questions.md new file mode 100644 index 0000000..b3a7c8b --- /dev/null +++ b/infospace/assimilation/canon-federation/open-questions.md @@ -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. diff --git a/infospace/assimilation/canon-federation/proposed-changes.md b/infospace/assimilation/canon-federation/proposed-changes.md new file mode 100644 index 0000000..8b5eb2f --- /dev/null +++ b/infospace/assimilation/canon-federation/proposed-changes.md @@ -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. diff --git a/infospace/assimilation/canon-federation/source-summary.md b/infospace/assimilation/canon-federation/source-summary.md new file mode 100644 index 0000000..73b233f --- /dev/null +++ b/infospace/assimilation/canon-federation/source-summary.md @@ -0,0 +1,13 @@ +# Source summary + +Frozen completed research, not revalidated external specifications. + +- authentication-federation: 4 files. +- authorization-relationships: 4 files. +- commercial-identity: 14 files. +- commercial-subscription: 2 files. +- entity-resolution-privacy: 3 files. +- identity-provisioning: 5 files. +- shared-context: 6 files. +- social-community-graphs: 4 files. +- verifiable-claims: 3 files. diff --git a/infospace/assimilation/canon-federation/source/research/CorpusIndex.md b/infospace/assimilation/canon-federation/source/research/CorpusIndex.md new file mode 100644 index 0000000..47cfa7b --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/CorpusIndex.md @@ -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. diff --git a/infospace/assimilation/canon-federation/source/research/README.md b/infospace/assimilation/canon-federation/source/research/README.md new file mode 100644 index 0000000..e0f0378 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/README.md @@ -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. diff --git a/infospace/assimilation/canon-federation/source/research/ResearchSeed.md b/infospace/assimilation/canon-federation/source/research/ResearchSeed.md new file mode 100644 index 0000000..b85ec4d --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/ResearchSeed.md @@ -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. diff --git a/infospace/assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md b/infospace/assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md new file mode 100644 index 0000000..579d9a8 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md @@ -0,0 +1,129 @@ +# NIST SP 800-63-4 + +## Source Type + +Government guideline. NIST Special Publication 800-63-4, Digital Identity +Guidelines (2025). + +## Domain + +Identity assurance, authentication assurance, federation assurance, and +identity lifecycle. + +## Why This Source Matters + +NIST identity guidance separates identity proofing, authentication assurance, +federation assurance, and lifecycle management. + +NIST 800-63 provides the most explicit assurance-level vocabulary for +separating how strongly an identity is bound to a person, how strongly +authentication occurred, and how federation preserves or degrades assurance. + +## Key Concepts + +- **IAL (Identity Assurance Level)**: confidence that a subscriber is who they + claim to be (IAL1–IAL3). +- **AAL (Authenticator Assurance Level)**: confidence in authentication + mechanism strength (AAL1–AAL3). +- **FAL (Federation Assurance Level)**: confidence in federation protocol and + assertion protection (FAL1–FAL3). +- **Subscriber**: party enrolled with a CSP (credential service provider). +- **Credential Service Provider (CSP)**: issues credentials and performs + identity proofing. +- **Relying Party (RP)**: depends on CSP assertions. +- **Identity Provider (IdP) / Asserting Party (AP)**: federates authentication + to RPs. +- **Verifier**: entity confirming claimant possession of authenticator. +- **Binding**: association between subscriber, identity, and authenticator. +- **Identity proofing**: collection and validation of evidence about a person. +- **Authenticator**: something the subscriber possesses/controls for auth. +- **Federation assertion**: signed statement from IdP to RP about + authentication and attributes. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Subscriber | Enrolled party at CSP; not necessarily named "user." | +| CSP | Provider performing proofing and credential issuance. | +| RP | Consumer of identity/authentication assertions. | +| IAL | Identity proofing strength level. | +| AAL | Authentication event strength level. | +| FAL | Federation protocol/assertion protection level. | +| Claimant | Party attempting authentication. | +| Verifier | Confirms authenticator use. | +| Binding | Link between subscriber identity and authenticator. | +| Supervised remote proofing | IAL2+ proofing with human or tech supervision. | + +## Modeling Assumptions + +- **Identity assurance, authentication, and federation are separable** + dimensions with independent levels. +- **Subscriber is the enrolled entity**, not the legal person directly; binding + connects them. +- **Proofing evidence matters** and should be retained per policy. +- **Federation may preserve or reduce assurance** depending on FAL and + assertion contents. +- **Lifecycle includes enrollment, binding, maintenance, and termination.** +- **Pseudonymous enrollment is allowed** at IAL1 without real-name binding. +- **Agency/customer relationship** is outside the technical model but affects + policy. + +## Identity-Canon Implications + +- NIST **Subscriber** maps to **Account** or enrolled **Identity Record** + bound to **Natural Person** at higher IAL. +- **IAL** maps to **Assurance Level** on Identity Record / Person binding. +- **AAL** maps to **Assurance Level** on authentication event / Credential use. +- **FAL** maps to **Assurance Level** on **Trust Relationship** or federation + assertion. +- **Binding** maps to **Synonymity Assertion** or **Identifier Binding** + between subscriber, person, and authenticator. +- **Identity proofing evidence** maps to **Evidence Source**. +- Reinforces **P7** (synonymity as assertion) and **P8** (preserve evidence). +- Supports S12 (weak match insufficient for IAL2+), S13 (strong link with + verification), S06 (family/guardian proofing). + +## Terminology Conflicts + +- **Subscriber vs. User**: NIST subscriber is enrolled party; apps say user. +- **Identity vs. Subscriber**: NIST separates identity proofing from + subscriber record. +- **Credential vs. Authenticator**: NIST distinguishes credential (issued) + from authenticator (possessed); products conflate. +- **IAL vs. Account trust**: assurance on person binding ≠ account permissions. +- **Federation vs. Synonymity**: federation assertion ≠ same-person claim + across systems. + +## Candidate Canonical Mappings + +| NIST concept | Candidate canonical concept | +| --- | --- | +| Subscriber | Account / enrolled Identity Record | +| CSP / IdP | Issuer Scope + Trust Relationship | +| RP | Relying party Scope | +| IAL | Assurance Level (identity proofing) | +| AAL | Assurance Level (authentication) | +| FAL | Assurance Level (federation) | +| Authenticator | Credential | +| Binding | Identifier Binding / Synonymity Assertion | +| Proofing evidence | Evidence Source | +| Federation assertion | Claim + Credential (signed) | +| Claimant | Actor attempting authentication (projection) | + +## Open Questions + +- Should IAL/AAL/FAL be a unified Assurance Level vocabulary or three + orthogonal dimensions in canon? +- How should pseudonymous IAL1 subscribers map when no Natural Person binding + exists? +- Does guardian-assisted proofing for minors warrant a distinct Relationship + type with assurance caps? +- Should CSP subscriber ID be a Scoped Identifier under CSP Scope? + +## References + +- NIST SP 800-63-4 — https://pages.nist.gov/800-63-4/ +- NIST SP 800-63A (Enrollment and Identity Proofing) — https://pages.nist.gov/800-63-4/sp800-63A.html +- NIST SP 800-63B (Authentication and Lifecycle) — https://pages.nist.gov/800-63-4/sp800-63B.html +- NIST SP 800-63C (Federation and Assertions) — https://pages.nist.gov/800-63-4/sp800-63C.html \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md b/infospace/assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md new file mode 100644 index 0000000..8e64bb1 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md @@ -0,0 +1,125 @@ +# OIDC Core Subject Identifiers + +## Source Type + +Standard. OpenID Connect Core 1.0 incorporating errata; subject identifier +types defined in Core and the Subject Identifier Types specification. + +## Domain + +Authentication, federated identity, token claims, and relying-party-scoped +subject identification. + +## Why This Source Matters + +OpenID Connect subject identifiers, claims, pairwise/public subjects, relying +parties, and issuers. + +OIDC is the dominant federation protocol. Its `sub` claim, issuer (`iss`), +pairwise identifier type, and claim model directly shape synonymity, +account-linking, and scoped-identifier semantics in identity-canon. + +## Key Concepts + +- **Issuer (iss)**: OIDC provider identifier; defines the namespace for + subject identifiers and claims. +- **Subject (sub)**: locally unique identifier for an end-user at the issuer; + stable per issuer and subject type. +- **Claim**: name/value (or structured) assertion about the subject in ID + token or UserInfo response. +- **ID Token**: JWT (or encrypted JWT) asserting authentication event with + `iss`, `sub`, `aud`, `exp`, and optional claims. +- **Relying Party (RP)**: client application consuming tokens from an OP. +- **Pairwise subject identifier**: per-RP (or per-sector) `sub` preventing + cross-RP correlation. +- **Public subject identifier**: same `sub` across RPs at one issuer. +- **Claim Types**: Normal (profile), Aggregated, Distributed. +- **Authentication Context (acr, amr)**: signals about how authentication + was performed. +- **max_age / auth_time**: session freshness requirements. +- **Account linking (implicit)**: RP may maintain local account bound to + `iss` + `sub` pair. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Subject (sub) | Identifier for end-user at issuer; not the human being. | +| Issuer (iss) | URL identifying the OP; scopes subject namespace. | +| End-User | Human participant; OIDC does not model as a separate entity. | +| Relying Party | OAuth client receiving tokens about the subject. | +| Claim | Assertion about subject attributes or authentication event. | +| Pairwise sub | RP-specific subject preventing global correlation. | +| Public sub | Shared subject across RPs at same issuer. | +| ID Token | Signed authentication assertion. | +| UserInfo | Endpoint returning additional claims about subject. | +| aud (audience) | Intended RP client for the token. | + +## Modeling Assumptions + +- **Subject is issuer-scoped identifier**, not a person or account in the RP + system. +- **Issuer defines the namespace**; `iss` + `sub` is globally unique for + identification purposes. +- **Pairwise identifiers assume RP as scope** for correlation boundaries. +- **Claims are assertions** from the issuer, not verified facts in the RP. +- **End-user is implicit**; OIDC does not provision person records. +- **Account linking is RP-local**; protocol does not standardize cross-system + synonymity. +- **Authentication and attributes are bundled** in token delivery. + +## Identity-Canon Implications + +- OIDC **sub** maps to **Scoped Identifier** (pairwise) or **Identifier** + (public) within issuer **Realm/Scope**. +- **iss** maps to issuer **Scope** boundary. +- **End-User** maps to **Natural Person** only by RP inference, not by OIDC + entity. +- RP-local binding of `iss`+`sub` to local record maps to **Synonymity + Assertion** or **Identifier Binding**. +- **Claims** map to **Claim** objects with issuer as **Evidence Source**. +- **Pairwise sub** is canonical evidence for **Privacy-Preserving Link** (S14). +- **acr/amr** inform **Assurance Level** on authentication event. +- Strong support for **P2** (subject ≠ account) and **P3** (scope first-class). + +## Terminology Conflicts + +- **Subject vs. Actor**: OIDC subject is identifier; authorization and social + models use actor as participant. +- **Subject vs. Account**: RP often stores `sub` on a local user account record. +- **End-User vs. User**: OIDC end-user is human; `user` in apps means account. +- **Identity vs. Subject**: developers conflate `sub` with "identity." +- **Pairwise vs. Pseudonym**: pairwise is protocol mechanism; pseudonym is + broader privacy concept. + +## Candidate Canonical Mappings + +| OIDC concept | Candidate canonical concept | +| --- | --- | +| sub | Identifier or Scoped Identifier | +| iss | Realm / Scope (issuer namespace) | +| End-User | Natural Person (inferred, not represented) | +| Claim | Claim | +| ID Token | Credential / signed assertion | +| Pairwise sub | Scoped Identifier | +| Public sub | Identifier | +| iss + sub pair | Identifier Binding in RP scope | +| acr / amr | Assurance Level metadata | +| RP-local account link | Synonymity Assertion (strong, scoped) | +| aud | Scope (intended consumer) | + +## Open Questions + +- Should `iss` + `sub` be a compound Identifier type or a Synonymity key + pair linking to local Account? +- How should sector identifier (pairwise variant) map to Scope hierarchy? +- Does OIDC `sub` rotation on issuer policy change warrant Synonymity + Assertion supersession? +- Should distributed/aggregated claims map to Claim with Evidence Source + references to external issuers? + +## References + +- OpenID Connect Core 1.0 — https://openid.net/specs/openid-connect-core-1_0.html +- OpenID Connect Subject Identifier Types — https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes +- OAuth 2.0 (RFC 6749) — https://datatracker.ietf.org/doc/html/rfc6749 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md b/infospace/assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md new file mode 100644 index 0000000..e731e8a --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md @@ -0,0 +1,128 @@ +# SAML NameID Federation + +## Source Type + +Standard. OASIS SAML 2.0 Core and Profiles for Web Browser SSO; NameID formats +and federation metadata conventions. + +## Domain + +Enterprise federation, single sign-on, assertion semantics, and cross-domain +identity correlation. + +## Why This Source Matters + +SAML 2.0 remains central to enterprise federation. NameID formats, assertion +subject statements, attribute statements, and IdP/SP metadata define how +enterprise identities cross organizational boundaries. + +## Key Concepts + +- **Identity Provider (IdP)**: asserts authentication and attributes about a + subject to service providers. +- **Service Provider (SP)**: consumes assertions and establishes local session. +- **Assertion**: XML security token containing subject, conditions, authn + statements, and attribute statements. +- **Subject / NameID**: identifier for the principal at the IdP; carries + Format attribute defining syntax and semantics. +- **NameID formats**: transient, persistent, emailAddress, X509SubjectName, + kerberos, entity, unspecified, and others. +- **Persistent NameID**: stable, opaque identifier for a principal at an IdP. +- **Transient NameID**: one-time identifier for a single federation session. +- **AttributeStatement**: SAML attributes (mail, eduPersonPrincipalName, group + memberships) about the subject. +- **AuthnStatement**: authentication instant, session index, and context class. +- **AudienceRestriction**: scopes assertion to intended SP entity IDs. +- **Metadata**: XML describing IdP/SP endpoints, certificates, NameID formats, + and supported attributes. +- **Affiliation / discovery**: federations aggregate metadata for trust circles. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Principal | Authenticated entity; identified by NameID in assertion. | +| NameID | Subject identifier chosen by IdP; format determines semantics. | +| Persistent NameID | Long-lived opaque ID stable for principal at IdP. | +| Transient NameID | Ephemeral ID for one session; privacy-preserving. | +| Subject | SAML assertion subject element holding NameID. | +| Attribute | Named property asserted about subject. | +| EntityID | Unique identifier for IdP or SP in metadata. | +| Assertion | Signed statement about authentication and attributes. | +| SessionIndex | Handle for single logout correlation. | +| Audience | Intended SP for assertion consumption. | + +## Modeling Assumptions + +- **NameID is the primary correlation key** between IdP and SP for account + linking. +- **Format determines persistence and privacy**; persistent enables cross- + session linking, transient prevents it. +- **Principal means authenticated subject**, not a pre-provisioned local user. +- **Attributes are asserted**, not authoritative directory records in the SP. +- **Trust is pairwise** between IdP and SP via metadata exchange. +- **Groups may appear as attributes**, not as first-class relationship tuples. +- **Federation operates across organizational boundaries**; each side + maintains its own namespace. + +## Identity-Canon Implications + +- SAML **NameID** maps to **Identifier** or **Scoped Identifier** depending + on format (persistent vs. transient). +- **Persistent NameID** supports **Synonymity Assertion** linking SP local + Account to IdP identifier. +- **Transient NameID** maps to session-scoped **Scoped Identifier** with no + cross-session synonymity. +- **Principal** in assertion maps to **Authenticated Subject** projection. +- **AttributeStatement** attributes map to **Claim** objects. +- **EntityID** maps to **Scope** identifier for IdP/SP. +- **AudienceRestriction** maps to Scope boundary for assertion validity. +- **Attribute-based group membership** maps to **Claim** (group attribute) or + Membership hint, not canonical Group unless provisioned. +- Supports S02 (multi-scope accounts), S13 (strong link via persistent NameID). + +## Terminology Conflicts + +- **Principal vs. Subject**: SAML uses both; principal is authenticated entity, + subject is XML element. +- **Principal vs. Authorization Principal**: SAML principal is auth subject, + not Cedar principal. +- **Persistent vs. Pairwise**: SAML persistent NameID is IdP-wide stable; + OIDC pairwise is RP-specific. +- **NameID vs. emailAddress format**: email as identifier conflates Identifier + with contact attribute. +- **Attribute vs. Claim**: SAML attribute is XML element; canon Claim is + issuer statement — compatible but different syntax. + +## Candidate Canonical Mappings + +| SAML concept | Candidate canonical concept | +| --- | --- | +| NameID (persistent) | Identifier | +| NameID (transient) | Scoped Identifier (session-bound) | +| NameID (emailAddress) | Identifier (with attribute conflation risk) | +| Principal | Authenticated Subject | +| Subject element | Protocol binding for Authenticated Subject | +| AttributeStatement attribute | Claim | +| EntityID (IdP/SP) | Scope identifier | +| Assertion | Credential / signed assertion | +| Audience | Scope boundary | +| SessionIndex | Session correlation reference (projection) | +| SP local account mapping | Synonymity Assertion | + +## Open Questions + +- Should persistent NameID map to strong Synonymity by default, or only after + SP verification (S13)? +- How should eduPerson / SCHAC attribute vocabularies map to Profile vs. Claim? +- Does transient NameID session scope warrant a distinct Lifecycle State on the + Scoped Identifier? +- Should federation metadata trust map to **Trust Relationship** with + certificate Evidence Source? + +## References + +- SAML 2.0 Core — http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf +- SAML 2.0 Profiles — http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf +- SAML NameID Format URIs — http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf (§8.3) +- REFEDS entity categories — https://refeds.org/category \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md b/infospace/assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md new file mode 100644 index 0000000..6c177fc --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md @@ -0,0 +1,125 @@ +# Shared Signals, CAEP, and RISC + +## Source Type + +Standard and profile. OpenID Shared Signals Framework 1.0, CAEP (Continuous +Access Evaluation Profile), and RISC (Risk Incident Sharing and Coordination). + +## Domain + +Security event sharing, session lifecycle, account state propagation, and +continuous access evaluation across federated systems. + +## Why This Source Matters + +OpenID Shared Signals, CAEP, and RISC suggest that canonical identity models +should anticipate dynamic security and lifecycle events. + +Federation is not static. Shared Signals define how issuers push account +compromise, credential change, session revocation, and user profile update +events to relying parties — requiring lifecycle-aware identity modeling. + +## Key Concepts + +- **Shared Signals Framework (SSF)**: transport and envelope for delivering + security events between transmitter and receiver. +- **Transmitter**: entity (typically IdP) sending events about subjects. +- **Receiver**: entity (typically RP) consuming events and updating local state. +- **Subject in event**: identifies the affected party, often by `sub` and `iss` + or equivalent. +- **CAEP events**: session-revoked, token-claims-change, credential-change, + assurance-level-change, and related continuous evaluation signals. +- **RISC events**: account-credential-compromise, account-disabled, + account-enabled, identifier-changed, and recovery-related events. +- **SET (Security Event Token)**: JWT-format event payload. +- **Stream configuration**: receiver registers endpoint; transmitter manages + delivery and retry. +- **Verification**: receivers validate SET signatures from transmitter. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Transmitter | Event source (usually OP/IdP). | +| Receiver | Event consumer (usually RP). | +| SET | Security Event Token (JWT). | +| Subject (event) | Identifies affected user at transmitter. | +| Session revoked | Active sessions should be terminated at receiver. | +| Credential change | Password/key rotation; may require re-auth. | +| Account disabled | Subject account suspended at transmitter. | +| Identifier changed | Subject ID or attribute materially changed. | +| Assurance level change | IAL/AAL/FAL or equivalent changed. | +| Stream | Configured event delivery channel. | + +## Modeling Assumptions + +- **Identity state changes over time** and RPs must react without polling. +- **Subject in events maps to prior federation binding** (`iss`+`sub` or + equivalent). +- **Lifecycle events are issuer-authoritative** for issuer-managed accounts. +- **Receivers maintain local session/account state** that must reconcile with + events. +- **Not all state changes imply synonymity changes**; identifier-changed may + require rebinding. +- **Events are evidence** for downstream state transitions. + +## Identity-Canon Implications + +- SSF events map to **Evidence Source** events triggering **Lifecycle State** + transitions on Account, Session projection, or Synonymity Assertion. +- **Account disabled/enabled** maps to Lifecycle State change on Account or + Identity Record. +- **Credential change** maps to Credential lifecycle event; may invalidate + sessions. +- **Session revoked** affects session projection, not canonical Account. +- **Identifier changed** may require superseding **Identifier Binding** or + Synonymity Assertion with new target. +- **Assurance level change** maps to updated **Assurance Level** metadata. +- Reinforces **P8** (preserve source/evidence) and invariant that lifecycle + applies to relationships and assertions, not only accounts. +- Supports S02 (multi-account lifecycle), S13 (link revocation), federation + scenarios requiring continuous evaluation. + +## Terminology Conflicts + +- **Subject**: event subject is issuer identifier; not authorization subject. +- **Account**: event "account disabled" means issuer-side record; RP may have + separate local account. +- **Session vs. Account**: session revocation ≠ account deletion. +- **Identifier changed vs. Synonymity**: identifier migration is not automatic + same-as merge. +- **Continuous access vs. Authorization**: CAEP informs access evaluation but + is not a policy engine. + +## Candidate Canonical Mappings + +| SSF/CAEP/RISC concept | Candidate canonical concept | +| --- | --- | +| SET event | Evidence Source (event) | +| Transmitter | Issuer Scope | +| Receiver | Relying party Scope | +| Event subject | Identifier reference | +| Account disabled/enabled | Lifecycle State transition | +| Credential change | Credential Lifecycle State | +| Session revoked | Session projection lifecycle | +| Identifier changed | Identifier Binding supersession | +| Assurance level change | Assurance Level update | +| Token claims change | Claim set modification event | + +## Open Questions + +- Should SET event types be enumerated in canon as standard Evidence Source + categories? +- How should identifier-changed events interact with existing Synonymity + Assertions (supersede vs. revoke vs. chain)? +- Should receivers model event processing state as Relationship between + Receiver Scope and Transmitter Scope? +- Are session projections worth a minimal canonical mention given SSF + prevalence? + +## References + +- OpenID Shared Signals Framework 1.0 — https://openid.net/specs/openid-sharedsignals-framework-1_0.html +- OpenID CAEP 1.0 — https://openid.net/specs/openid-caep-1_0.html +- OpenID RISC 1.0 — https://openid.net/specs/openid-risc-1_0.html +- RFC 8417: Security Event Token (SET) — https://datatracker.ietf.org/doc/html/rfc8417 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md b/infospace/assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md new file mode 100644 index 0000000..5b3584c --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md @@ -0,0 +1,114 @@ +# Cedar Principal Action Resource Context + +## Source Type + +Standard and product reference. Cedar policy language (AWS Verified Permissions) +with principal-action-resource-context evaluation model. + +## Domain + +Fine-grained authorization, policy-based access control, and ABAC/RBAC +hybrid evaluation. + +## Why This Source Matters + +Cedar's principal-action-resource-context distinction preserves orthogonality +between identity, action, resource, and request context. + +## Key Concepts + +- **Principal**: entity requesting access; typed entity reference (`User::"alice"`, + `Role::"admin"`). +- **Action**: operation being attempted (`Action::"view"`, `Action::"delete"`). +- **Resource**: entity being accessed (`Document::"report"`). +- **Context**: request-time record with additional attributes (IP, time, + delegated-by). +- **Policy**: Cedar statement allowing or forbidding `(principal, action, resource)` + under conditions. +- **Entity**: typed object in entity store with attributes and parents. +- **Schema**: defines entity types, actions, and attribute shapes. +- **Group / Role entity**: principal may be member of groups; roles as entities. +- **Authorization request**: tuple of principal, action, resource, context + evaluated against policies. +- **Conditional policies**: when-clauses over context and entity attributes. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Principal | Entity requesting access in authorization decision. | +| Action | Verb/operation being authorized. | +| Resource | Target entity of the action. | +| Context | Ephemeral request attributes. | +| Entity | Typed node in entity store with UID and attributes. | +| Policy | Rule governing allow/deny. | +| Schema | Type system for entities and actions. | +| Role | Entity type principals can assume or belong to. | +| Group | Entity type with membership edges. | +| UID | Unique entity identifier string (`Type::"id"`). | + +## Modeling Assumptions + +- **Authorization is a decision over four orthogonal dimensions** (PARTICIPANT, + ACTION, TARGET, CONTEXT). +- **Principals are entity references**, not full identity records. +- **Entity store is separate** from identity directory; may sync from IAM. +- **Roles and groups are entities**, not free-floating strings. +- **Context carries delegation and environmental facts** at decision time. +- **Policies are declarative** and evaluated without imperative code. +- **No social or legal relationship model** beyond entity parent/group links. + +## Identity-Canon Implications + +- Cedar **Principal** maps to **Authorization Principal** projection. +- **Resource** maps to **Authorization Resource** projection. +- **Action** maps to **Authorization Action** projection. +- **Context** maps to request **Context** projection (may carry Delegation + evidence). +- **Entity** in store may represent Account, Group, Role, or Organization + projection — not canonical Actor directly. +- Parent/group entity links parallel **Membership** in authz layer. +- Context `delegatedBy` or custom attributes support S11 (AI agent delegation). +- Strong evidence for **P6** and **P2** (principal ≠ actor ≠ account). + +## Terminology Conflicts + +- **Principal vs. Actor**: Cedar principal is decision participant; actor is + conceptual entity. +- **Principal vs. Subject**: OIDC subject is identifier; Cedar principal is + typed entity UID. +- **Role**: Cedar Role entity vs. IAM role vs. social role. +- **Group**: Cedar group entity vs. LDAP group vs. community. +- **Entity**: Cedar entity vs. canon Entity family (actor layer). + +## Candidate Canonical Mappings + +| Cedar concept | Candidate canonical concept | +| --- | --- | +| Principal | Authorization Principal | +| Resource | Authorization Resource | +| Action | Authorization Action | +| Context | Request context projection | +| Entity (User) | Authorization Principal (Account projection) | +| Entity (Group) | Group (authz projection) | +| Entity (Role) | Role (authorization projection) | +| Policy | Authorization Policy (downstream artifact) | +| Schema | Authorization schema (downstream) | +| parent relation | Membership/inheritance (authz projection) | +| Context.delegatedBy | Delegation Relationship (context reference) | + +## Open Questions + +- Should canon define a minimal Context projection schema for delegation and + assurance attributes? +- How should Cedar User entities map to Account vs. Service Account vs. + Artificial Agent? +- Are Cedar Role entities always authorization projections, or can they mirror + canonical Role relationships? +- Should entity UID format be standardized in downstream recommendations? + +## References + +- Cedar policy language — https://www.cedarpolicy.com/ +- Cedar schema format — https://www.cedarpolicy.com/policies/syntax-schema.html +- AWS Verified Permissions — https://docs.aws.amazon.com/verifiedpermissions/ \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md b/infospace/assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md new file mode 100644 index 0000000..a577419 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md @@ -0,0 +1,114 @@ +# Cerbos ABAC Derived Roles + +## Source Type + +Product documentation and open-source implementation reference for Cerbos +policy decision point with derived roles and attribute-based conditions. + +## Domain + +Policy-based authorization, attribute-driven role derivation, and resource-centric +access control. + +## Why This Source Matters + +Cerbos combines resource policies, principal attributes, and derived roles — +a pattern common in SaaS where permissions depend on both identity attributes +and resource ownership context. + +## Key Concepts + +- **Principal**: subject of authorization request with `id` and `roles` plus + optional attributes. +- **Resource**: target with `kind`, `id`, and attributes (owner, department, + classification). +- **Action**: operation requested on resource. +- **Policy**: YAML/JSON rules binding roles and conditions to allow/deny/effect. +- **Derived roles**: dynamically computed roles from principal + resource + attributes (e.g., `owner` when `principal.id == resource.attr.owner`). +- **Static roles**: assigned roles on principal at request time. +- **Condition**: CEL expression over principal, resource, and request metadata. +- **Scope**: policy namespace for multi-tenant isolation (`scope` field). +- **AuxData**: JWT claims or external data enriching principal at check time. +- **Effect**: ALLOW, DENY, or conditional variants with rule ordering. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Principal | Requesting party with id, roles, attributes. | +| Resource | Entity with kind, id, and attributes. | +| Derived role | Role computed from attribute matching rules. | +| Static role | Pre-assigned role on principal. | +| Policy | Declarative allow/deny rules. | +| Scope | Tenant or environment partition for policies. | +| Condition | Boolean expression over request context. | +| AuxData | Supplemental principal data (e.g., JWT). | +| kind | Resource type discriminator. | +| attr | Attribute bag on principal or resource. | + +## Modeling Assumptions + +- **Authorization is resource-centric** with policies attached to resource kinds. +- **Roles can be derived at evaluation time** from attribute equality or + relationships encoded in attributes. +- **Principal attributes may come from JWT** or external identity system. +- **Ownership is often modeled as resource attribute**, not explicit relationship. +- **Scope provides tenant isolation** for policy sets. +- **No graph traversal** for permissions; derivation is attribute-based. +- **Identity system supplies principal id and roles**; Cerbos does not store + identity records. + +## Identity-Canon Implications + +- Cerbos **Principal** maps to **Authorization Principal** projection. +- **Resource** maps to **Authorization Resource** projection. +- **Derived role** (e.g., owner) should trace to canonical **Ownership + Relationship** or **Membership** when possible, not only attribute equality. +- Encoding `resource.attr.owner = principal.id` collapses relationship into + attribute — canon should prefer explicit Relationship with authz projection. +- **Scope** maps to **Scope** / **Tenant** for policy partition. +- **AuxData JWT claims** map to **Claim** inputs to authorization projection. +- Supports S05 (admin roles), S10 (service principal attributes), but risks + hiding relationships in attributes (tension with **P5**). + +## Terminology Conflicts + +- **Principal vs. User**: Cerbos principal id often equals user id from app DB. +- **Owner**: derived role "owner" vs. Ownership Relationship vs. resource + attribute. +- **Role**: derived role vs. static IAM role vs. canonical Role relationship. +- **Scope vs. Tenant**: Cerbos scope is policy namespace; may not equal tenant. +- **Attributes vs. Profile**: principal attributes overlap with profile fields. + +## Candidate Canonical Mappings + +| Cerbos concept | Candidate canonical concept | +| --- | --- | +| Principal | Authorization Principal | +| Resource | Authorization Resource | +| Action | Authorization Action | +| Static role | Role (authorization projection) | +| Derived role | Role derived from Relationship (preferred) or attribute rule | +| Policy | Authorization Policy (downstream) | +| Scope | Scope / Tenant (policy partition) | +| Principal attributes | Profile/Claim inputs to projection | +| Resource attributes | Resource metadata + Ownership hints | +| AuxData (JWT) | Claim + Authenticated Subject context | +| Condition | Request context projection | + +## Open Questions + +- Should canon explicitly discourage encoding Ownership as resource attribute + without a backing Relationship? +- How should derived roles from group membership sync with canonical Membership + edges? +- Does Cerbos scope map 1:1 to Tenant, or also to Application Scope? +- Should JWT AuxData be documented as standard Authenticated Subject → + Principal projection path? + +## References + +- Cerbos documentation — https://docs.cerbos.dev/ +- Cerbos derived roles — https://docs.cerbos.dev/cerbos/latest/policies/derived_roles +- Cerbos scopes — https://docs.cerbos.dev/cerbos/latest/policies/scope_policy \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md b/infospace/assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md new file mode 100644 index 0000000..f572249 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md @@ -0,0 +1,111 @@ +# OpenFGA Modeling + +## Source Type + +Product documentation and open-source implementation reference for OpenFGA +authorization modeling (Zanzibar-inspired). + +## Domain + +Relationship-based access control modeling, authorization schema design, and +multi-tenant permission systems. + +## Why This Source Matters + +OpenFGA provides a concrete, documented modeling language for Zanzibar-style +relationship tuples with authorization models, stores, and checks. + +## Key Concepts + +- **Authorization model**: declarative schema of types, relations, and + permission definitions. +- **Type definition**: object type with relations and optional `define` rules. +- **Relation**: named edge on a type; may allow direct assignment or computed + rules. +- **Define / rewrite rules**: union (`+`), intersection, exclusion, and + inheritance (`from relation`). +- **Tuple**: `user:type#relation@object:type` stored fact. +- **Userset**: indirect reference such as `user:anne#member@group:engineering`. +- **Store**: isolated tuple set with its own model. +- **Check / ListObjects / ListUsers**: query APIs. +- **Contextual tuples**: ephemeral tuples supplied at check time. +- **Conditions**: CEL-based contextual rules on relations (newer versions). + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| User (in tuple) | Subject identifier in `user:` namespace. | +| Object | Entity in `object:` namespace with type. | +| Relation | Named permission edge on a type. | +| Type | Schema class for objects (document, folder, organization). | +| Model | Collection of type definitions. | +| Store | Isolated authorization dataset. | +| define | Computed relation rule. | +| from | Inheritance from related object's relation. | +| contextual tuple | Runtime-only tuple for conditional checks. | + +## Modeling Assumptions + +- **Model-first design**: relations are declared in schema before tuples are written. +- **User and object IDs are opaque strings**; no embedded identity semantics. +- **Organization/tenant patterns** are modeled as types (e.g., `organization`, + `tenant`) with `member`, `admin` relations. +- **Inheritance chains** (folder contains document) are common modeling pattern. +- **Store isolation** provides multi-tenant authorization separation. +- **Identity management is external**; OpenFGA consumes identifiers. +- **Permissions are computed**, not stored as standalone grants. + +## Identity-Canon Implications + +- OpenFGA aligns with Zanzibar mappings; adds explicit **authorization model** + as schema artifact (downstream, not canonical). +- Type definitions like `organization#member` parallel **Organization** + + **Membership Relationship** but in authz projection. +- **Store** maps to **Authorization Domain** Scope or tenant-scoped authz partition. +- `user:` prefix in tuples maps to **Authorization Principal** identifier. +- Contextual tuples support request-time **Delegation** context without + persisting relationship. +- Model examples for parent-child org hierarchies support S03, S04, S05. +- Reinforces **P6**: tuples are projections from actors/relationships. + +## Terminology Conflicts + +- **User**: OpenFGA `user:` is tuple subject prefix, not human or account. +- **Organization type**: authz type ≠ Organization collective actor unless + explicitly linked. +- **Member relation**: authz member ≠ community member without model alignment. +- **Store vs. Tenant**: store is authz isolation; tenant is broader scope. +- **Permission vs. Relation**: permissions are computed from relations; products + often say "permission" for relation name. + +## Candidate Canonical Mappings + +| OpenFGA concept | Candidate canonical concept | +| --- | --- | +| Tuple | Relationship Tuple (authorization projection) | +| user: (subject) | Authorization Principal | +| object: (entity) | Authorization Resource | +| Relation | Relationship type (authz-implied) | +| Type definition | Authorization schema (downstream) | +| Store | Authorization Domain Scope | +| define/from rules | Authorization derivation (non-canonical) | +| organization#member | Membership Relationship (projection) | +| organization#admin | Administration Relationship (projection) | +| contextual tuple | Delegation context (ephemeral) | + +## Open Questions + +- Should canon document standard OpenFGA type patterns (org/team/resource) as + downstream recommendations only? +- How should principal identifiers be aligned with Account IDs vs. Authenticated + Subject `sub` values? +- Do conditional (CEL) relations require canonical Context as a first-class + projection? +- Should one Store always map 1:1 to a Tenant Scope? + +## References + +- OpenFGA documentation — https://openfga.dev/docs +- OpenFGA modeling guide — https://openfga.dev/docs/modeling +- OpenFGA configuration language — https://openfga.dev/docs/configuration-language \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md b/infospace/assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md new file mode 100644 index 0000000..9d52912 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md @@ -0,0 +1,111 @@ +# Google Zanzibar ReBAC + +## Source Type + +Architecture pattern and research paper. Google Zanzibar (2019) defines +relationship-based access control at global scale. + +## Domain + +Relationship-based authorization, permission inheritance, and large-scale +access control graphs. + +## Why This Source Matters + +Zanzibar/OpenFGA-style relationship tuples are especially close to what +identity-canon needs for memberships, ownership, representation, delegation, +and tenant administration. + +Zanzibar is the reference architecture for storing authorization facts as +subject-relation-object tuples with computed permission expansion. + +## Key Concepts + +- **Relation tuple**: `object#relation@subject` or `object#relation@subject#subject_relation`. +- **Object**: typed entity with namespace and ID (e.g., `document:readme`). +- **Subject**: user, group, or object acting through a relation. +- **Relation**: named edge type on an object type (owner, editor, viewer, member). +- **Userset rewrite**: computed relations via union, intersection, exclusion, + and arrow operators (e.g., parent->owner). +- **Namespace configuration**: schema defining object types, relations, and + rewrite rules. +- **Check API**: evaluate whether subject has relation to object. +- **Expand API**: enumerate subjects with relation to object. +- **zookie**: consistency token for read-after-write semantics. +- **Group as subject**: usersets allow group-like indirection in tuples. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Tuple | Stored authorization fact. | +| Object | Resource or entity being authorized. | +| Subject | Actor or userset granted a relation. | +| Relation | Named permission edge on object type. | +| Userset | Indirect subject reference via relation chain. | +| Namespace | Schema for object types and relations. | +| Check | Boolean permission query. | +| Expand | Enumerate authorized subjects. | +| owner / editor / viewer | Common relation names (deployment-specific). | +| parent relation | Hierarchical inheritance via rewrite rules. | + +## Modeling Assumptions + +- **Authorization facts are relationships**, not role assignments on users alone. +- **Subjects and objects are typed strings**, not rich identity records. +- **Inheritance is computed** from tuple graph via rewrite rules. +- **Identity provisioning is external**; Zanzibar stores authorization state only. +- **Groups are modeled as objects** with member relations, not as separate IAM groups. +- **Consistency matters** for distributed reads (zookie tokens). +- **No canonical person model**; subject IDs are opaque. + +## Identity-Canon Implications + +- Zanzibar **tuple** maps to **Relationship Tuple** (authorization projection). +- **Object** maps to **Authorization Resource** projection. +- **Subject** maps to **Authorization Principal** projection. +- **Relation** maps to typed **Relationship** with authorization implication. +- **Namespace** maps to **Authorization Domain** Scope. +- **Userset rewrite** is authorization engine logic, not canonical identity. +- Membership tuples (`group:eng#member@user:alice`) parallel **Membership + Relationship** but live in authz layer. +- Supports S05 (admin delegation), S08 (moderator relations), S10 (service + account acting for org via tuple). + +## Terminology Conflicts + +- **Subject**: Zanzibar subject is authz participant; OIDC subject is identifier. +- **Object**: Zanzibar object is authz resource; grammar object ≠ domain object. +- **Relation vs. Relationship**: Zanzibar relation is permission edge; canon + Relationship is broader (social, legal, operational). +- **Member**: Zanzibar member relation on group object ≠ social membership. +- **User**: Zanzibar user ID is opaque; no person/account distinction. + +## Candidate Canonical Mappings + +| Zanzibar concept | Candidate canonical concept | +| --- | --- | +| Relation tuple | Relationship Tuple (authorization projection) | +| Object | Authorization Resource | +| Subject | Authorization Principal | +| Relation name | Relationship type (authz-implied) | +| Namespace config | Authorization Domain Scope | +| Group object + member | Group + Membership (authz projection) | +| Userset rewrite | Authorization engine derivation (non-canonical) | +| zookie | Consistency metadata (operational) | + +## Open Questions + +- Should canonical Membership Relationship be shared between identity and + authz layers, or always projected into tuples? +- How should representation/delegation map to Zanzibar relations vs. identity-layer + Representation Relationship? +- Should object namespace prefixes map to Scope identifiers? +- When does a social Following relationship warrant an authz tuple vs. remain + identity-only? + +## References + +- Google Zanzibar paper — https://research.google/pubs/pub48190/ +- Zanzibar ACL language (related) — referenced in paper §2 +- OpenFGA (Zanzibar-inspired OSS) — https://openfga.dev/docs \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md new file mode 100644 index 0000000..c214f63 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md @@ -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` \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md new file mode 100644 index 0000000..298de1c --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.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. \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md new file mode 100644 index 0000000..79e0d8b --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md @@ -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. \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md new file mode 100644 index 0000000..0cc7cde --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md @@ -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) \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md new file mode 100644 index 0000000..9b2aed8 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md @@ -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` \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md new file mode 100644 index 0000000..4ede13b --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.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 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md new file mode 100644 index 0000000..6e157bb --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md @@ -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 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md new file mode 100644 index 0000000..7953771 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md @@ -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 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md new file mode 100644 index 0000000..8994564 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md @@ -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 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md new file mode 100644 index 0000000..feae2b0 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md @@ -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 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md new file mode 100644 index 0000000..2aacb21 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md @@ -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` \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md new file mode 100644 index 0000000..ceaf850 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.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` \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md new file mode 100644 index 0000000..b3cdfc0 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.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` \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md b/infospace/assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md new file mode 100644 index 0000000..6a46bdb --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.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/ \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md b/infospace/assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md new file mode 100644 index 0000000..2cbafaa --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md @@ -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/ \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md b/infospace/assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md new file mode 100644 index 0000000..fb37591 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md @@ -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 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md b/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md new file mode 100644 index 0000000..386a915 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md @@ -0,0 +1,109 @@ +# Deterministic vs Probabilistic Matching + +## Source Type + +Academic and industry practice. Entity resolution, record linkage, and +duplicate detection literature plus operational MDM patterns. + +## Domain + +Entity resolution, record linkage, duplicate detection, and account matching +confidence. + +## Why This Source Matters + +Entity resolution literature distinguishes deterministic keys from probabilistic +matching — the foundation for weak vs. strong synonymity modeling. + +## Key Concepts + +- **Deterministic matching**: records match when agreed key fields are equal + (exact email, government ID, OIDC `iss`+`sub`). +- **Probabilistic matching**: match score from weighted field similarity + (Fellegi-Sunter, Jaro-Winkler, ML classifiers). +- **Record linkage**: identifying records across datasets referring to same + entity. +- **Blocking**: reduce comparison space by bucketing on partial keys. +- **Match threshold**: score above which records are linked or flagged. +- **False positive / false negative tradeoff**: precision vs. recall in linking. +- **Golden record / survivor**: MDM pattern selecting canonical merged record. +- **Non-destructive link**: associate records without merge (preferred in modern MDM). +- **Human review queue**: ambiguous matches escalated for operator decision. +- **Master data management (MDM)**: operational discipline around entity resolution. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Deterministic match | Equality on predefined key fields. | +| Probabilistic match | Scored similarity above threshold. | +| Record linkage | Cross-dataset entity correspondence. | +| Blocking key | Partial key for candidate pair generation. | +| Match score | Confidence metric for probable same entity. | +| Duplicate | Records hypothesized to refer to same entity. | +| Merge | Combine records into one (destructive). | +| Link | Associate records preserving sources (non-destructive). | +| Survivor record | Chosen primary after merge. | +| Quarantine | Hold ambiguous matches for review. | + +## Modeling Assumptions + +- **Same entity is hypothesis until verified** in probabilistic approaches. +- **Deterministic rules are domain-specific** (no universal golden key). +- **Merge destroys provenance** unless carefully audited — increasingly avoided. +- **Confidence is continuous or banded** (weak/medium/strong). +- **Source system identity must be preserved** for compliance and undo. +- **Human review is part of high-assurance linking.** +- **Privacy regulations constrain** which fields can be matched. + +## Identity-Canon Implications + +- Deterministic match maps to **strong Synonymity Assertion** when keys are + authoritative (S13). +- Probabilistic match maps to **weak Synonymity Assertion** with confidence + score and method (S12). +- **Link without merge** is the canonical preferred pattern (**P7**). +- **Match score** maps to confidence/strength on Synonymity Assertion. +- **Blocking/method** maps to Evidence Source metadata. +- **Quarantine** maps to Lifecycle State `proposed` on assertion. +- **Golden record** is downstream MDM pattern; canon should not require merge. +- **Human review** maps to Evidence Source (operator decision). + +## Terminology Conflicts + +- **Duplicate vs. Synonymity**: duplicates imply merge; synonymity allows coexistence. +- **Match vs. Link**: industry uses interchangeably; canon distinguishes strength. +- **Entity vs. Actor**: resolution literature says entity; canon prefers Actor target. +- **Identity vs. Record**: matching is between records, not persons directly. +- **Deterministic vs. Strong**: deterministic can still be wrong if key is shared + (shared email). + +## Candidate Canonical Mappings + +| Entity resolution concept | Candidate canonical concept | +| --- | --- | +| Deterministic match | Strong Synonymity Assertion | +| Probabilistic match | Weak Synonymity Assertion | +| Match score | Confidence / strength metadata | +| Link (non-destructive) | Synonymity Assertion | +| Merge | Downstream anti-pattern (avoid) | +| Blocking key | Evidence Source method | +| Review queue | Lifecycle State `proposed` | +| Source record ID | Identifier | +| Golden record | Downstream projection only | +| False positive handling | Revocation / supersession of assertion | + +## Open Questions + +- What confidence bands (weak/medium/strong) should canon standardize? +- Which deterministic keys are authoritative per source family (OIDC iss+sub, + persistent SAML NameID, verified email)? +- Should probabilistic matchers be required to store feature-level Evidence Source? +- How should shared-attribute false positives (family email) be classified? + +## References + +- Fellegi-Sunter model (1969) — foundational probabilistic record linkage +- Christen, "Data Matching" (2012) — entity resolution textbook +- NIST SP 800-63A evidence requirements — https://pages.nist.gov/800-63-4/sp800-63A.html +- MDM Institute duplicate management practices — industry reference \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md b/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md new file mode 100644 index 0000000..2fe20f9 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md @@ -0,0 +1,114 @@ +# GDPR Pseudonymization and Privacy + +## Source Type + +Regulatory guidance. EU GDPR (Regulation 2016/679) Article 4(5) and Recital 26; +EDPB guidance on identifiability, anonymization, and data subject rights. + +## Domain + +Privacy regulation, pseudonymization, identifiability, data minimization, and +lawful basis for identity processing. + +## Why This Source Matters + +GDPR pseudonymization and identifiability concepts affect how canonical models +should represent privacy-limited links, scoped identifiers, and correlation risk. + +## Key Concepts + +- **Personal data**: information relating to identified or identifiable natural + person. +- **Identifiable person**: can be identified directly or indirectly by reasonable + means. +- **Pseudonymization (Art. 4(5))**: processing personal data so it cannot be + attributed to a subject without additional information kept separately. +- **Anonymization**: irreversible de-identification; data no longer personal. +- **Data subject**: identified or identifiable natural person. +- **Controller / Processor**: roles responsible for processing personal data. +- **Purpose limitation**: data used for specified, explicit, legitimate purposes. +- **Data minimization**: adequate, relevant, limited to necessary. +- **Right of access / erasure**: data subject rights affecting linked records. +- **Additional information**: key held separately to re-identify pseudonymous data. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Personal data | Data about identifiable natural person. | +| Pseudonymization | Reversible de-identification with separate key. | +| Anonymization | Irreversible; no longer personal data (if effective). | +| Data subject | Natural person the data relates to. | +| Identifiable | Reasonably linkable to person. | +| Additional information | Re-identification key stored separately. | +| Controller | Determines purposes and means of processing. | +| Processing | Any operation on personal data. | +| Erasure | Delete personal data (right to be forgotten). | +| Profiling | Automated evaluation of personal aspects. | + +## Modeling Assumptions + +- **Pseudonymization is not anonymization**; data may remain personal. +- **Separate storage of additional information** is required for pseudonymization. +- **Scope and access control on keys** determine correlation risk. +- **Linking pseudonymous records across purposes** may increase identifiability. +- **Legal basis and purpose** govern whether linking is permissible. +- **Erasure requests** may require breaking links or deleting assertions. +- **Regulatory role (controller)** is organizational, not purely technical. + +## Identity-Canon Implications + +- **Pseudonymous Identifier** and **Scoped Identifier** map to pseudonymization + techniques (pairwise sub, hashed email, internal IDs). +- **Privacy-limited Synonymity Assertion** must record privacy classification + and scope (S14). +- **Additional information** (re-identification key) maps to separately secured + **Evidence Source** or **Credential** with strict Scope access. +- **Data subject** maps to **Natural Person** with privacy rights overlay + (downstream policy, not canon legal advice). +- **Erasure** maps to Lifecycle State transitions: revoke assertions, sever + bindings, archive with legal exceptions noted downstream. +- Pairwise OIDC, tenant-local subjects, and restricted persona links are + technical pseudonymization patterns aligned with GDPR concepts. +- Reinforces visibility of privacy constraints on relationships (**P8**, S14 checks). + +## Terminology Conflicts + +- **Pseudonym vs. Pseudonymization**: pseudonym is identifier; pseudonymization + is processing technique. +- **Anonymous vs. Pseudonymous**: often conflated in product marketing. +- **Identity vs. Personal data**: not all identifiers are personal data in all + contexts. +- **Deletion vs. Revocation**: erasure may require more than assertion revocation. +- **Subject**: GDPR data subject vs. OIDC/SAML subject. + +## Candidate Canonical Mappings + +| GDPR concept | Candidate canonical concept | +| --- | --- | +| Data subject | Natural Person (privacy overlay) | +| Pseudonymization | Processing pattern on Identifier / Profile | +| Pseudonymous identifier | Scoped Identifier / Pseudonymous Identifier | +| Additional information | Separately secured Evidence Source / key | +| Purpose limitation | Scope + policy metadata on processing | +| Cross-system link | Synonymity Assertion (privacy classification required) | +| Erasure request | Lifecycle State + assertion revocation | +| Identifiability risk | Privacy classification on links | +| Controller | Organization actor (downstream legal role) | +| Anonymized dataset | Out of scope for personal identity linking | + +## Open Questions + +- Should canon include a standard `privacy_classification` enum for assertions? +- How should erasure of one account affect Synonymity Assertions touching other + accounts (S02)? +- Does pseudonymization key storage warrant a canonical secured Scope type? +- Should identifiability review be documented as operator workflow in downstream + recommendations only? + +## References + +- GDPR Article 4(5) pseudonymization — https://gdpr-info.eu/art-4-gdpr/ +- GDPR Recital 26 on identifiability — https://gdpr-info.eu/recitals-novo/26/ +- EDPB Guidelines on identifiability (various) — https://edpb.europa.eu/ +- ISO/IEC 20889 privacy enhancing data de-identification terminology \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md b/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md new file mode 100644 index 0000000..5dc38d8 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md @@ -0,0 +1,106 @@ +# Synonymity Assertions + +## Source Type + +Concept synthesis from identity-canon ResearchSeed, entity resolution practice, +federation account linking, and semantic web `sameAs` patterns. + +## Domain + +Identity linking, scoped equivalence, account linking, and non-destructive record +association. + +## Why This Source Matters + +Synonymity assertions are the identity-canon-native model for linking records +without merge — synthesizing federation binding, entity resolution, and +semantic equivalence patterns. + +## Key Concepts + +- **Synonymity assertion**: scoped, evidenced claim that two or more identifiers, + records, or actors refer to the same target for a stated purpose. +- **Relation type**: `same_as`, `probably_same_as`, `linked_to`, `represents`, + `controls`, `acts_for` (from ResearchSeed). +- **Strength**: weak, medium, strong, authoritative bands. +- **Scope**: namespace, tenant, relying party, or purpose boundary limiting + assertion validity. +- **Evidence**: verification event, issuer signature, operator review, import + job output. +- **Source system**: system that created or maintains the assertion. +- **Lifecycle**: proposed, active, revoked, expired, superseded. +- **Privacy classification**: controls visibility and correlation risk. +- **Non-merge invariant**: linked records retain independent identity and provenance. +- **Supersession chain**: new assertion replaces old when identifiers change. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Synonymity | Sameness or equivalence under conditions. | +| Assertion | Explicit modeled statement, not implicit merge. | +| same_as | High-confidence equivalence. | +| probably_same_as | Probabilistic equivalence. | +| linked_to | Operational convenience link. | +| represents | One record represents another (controller, profile). | +| Scope | Boundary limiting assertion meaning. | +| Strength | Confidence band. | +| Revocation | Assertion no longer valid. | +| Supersession | New assertion replaces prior. | + +## Modeling Assumptions + +- **Equivalence is contextual**, not universal. +- **Multiple assertions can coexist** for different scopes and purposes. +- **Conflicting assertions possible**; require review workflow. +- **Downstream systems consume assertions** according to their assurance needs. +- **Privacy-limited assertions** must not leak across scopes (S14). +- **Federation bindings are synonymity assertions** (`iss`+`sub` → local account). +- **sameAs on web is weak by default** unless corroborated. + +## Identity-Canon Implications + +- Synonymity Assertion is a **first-class Relationship** class in canon. +- Recommended fields align with ResearchSeed and ConceptualModel invariants. +- OIDC RP binding, SAML persistent NameID mapping, SCIM `externalId` + correlation, and entity-resolution matches all project into Synonymity + Assertions with appropriate strength. +- Supports all linking scenarios: S12 (weak), S13 (strong), S14 (privacy-limited). +- **P7** is the governing principle; merge is downstream exception only. +- Revocation from RISC/SSF events should update assertion Lifecycle State. + +## Terminology Conflicts + +- **Link vs. Merge**: products say "linked accounts" after merge. +- **sameAs vs. same_as**: semantic web informal vs. canon typed relation. +- **Account linking vs. Identity linking**: may target accounts or identifiers. +- **Alias vs. Synonymity**: alias is presentation; synonymity is assertion. +- **Duplicate resolution vs. Synonymity**: MDM duplicate implies survivor selection. + +## Candidate Canonical Mappings + +| Practice / source pattern | Candidate canonical concept | +| --- | --- | +| OIDC iss+sub → local user | Strong Synonymity Assertion (scoped) | +| SAML persistent NameID map | Strong Synonymity Assertion | +| Probabilistic duplicate score | Weak Synonymity Assertion (`probably_same_as`) | +| Operator-verified link | Strong Synonymity Assertion (authoritative) | +| Pairwise sub RP binding | Privacy-limited Synonymity Assertion | +| SCIM externalId correlation | Identifier Binding / medium Synonymity | +| schema.org sameAs | Weak Synonymity Assertion (caution) | +| DID equivalentId | Method-dependent Synonymity | +| VC subject DID binding | Strong Synonymity Assertion with cryptographic evidence | + +## Open Questions + +- Should `linked_to` remain distinct from `same_as` for operational vs. semantic links? +- What minimum field set is mandatory for all Synonymity Assertions (see OpenQuestions)? +- How should conflicting assertions be represented (priority, review state)? +- Should privacy classification be enum or policy reference? + +## References + +- identity-canon ResearchSeed.md — synonymity assertion fields +- identity-canon ConceptualModel.md — identity linking model +- OIDC account linking practice — https://openid.net/specs/openid-connect-core-1_0.html +- W3C VC subject identification — https://www.w3.org/TR/vc-data-model-2.0/ \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md b/infospace/assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md new file mode 100644 index 0000000..5925c23 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md @@ -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 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md b/infospace/assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md new file mode 100644 index 0000000..a946925 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md @@ -0,0 +1,130 @@ +# LDAP RFC 4519 and inetOrgPerson RFC 2798 + +## Source Type + +Standard. RFC 4519 defines LDAP attribute types and object classes; RFC 2798 +defines the `inetOrgPerson` auxiliary object class for Internet person entries. + +## Domain + +Directory services, enterprise identity records, and hierarchical naming. + +## Why This Source Matters + +LDAP directory schema, RFC 4519 attribute/object class vocabulary, and +inetOrgPerson RFC 2798. + +LDAP remains the structural backbone of many enterprise directories. Its +distinguished names, organizational units, and groupOfNames semantics +precede and often underpin SCIM and IAM product models. + +## Key Concepts + +- **Directory Information Tree (DIT)**: hierarchical namespace of entries + identified by Distinguished Names (DNs). +- **Entry**: a collection of attribute type/value pairs with one structural + object class and optional auxiliary object classes. +- **Distinguished Name (DN)**: unique identifier within a directory; composed + of Relative Distinguished Names (RDNs) such as `cn`, `ou`, `dc`. +- **inetOrgPerson**: auxiliary object class for person entries with `cn`, + `sn`, `mail`, `uid`, `employeeNumber`, and related attributes. +- **organizationalUnit (ou)**: container for organizational structure. +- **groupOfNames / groupOfUniqueNames**: group entries with `member` or + `uniqueMember` attributes referencing member DNs. +- **posixAccount / posixGroup**: UNIX-oriented account and group semantics + with `uid`, `gid`, `homeDirectory`, and `memberUid`. +- **Attribute syntax and matching rules**: typed attributes (DirectoryString, + IA5String, JPEG) with defined comparison semantics. +- **Referrals and aliases**: indirection for distributed or aliased entries. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| person / inetOrgPerson | Directory entry representing a human; attributes, not a login session. | +| uid | User identifier string; often login name in POSIX contexts. | +| cn (commonName) | Display or legal name component of DN. | +| mail | Email address attribute; may be multi-valued. | +| employeeNumber | Workforce identifier assigned by employer. | +| ou (organizationalUnit) | Structural container in the DIT; department or division. | +| dc (domainComponent) | DNS-domain component in DN; defines directory partition. | +| member / uniqueMember | DN reference from a group entry to a member entry. | +| groupOfNames | Group requiring at least one member; membership by DN reference. | +| account (posixAccount) | UNIX account attributes bound to a person entry. | + +## Modeling Assumptions + +- **Identity is entry-centric**: a person is a directory entry located in a + hierarchical tree, not a free-floating actor. +- **Naming implies structure**: DN path encodes organizational placement + (`ou=Engineering,ou=People,dc=example,dc=com`). +- **Groups are entries**, not relationships; membership is an attribute on the + group entry pointing to member DNs. +- **Person and account can co-reside** on one entry (inetOrgPerson + + posixAccount auxiliary class). +- **Uniqueness** is per-directory-partition; `uid` or DN must be unique within + scope. +- **No standard org-entity object class** for corporations; org structure is + implied by `ou` containers. +- **Authorization** is external; groups are conventionally mapped to permission + sets by consuming applications. + +## Identity-Canon Implications + +- LDAP **inetOrgPerson entry** maps to **Identity Record** with optional + **Account** when posixAccount or login-binding attributes are present. +- **DN** and **uid** are **Identifiers** within the directory **Scope** + (namespace). +- **organizationalUnit** maps to a structural container, candidate + **Organization Unit** or scope partition — not automatically an + **Organization** actor. +- **groupOfNames** maps to **Group** with **Membership Relationship** via + member DN references. +- DN hierarchy suggests **Affiliation** or structural relationships but LDAP + does not type them explicitly. +- LDAP reinforces that **Identifier** (DN) carries locational semantics + beyond bare value identity. + +## Terminology Conflicts + +- **Account**: posixAccount is attribute bundle on a person entry; conflicts + with IAM Account as a distinct operational record. +- **User**: directory "user" means entry or uid; conflicts with application + session user. +- **Organization**: `ou` is a container, not a legal or commercial org actor. +- **Group**: LDAP group is an entry with member attributes; conflicts with + SCIM Group resource and social community. +- **Person**: inetOrgPerson is a schema label, not a legal natural-person + assertion. + +## Candidate Canonical Mappings + +| LDAP concept | Candidate canonical concept | +| --- | --- | +| inetOrgPerson entry | Identity Record | +| posixAccount attributes | Account (co-located on same entry) | +| DN | Identifier (locator + namespace) | +| uid, mail, employeeNumber | Identifier | +| organizationalUnit (ou) | Scope partition or org-unit container | +| groupOfNames entry | Group | +| member / uniqueMember | Membership Relationship | +| dc partition | Scope / Namespace | +| attribute values | Profile attributes or Claims on Identity Record | + +## Open Questions + +- Should DN be modeled as a compound Identifier (locator + value) or split + into Namespace Scope plus local Identifier? +- How should multi-valued `mail` attributes interact with synonymity assertions + when matching across systems? +- Does `ou` hierarchy warrant a canonical **Organizational Structure** + relationship type, or remain a naming convention? +- When inetOrgPerson and posixAccount coexist, is one Identity Record with + Account facet sufficient? + +## References + +- RFC 4519: LDAP Attribute Types and Object Classes — https://datatracker.ietf.org/doc/html/rfc4519 +- RFC 2798: Definition of the inetOrgPerson Object Class — https://datatracker.ietf.org/doc/html/rfc2798 +- RFC 4511: LDAP Protocol — https://datatracker.ietf.org/doc/html/rfc4511 +- RFC 2307: POSIX account/group schema — https://datatracker.ietf.org/doc/html/rfc2307 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md b/infospace/assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md new file mode 100644 index 0000000..9e53b97 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md @@ -0,0 +1,138 @@ +# Ory Kratos and Keto + +## Source Type + +Product documentation and open-source implementation reference for Ory Kratos +(identity management) and Ory Keto (relationship-based authorization). + +## Domain + +Cloud-native identity management, self-service flows, and ReBAC authorization +separation. + +## Why This Source Matters + +Ory Kratos identity/user management and Ory Keto relationship-based +authorization separation. + +Ory explicitly separates identity management (Kratos) from authorization +(Keto). This architectural split is a strong reference for identity-canon's +P6 principle (authorization projections separate from identity model). + +## Key Concepts + +- **Identity (Kratos)**: core identity record with traits (schema-defined + attributes), credentials, verifiable addresses, and recovery settings. +- **Traits**: JSON attributes on an identity (email, name, etc.) governed by + identity schema. +- **Credential**: password, OIDC link, TOTP, WebAuthn, or lookup secret + attached to an identity. +- **Identity schema**: JSON Schema defining allowed traits and validation. +- **Session**: authenticated session bound to an identity after credential + verification. +- **Recovery / Verification flow**: self-service processes for account + recovery and address verification. +- **Relation tuple (Keto)**: `namespace:object#relation@subject` assertion + for ReBAC checks. +- **Namespace (Keto)**: typed object class in the authorization model with + defined relations and permissions. +- **Subject (Keto)**: entity in a relation tuple; may reference a Kratos + identity or arbitrary identifier. +- **Permission check**: evaluate whether a subject has a relation to an + object in a namespace. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Identity | Kratos record with traits and credentials; not authorization entity. | +| Traits | Schema-validated attributes on an identity. | +| Credential | Authentication factor bound to identity. | +| Session | Active authenticated state for an identity. | +| Schema | JSON Schema defining identity trait structure per use case. | +| Relation tuple | Subject-relation-object fact in Keto. | +| Namespace | Authorization object type with relation definitions. | +| Subject | Authorization participant in a tuple. | +| Object | Resource or entity being authorized in a tuple. | +| Relation | Named edge type between subject and object. | + +## Modeling Assumptions + +- **Identity and authorization are separate services** with distinct storage + and APIs. +- **Identity means traits + credentials**, not permissions. +- **Traits are schema-driven**, allowing multiple identity schemas per + deployment (consumer vs. admin personas). +- **Sessions are ephemeral** authentication state, not identity records. +- **Authorization uses Zanzibar-style tuples** in Keto, not Kratos groups or + roles. +- **Subjects in Keto may not map 1:1** to Kratos identities; integration is + application-level. +- **No first-class organization or tenant** in Kratos core; multi-tenancy is + application concern. + +## Identity-Canon Implications + +- Kratos **Identity** maps to **Identity Record** with **Profile** (traits) + and **Credential** attachments. +- Kratos does not use "account" explicitly; Identity is closer to Account + + Profile combined. +- **Session** is ephemeral auth state, not a canonical entity; maps to + downstream session projection. +- **Identity schema** maps to schema governance for Profile/Identity Record + attributes in a Scope. +- Keto **relation tuple** maps to **Relationship Tuple** (authorization + projection) or typed **Relationship** with authz implication. +- Keto **namespace** maps to **Authorization Domain** Scope. +- Keto **subject** maps to **Authorization Principal** projection. +- Strong evidence for **P6**: identity store and authorization graph are + orthogonal. +- Supports S01 (single local identity), S10 (service identity via traits + + credentials), S11 (agent via separate Keto tuples). + +## Terminology Conflicts + +- **Identity**: Kratos Identity is a record with credentials; conflicts with + bare "identity" meaning personhood or issuer subject. +- **Subject**: Keto subject is authorization participant; OIDC subject is + issuer identifier; different layers. +- **Traits vs. Profile**: traits are stored attributes; profile is + presentation — often conflated in Kratos. +- **Namespace**: Keto namespace is authorization object type; DNS/LDAP + namespace is naming scope. +- **No user term**: Kratos avoids "user" in API, but docs sometimes use it + informally. + +## Candidate Canonical Mappings + +| Ory concept | Candidate canonical concept | +| --- | --- | +| Kratos Identity | Identity Record + Account facet | +| Traits | Profile attributes | +| Credential | Credential | +| Session | Ephemeral auth projection (non-canonical) | +| Identity schema | Profile/record schema in Scope | +| Keto relation tuple | Relationship Tuple (authorization projection) | +| Keto namespace | Authorization Domain Scope | +| Keto subject | Authorization Principal | +| Keto object | Authorization Resource | +| Keto relation | Relationship type (authz) | +| Verification flow | Evidence Source event | + +## Open Questions + +- Should Kratos Identity be split into Account + Profile in canon, or kept + as unified Identity Record? +- How should Keto subjects that reference non-Kratos identifiers (e.g., + `group:engineering#member`) map to canonical Group + Membership? +- Does Kratos multi-schema support (consumer vs. admin) map to Persona or + separate Identity Records? +- Should session be documented as a projection type in canon or remain + explicitly out of scope? + +## References + +- Ory Kratos documentation — https://www.ory.sh/docs/kratos/ +- Ory Keto documentation — https://www.ory.sh/docs/keto/ +- Ory Kratos identity model — https://www.ory.sh/docs/kratos/manage-user-identities/identity-schema +- Ory Keto relation tuples — https://www.ory.sh/docs/keto/concepts/relation-tuples \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md b/infospace/assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md new file mode 100644 index 0000000..b3ba782 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md @@ -0,0 +1,133 @@ +# SCIM RFC 7643 and RFC 7644 + +## Source Type + +Standard. RFC 7643 defines the SCIM 2.0 core schema; RFC 7644 defines the +SCIM 2.0 protocol for provisioning. + +## Domain + +Identity provisioning and directory synchronization. + +## Why This Source Matters + +SCIM 2.0: RFC 7643 schema and RFC 7644 protocol. + +SCIM is the dominant platform-neutral provisioning baseline. It defines +resource types, attribute schemas, and CRUD/search operations for users and +groups without prescribing authentication or authorization semantics. + +## Key Concepts + +- **Resource**: a provisionable object with a `schemas` array, `id`, `meta`, + and typed attributes. +- **User resource**: a person-oriented identity record with `userName`, + `name`, `emails`, `phoneNumbers`, `addresses`, `groups`, `roles`, and + `active` lifecycle state. +- **Group resource**: a named collection with `displayName`, `members`, and + optional `type` (direct or indirect membership). +- **Enterprise User extension** (RFC 7643 §4.3): adds `employeeNumber`, + `costCenter`, `organization`, `division`, `department`, and `manager` for + workforce semantics. +- **Service Provider Config**: exposes supported features, authentication + schemes, and bulk limits. +- **Meta block**: `resourceType`, `created`, `lastModified`, `version`, + `location` — lifecycle and versioning metadata on every resource. +- **Operations**: Create, Read, Update, Delete, Search (POST /Users/.search), + and Bulk (RFC 7644 §3.7). +- **PatchOp**: partial updates via `add`, `remove`, `replace` on paths. +- **ExternalId**: cross-system correlation identifier supplied by the client. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| User | A provisionable identity record; not necessarily a login account in the consuming system. | +| Group | A named collection of members; may represent authorization, organizational, or mailing-list grouping. | +| userName | Unique identifier within the service provider's namespace; often used as login handle. | +| externalId | Client-supplied correlation key for linking to an upstream system of record. | +| active | Boolean lifecycle flag; inactive users retain the record but should lose access. | +| member | Reference (`value`, `display`, `$ref`) to a User or Group in a Group's membership list. | +| organization (extension) | Free-text employer or org name on a user; not a structured org resource. | +| manager | Reference to another User who manages this user. | +| roles | Application-specific role strings on the User resource; not RBAC policy. | +| Service Provider | The system receiving provisioned resources. | +| Client | The system sending provisioning requests. | + +## Modeling Assumptions + +- A **User** is the primary provisionable identity record; there is no separate + Account or Person resource type in core SCIM. +- **Groups** absorb membership semantics; there is no first-class relationship + tuple beyond group membership references. +- **Organization structure** is flattened into user attributes (department, + division, organization) rather than modeled as org entities. +- **Lifecycle** is binary (`active` true/false) with soft-disable semantics; + deletion is a separate operation. +- **Uniqueness** is scoped to the service provider; `userName` must be unique + within the SP namespace. +- **Authorization** is out of scope; `roles` and group membership are hints + that downstream systems may map to policies. +- **Multi-tenancy** is not defined; tenant isolation is an implementation + concern of the service provider. + +## Identity-Canon Implications + +- SCIM **User** maps to **Identity Record** (and often **Account** when the + SP uses it for login), not to **Natural Person**. +- SCIM **Group** maps to **Group** collective actor with **Membership + Relationship** edges to member records. +- `userName` and `externalId` are **Identifiers** within the SP **Scope**. +- `active` maps to **Lifecycle State** on the Identity Record. +- Enterprise extension `manager` suggests a **Representation** or reporting + relationship, but SCIM does not type it beyond a User reference. +- `organization`, `department`, `division` are attribute-level hints, not + **Organization** actors; canon should not treat them as structured org graphs. +- SCIM reinforces **P2** (person ≠ account) and **P5** (membership explicit) + but lacks actor-layer primitives. + +## Terminology Conflicts + +- **User**: SCIM User is a record, not a human being. Conflicts with + application "user" meaning login session holder. +- **Group**: SCIM Group may mean LDAP security group, mailing list, or org + unit depending on deployment; conflicts with social **Community**. +- **Role**: SCIM `roles` are opaque strings; conflicts with Cedar/OpenFGA + relationship-based roles and IAM permission bundles. +- **Organization**: SCIM extension `organization` is a string attribute; + conflicts with **Organization** collective actor in IAM products. +- **Active**: boolean disable vs. full lifecycle states (suspended, archived) + used in enterprise directories. + +## Candidate Canonical Mappings + +| SCIM concept | Candidate canonical concept | +| --- | --- | +| User resource | Identity Record (+ Account when login-enabled) | +| Group resource | Group | +| member reference | Membership Relationship | +| userName | Identifier | +| externalId | Identifier (cross-system correlation) | +| active | Lifecycle State | +| manager (extension) | Representation Relationship (weakly typed) | +| organization/department/division | Affiliation hints; not Organization actors | +| roles (extension) | Role labels; authorization projection input | +| meta.created/lastModified | Evidence timestamps for record provenance | +| Service Provider namespace | Scope | + +## Open Questions + +- Should SCIM `externalId` be modeled as a dedicated **Identifier Binding** + or a generic Identifier with source metadata? +- How should indirect group membership (`type: indirect`) map to canon + membership vs. inherited authorization projection? +- Does the Enterprise User `manager` reference warrant a canonical + **Reporting Relationship** distinct from Representation? +- Should a SCIM-only deployment without login map User exclusively to + Identity Record, skipping Account? + +## References + +- RFC 7643: SCIM 2.0 Core Schema — https://datatracker.ietf.org/doc/html/rfc7643 +- RFC 7644: SCIM 2.0 Protocol — https://datatracker.ietf.org/doc/html/rfc7644 +- IETF SCIM working group overview — https://datatracker.ietf.org/wg/scim/about/ \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md b/infospace/assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md new file mode 100644 index 0000000..e8785b3 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md @@ -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 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md b/infospace/assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md new file mode 100644 index 0000000..9a157ba --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md @@ -0,0 +1,114 @@ +# ActivityPub Actors and Followers + +## Source Type + +Standard. W3C ActivityPub (REC) with Activity Streams 2.0 vocabulary for +federated social actors, inboxes, and follower relationships. + +## Domain + +Federated social graphs, actor identity, following/followers, and server-side +account representation. + +## Why This Source Matters + +ActivityPub treats users as server-side actors with inboxes and outboxes. A +person may have several actors across servers, mapping well to contextual +identities and personas. + +## Key Concepts + +- **Actor**: Activity Streams object (Person, Service, Group, Organization, + Application) with `inbox`, `outbox`, `followers`, `following`, `liked`. +- **Person actor**: human-associated actor on a federated server. +- **Service / Application actor**: automated or app-mediated actor. +- **Group actor**: collective actor with shared inbox/outbox. +- **Follow activity**: actor A sends Follow to actor B; B may Accept or Reject. +- **Followers / Following collections**: reverse-indexed social graph edges. +- **preferredUsername**: handle local to the origin server. +- **Actor ID (URL)**: globally unique actor URI, typically HTTPS profile URL. +- **SharedInbox**: delivery optimization for addressing multiple actors. +- **Public / followers-only addressing**: audience scoping for activities. +- **WebFinger**: discovery of actor profile from `acct:user@domain`. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Actor | Server-hosted social entity with inbox/outbox; not necessarily one human. | +| Person | Actor type for human-associated accounts. | +| Follow | Directed activity establishing follower relationship. | +| Follower | Actor who follows another actor. | +| preferredUsername | Local handle on origin server. | +| Actor ID | HTTPS URI identifying actor globally. | +| Inbox / Outbox | Message endpoints for receiving/sending activities. | +| Group (actor type) | Collective actor in ActivityPub sense. | +| Service | Non-human automated actor type. | +| acct: URI | Account identifier for WebFinger discovery. | + +## Modeling Assumptions + +- **Actor is the primary social identity unit**, hosted on an origin server. +- **One human may operate multiple actors** across servers (implicit, not + standardized as same-person link). +- **Following is a social subscription**, not membership or authorization. +- **Actor ID is globally unique** within the fediverse namespace. +- **Server is authority** for actor existence and deletion. +- **Groups and Organizations are actor types**, not separate provisioning models. +- **No standardized account linking** across actors for same natural person. + +## Identity-Canon Implications + +- ActivityPub **Actor** maps to **Actor** (Person → Natural Person association + via Account/Profile on origin server). +- **Person actor** implies **Natural Person** operator but actor ≠ person. +- **Service/Application actor** maps to **Artificial Agent**. +- **Group actor** maps to **Community** or **Group** collective actor. +- **Follow** maps to **Following Relationship** (directed, social). +- **preferredUsername** + domain maps to **Identifier** in server **Scope**. +- **Actor ID (URL)** maps to global **Identifier**. +- Multi-server actors per person support S02, S09, S14 without mandatory + synonymity. +- **followers-only** audience maps to Scope/audience boundary on Profile. + +## Terminology Conflicts + +- **Actor vs. User**: ActivityPub actor is server entity; apps say user. +- **Person vs. Natural Person**: Person is actor type, not verified human. +- **Group**: ActivityPub Group actor vs. LDAP/SCIM group vs. IAM group. +- **Follow vs. Member**: following ≠ community membership unless separately defined. +- **Account vs. Actor**: `acct:` suggests account, but actor is richer object. + +## Candidate Canonical Mappings + +| ActivityPub concept | Candidate canonical concept | +| --- | --- | +| Actor (Person) | Actor + Profile + Account (on origin server) | +| Actor (Service) | Artificial Agent + Service Account | +| Actor (Group) | Community or Group collective actor | +| Actor (Organization) | Organization collective actor | +| Follow activity | Following Relationship | +| Followers/Following collections | Relationship indexes | +| preferredUsername | Identifier (local handle) | +| Actor ID (URL) | Identifier (global) | +| acct: URI | Identifier | +| Origin server domain | Scope | +| Inbox/Outbox | Operational endpoints (downstream) | +| WebFinger | Discovery protocol (downstream) | + +## Open Questions + +- Should cross-server actors for one Natural Person require explicit Synonymity + Assertion, or remain unlinked by default? +- Does ActivityPub Organization actor type map to Organization or Community + depending on moderation model? +- How should moved-to / moved-from actor migration (if used) map to Identifier + Binding supersession? +- Should followers-only audience be a Profile visibility Scope or separate + Relationship attribute? + +## References + +- W3C ActivityPub — https://www.w3.org/TR/activitypub/ +- Activity Streams 2.0 — https://www.w3.org/TR/activitystreams-core/ +- WebFinger (RFC 7033) — https://datatracker.ietf.org/doc/html/rfc7033 \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md b/infospace/assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md new file mode 100644 index 0000000..eaad8bc --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md @@ -0,0 +1,113 @@ +# FOAF Agent Person Group OnlineAccount + +## Source Type + +Semantic vocabulary. FOAF (Friend of a Friend) RDF vocabulary for persons, +agents, groups, and online accounts. + +## Domain + +Semantic web social identity, person/agent distinction, and account +representation. + +## Why This Source Matters + +FOAF distinguishes persons, agents, organizations, groups, accounts, and +membership-like properties — an early explicit separation of actor, account, +and online presence. + +## Key Concepts + +- **foaf:Person**: a person (human); may have name, homepage, depiction. +- **foaf:Agent**: anything that can do things; superclass of Person, Organization, + Group. +- **foaf:Organization**: collective agent with members and name. +- **foaf:Group**: collective agent with `member` property linking to agents. +- **foaf:OnlineAccount**: account on a service; links via `accountServiceHomepage` + and `accountName`. +- **foaf:OnlineChatAccount / OnlineGamingAccount**: specialized account types. +- **foaf:member**: agent belongs to group (inverse of Group membership). +- **foaf:knows**: social acquaintance link between agents (not authorization). +- **foaf:mbox / mbox_sha1sum**: email or hashed email identifiers. +- **foaf:openid**: OpenID identifier for agent. +- **foaf:Document / Image**: non-agent resources. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Person | Human being in FOAF sense. | +| Agent | Anything capable of action; includes persons and collectives. | +| Organization | Named collective agent. | +| Group | Collective agent with explicit members. | +| OnlineAccount | Presence on a service with account name. | +| member | Membership link from group to agent. | +| knows | Social network acquaintance between agents. | +| accountName | Handle on a service. | +| accountServiceHomepage | Service URL defining account namespace. | +| mbox | Email identifier (often `mailto:` URI). | + +## Modeling Assumptions + +- **Agent is the root actionable type**; Person is a specialization. +- **Person is explicitly human**, separate from accounts. +- **OnlineAccount is not the person**; it is an account on a service linked + to an agent. +- **Groups and Organizations are agents** with member properties. +- **Social knows is weak affiliation**, not trust or authorization. +- **Identifiers (mbox, openid) are properties**, not first-class scoped objects. +- **RDF graph allows multiple incomplete assertions** about same agents. + +## Identity-Canon Implications + +- FOAF **Person** maps closely to **Natural Person**. +- FOAF **Agent** maps to **Actor**. +- FOAF **Organization** / **Group** map to **Organization** / **Group** + collective actors. +- FOAF **OnlineAccount** maps to **Account** with service **Scope** defined + by `accountServiceHomepage`. +- **accountName** maps to **Identifier**. +- **member** maps to **Membership Relationship**. +- **knows** maps to **Affiliation Relationship** (social, weak). +- FOAF is strong evidence for **P1** (actor root) and **P2** (person ≠ account). +- Supports S01, S08, S09 with explicit person/account split. + +## Terminology Conflicts + +- **Agent vs. Artificial Agent**: FOAF Agent includes humans; canon Artificial + Agent is non-human only. +- **Group vs. Community**: FOAF Group is generic collective; community implies + participation norms. +- **OnlineAccount vs. Profile**: FOAF account is service presence; profile is + broader presentation surface. +- **knows vs. Following**: knows is bidirectional acquaintance; ActivityPub + Follow is directed. +- **mbox vs. Identifier**: mbox is contact + identifier; conflation risk. + +## Candidate Canonical Mappings + +| FOAF concept | Candidate canonical concept | +| --- | --- | +| Person | Natural Person | +| Agent | Actor | +| Organization | Organization | +| Group | Group | +| OnlineAccount | Account | +| accountName | Identifier | +| accountServiceHomepage | Scope (service namespace) | +| member | Membership Relationship | +| knows | Affiliation Relationship | +| mbox / openid | Identifier | +| depiction / name | Profile attributes | + +## Open Questions + +- Should FOAF OnlineAccount always imply Account, or sometimes Profile only? +- How should `mbox_sha1sum` map for privacy-preserving synonymity (weak match)? +- Does FOAF Group map to Group only, or also Community when informal? +- Should knows remain Affiliation, or split into Following vs. acquaintance? + +## References + +- FOAF vocabulary specification — http://xmlns.com/foaf/spec/ +- FOAF 0.99 RDF schema — http://xmlns.com/foaf/0.1/ \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md b/infospace/assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md new file mode 100644 index 0000000..1c688eb --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md @@ -0,0 +1,112 @@ +# Schema.org Person Organization Membership + +## Source Type + +Semantic vocabulary. Schema.org types and properties for Person, Organization, +membership, and role-like affiliations. + +## Domain + +Structured data about people and organizations, SEO/social graphs, and +membership representation on the web. + +## Why This Source Matters + +Schema.org distinguishes persons, organizations, membership, employee roles, +and affiliation properties — widely used for web-scale person/org modeling. + +## Key Concepts + +- **Person**: living human; properties include `name`, `email`, `identifier`, + `sameAs`, `affiliation`, `worksFor`, `memberOf`. +- **Organization**: business, club, or other collective; `member`, `employee`, + `department`, `subOrganization`, `parentOrganization`. +- **OrganizationRole**: intermediate type linking person to organization with + `roleName`, `startDate`, `endDate`. +- **member / memberOf**: reciprocal membership between Person and Organization. +- **employee / worksFor**: employment relationship properties. +- **affiliation**: organization a person is affiliated with (looser than member). +- **sameAs**: URL of related entity — often used for weak equivalence/synonymity. +- **identifier**: PropertyValue or Text for external IDs. +- **SportsTeam / PerformingGroup**: specialized Organization subtypes. +- **ProgramMembership**: membership in a program with tier/benefits. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Person | Human being in structured data. | +| Organization | Collective entity (company, club, NGO). | +| memberOf | Person belongs to Organization. | +| member | Organization has Person as member. | +| employee | Person employed by Organization. | +| worksFor | Inverse employment link. | +| affiliation | Looser org association for Person. | +| sameAs | Related/equivalent resource URL (weak linking). | +| OrganizationRole | Named role with temporal bounds. | +| subOrganization | Org hierarchy child. | +| identifier | External ID for entity. | + +## Modeling Assumptions + +- **Person means human** in schema.org intent. +- **Membership and employment are properties**, not reified relationship objects + (except OrganizationRole). +- **sameAs is informal equivalence** between web resources, not verified identity. +- **Organizations can nest** via subOrganization/parentOrganization. +- **Roles can be typed** via OrganizationRole with dates. +- **No authentication or authorization** semantics. +- **Properties are multi-valued**; one person can have many memberships. + +## Identity-Canon Implications + +- Schema.org **Person** maps to **Natural Person**. +- **Organization** maps to **Organization** collective actor. +- **memberOf / member** map to **Membership Relationship**. +- **employee / worksFor** map to **Affiliation Relationship** or employment + specialization of Membership. +- **affiliation** maps to **Affiliation Relationship** (looser). +- **OrganizationRole** maps to **Role** relationship with temporal bounds. +- **subOrganization** maps to structural relationship between Organization + actors (child/parent). +- **sameAs** maps to **weak Synonymity Assertion** between web resources — + high conflation risk if treated as strong link. +- **identifier** maps to **Identifier** PropertyValue. +- Supports S03 (sub-orgs), S07 (informal groups as Organization subtypes), S08. + +## Terminology Conflicts + +- **Person vs. Profile**: schema.org Person is often used for public profile page. +- **member vs. employee**: overlapping employment semantics; not always distinct. +- **sameAs vs. Synonymity**: sameAs is SEO linking, not identity proofing. +- **Organization vs. Community**: SportsTeam/PerformingGroup blur social vs. org. +- **Role vs. OrganizationRole**: roleName may be job title or permission label. + +## Candidate Canonical Mappings + +| Schema.org concept | Candidate canonical concept | +| --- | --- | +| Person | Natural Person | +| Organization | Organization | +| memberOf / member | Membership Relationship | +| employee / worksFor | Affiliation or employment Membership | +| affiliation | Affiliation Relationship | +| OrganizationRole | Role + Membership with temporal bounds | +| subOrganization | Organization hierarchy Relationship | +| sameAs | Weak Synonymity Assertion (caution) | +| identifier | Identifier | +| ProgramMembership | Membership Relationship (program scope) | + +## Open Questions + +- Should sameAs ever promote beyond weak Synonymity without additional evidence? +- Does OrganizationRole warrant a canonical temporal Relationship subtype? +- How should ProgramMembership map vs. Community membership? +- Should subOrganization be a distinct Relationship type or Organization attribute? + +## References + +- Schema.org Person — https://schema.org/Person +- Schema.org Organization — https://schema.org/Organization +- Schema.org OrganizationRole — https://schema.org/OrganizationRole +- Schema.org sameAs — https://schema.org/sameAs \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md b/infospace/assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md new file mode 100644 index 0000000..101413a --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md @@ -0,0 +1,108 @@ +# WebID and Solid Profile + +## Source Type + +Standard and ecosystem specification. WebID (W3C CG) for decentralized +identifiers; Solid Protocol for user-controlled data pods and profiles. + +## Domain + +Decentralized identity-style profile discovery, user-controlled storage, and +WebID-based identification. + +## Why This Source Matters + +WebID/Solid support user-controlled profiles and decentralized identity-style +profile discovery, relevant to persona, identifier, and data-sovereignty +semantics. + +## Key Concepts + +- **WebID**: HTTP(S) URI identifying an agent; dereferencing yields profile + document (RDF). +- **WebID profile document**: RDF description of agent with type, name, + certificates, and links. +- **Solid Pod**: user-controlled personal data store with access control. +- **Solid Profile**: extended profile in pod with extended attributes and + preferences. +- **WebID-OIDC**: bridge binding OIDC authentication to WebID URI. +- **Agent type in profile**: self-described person or organization. +- **ACL (WAC / ACP)**: resource-level access control on pod resources. +- **Type Index**: registry of resource types in a pod. +- **Identity provider linkage**: OIDC issuer associated with WebID. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| WebID | HTTP URI identifying an agent; profile at same URL. | +| Profile document | RDF at WebID URI describing the agent. | +| Pod | User-controlled storage space. | +| Solid Profile | Profile data stored in pod. | +| Agent | Entity described by WebID (person or org). | +| WebID-OIDC | OIDC flow producing ID token with WebID claim. | +| ACL | Access control on pod resources. | +| Type Index | Discovery of pod resource categories. | +| issuer | OIDC provider linked to WebID authentication. | + +## Modeling Assumptions + +- **Identifier (WebID URI) is primary**; profile is dereferenceable description. +- **User controls data placement** in pod, not only profile attributes. +- **Agent self-describes** type (person/org) in RDF profile. +- **Authentication can bind OIDC subject to WebID** via WebID-OIDC. +- **Access control is resource-centric** on pod, separate from identity record. +- **No central directory**; discovery via URI dereferencing. +- **Multiple profiles/pods per person** possible across providers. + +## Identity-Canon Implications + +- **WebID URI** maps to **Identifier** (globally dereferenceable). +- **Profile document** maps to **Profile** with RDF attributes. +- **Pod** maps to user-controlled **Scope** for data storage. +- **Agent in profile** maps to **Actor** (Natural Person or Organization). +- **WebID-OIDC binding** maps to **Synonymity Assertion** / **Identifier + Binding** between OIDC `sub`+`iss` and WebID URI. +- **ACL** maps to authorization projection on resources in pod Scope. +- Supports S14 (pseudonymous/scoped identity), S02 (multiple profiles), user + sovereignty goals from ResearchSeed. + +## Terminology Conflicts + +- **WebID vs. DID**: both decentralized identifiers; different ecosystems and + resolution models. +- **Profile vs. Account**: Solid profile is data surface; may not include + login credentials on same system. +- **Agent vs. Actor**: WebID agent is self-described entity; canon Actor is + broader participation root. +- **Identity vs. WebID**: developers equate WebID with whole identity. +- **ACL vs. Authorization Principal**: pod ACL uses WebID URIs as agents. + +## Candidate Canonical Mappings + +| WebID/Solid concept | Candidate canonical concept | +| --- | --- | +| WebID URI | Identifier | +| Profile document | Profile | +| Solid Pod | Scope (user-controlled data) | +| Agent (in RDF) | Actor | +| WebID-OIDC binding | Identifier Binding / Synonymity Assertion | +| OIDC iss + sub | Scoped Identifier | +| ACL agent | Authorization Principal (WebID URI) | +| Type Index | Profile/discovery metadata | +| Pod resource | Resource (downstream) | + +## Open Questions + +- Should WebID URI be a distinct Identifier subtype vs. generic HTTP URI? +- How should WebID-OIDC binding strength compare to OIDC pairwise sub (S14)? +- Does pod Scope warrant a canonical "Data Scope" specialization? +- Should Solid ACL remain purely authorization projection, or inform + Relationship types for resource sharing? + +## References + +- Solid Protocol — https://solidproject.org/TR/protocol +- WebID 1.0 (community spec) — https://www.w3.org/2005/Incubator/webid/wiki/Identity_Providers +- WebID-OIDC — https://solid.github.io/webid-oidc-spec/ +- Solid Access Control (ACP) — https://solidproject.org/TR/acl-spec \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/verifiable-claims/did-core.md b/infospace/assimilation/canon-federation/source/research/verifiable-claims/did-core.md new file mode 100644 index 0000000..33dc868 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/verifiable-claims/did-core.md @@ -0,0 +1,109 @@ +# W3C DID Core + +## Source Type + +Standard. W3C Decentralized Identifiers (DIDs) v1.0 Core. + +## Domain + +Decentralized identifiers, verifiable identity subjects, DID documents, and +verification methods. + +## Why This Source Matters + +DIDs provide externally controlled identifiers with cryptographic verification +methods, relevant to portable identity, issuer independence, and synonymity +across systems. + +## Key Concepts + +- **DID**: globally unique URI following `did:method:identifier` syntax. +- **DID subject**: entity identified by a DID; may be person, org, or thing. +- **DID controller**: entity authorized to change DID document (may differ from + subject). +- **DID document**: JSON-LD document resolved from DID; contains verification + methods, services, and controllers. +- **Verification method**: cryptographic key or proof mechanism for authentication + or signing. +- **Service endpoint**: machine-readable service URL in DID document. +- **DID method**: specific ledger or resolution rules (`did:web`, `did:key`, + `did:ion`, etc.). +- **Resolution**: process of retrieving DID document from DID URL. +- **Also-known-as / equivalentId**: related identifier properties (method-specific). +- **Delegation**: controller grants another party control via verification + relationship. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| DID | Decentralized identifier string. | +| DID subject | Entity the DID names. | +| DID controller | Party that can update DID document. | +| DID document | Resolved metadata about DID. | +| Verification method | Key/material for prove/control. | +| Service | Endpoint declaration in document. | +| DID method | Resolution and registry rules. | +| Resolve | Fetch DID document. | +| Controller | Authority over DID lifecycle. | +| Subject (DID) | Identified party; not necessarily controller. | + +## Modeling Assumptions + +- **Identifier is primary**; subject is named by DID, not stored in central directory. +- **Control is cryptographic** via verification methods and controllers. +- **Subject and controller may diverge** (custodial wallets, organizational DIDs). +- **DID document is mutable** under controller authority. +- **Methods vary in persistence, privacy, and registry model.** +- **No built-in person/account distinction**; semantics are method and usage dependent. +- **Relationships to other DIDs** may appear as services or custom properties. + +## Identity-Canon Implications + +- **DID** maps to **Identifier** (decentralized, resolvable). +- **DID subject** maps to **Actor** or target of **Claim** depending on usage. +- **DID controller** maps to **Representation** or **Ownership** relationship + over identifier control. +- **Verification method** maps to **Credential** (cryptographic). +- **DID document** maps to **Profile** / metadata record for Identifier. +- **Service endpoint** maps to operational binding (downstream). +- DID-based strong binding supports S13 (verified link), S14 (pseudonymous + scoped identity when using pairwise/privacy-preserving methods). +- Reinforces **P8** (evidence via cryptographic verification). + +## Terminology Conflicts + +- **Subject**: DID subject vs. OIDC sub vs. authorization subject. +- **Controller vs. Owner**: controller is key/document authority; owner is + broader relationship. +- **Identity vs. DID**: DID is identifier, not identity record. +- **Credential vs. Verification method**: verification method is key material; + VC is claim artifact. +- **Resolve vs. Lookup**: resolution is method-specific; not uniform directory. + +## Candidate Canonical Mappings + +| DID Core concept | Candidate canonical concept | +| --- | --- | +| DID | Identifier | +| DID subject | Actor (context-dependent) | +| DID controller | Representation or Ownership Relationship | +| DID document | Profile / Identifier metadata record | +| Verification method | Credential | +| Service endpoint | Operational binding (downstream) | +| DID method namespace | Scope (method-specific) | +| Resolution result | Evidence Source | +| equivalentId / alsoKnownAs | Synonymity Assertion (method-dependent) | + +## Open Questions + +- Should DID be a distinct Identifier subtype with method and resolution metadata? +- How should subject/controller split map for organizational vs. personal DIDs? +- Does equivalentId warrant weak or strong Synonymity by default? +- How do DID methods with pairwise features (e.g., did:ion pairwise) map to + Scoped Identifier? + +## References + +- W3C DID Core v1.0 — https://www.w3.org/TR/did-core/ +- DID Specification Registries — https://www.w3.org/TR/did-spec-registries/ \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md b/infospace/assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md new file mode 100644 index 0000000..1df947a --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md @@ -0,0 +1,106 @@ +# OpenID for Verifiable Credentials (OpenID4VC) + +## Source Type + +Standard suite. OpenID4VCI (issuance), OpenID4VP (presentation), and related +OAuth 2.0 profiles for verifiable credentials. + +## Domain + +VC issuance and presentation protocols, wallet-holder flows, and federation of +verifiable credential ecosystems. + +## Why This Source Matters + +OpenID4VC bridges OAuth/OIDC infrastructure with W3C Verifiable Credentials, +connecting federation protocols to portable claim semantics. + +## Key Concepts + +- **OpenID4VCI**: issuer-to-holder credential issuance using OAuth 2.0 access + tokens and credential offers. +- **OpenID4VP**: holder-to-verifier presentation using authorization requests + and VP tokens. +- **Credential Issuer**: OIDC/OAuth entity issuing VCs. +- **Wallet / Holder**: stores credentials and responds to presentation requests. +- **Verifier**: requests and validates presentations. +- **Credential Offer**: deeplink/URI initiating issuance to wallet. +- **Proof of possession**: holder proves control of key bound to credential. +- **Authorization Request (VP)**: verifier specifies required credential types. +- **SD-JWT VC**: selective disclosure JWT credential format (parallel track). +- **mDL / ISO 18013-5**: mobile document format integrated in some profiles. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Credential Issuer | OAuth/OIDC party issuing VCs. | +| Wallet | Holder software storing VCs. | +| Verifier | Party requesting VP from wallet. | +| Credential offer | Issuance initiation artifact. | +| Authorization request | Presentation request to wallet. | +| VP token | Presentation response token. | +| c_nonce | Issuance proof challenge. | +| format | VC encoding (jwt_vc, ldp_vc, sd-jwt). | +| credential_definition | Type/filter for requested credential. | +| presentation_definition | Verifier's input requirements. | + +## Modeling Assumptions + +- **Issuance is OAuth-mediated** between issuer, wallet, and optional broker. +- **Presentation is verifier-driven** with explicit requested claim types. +- **Holder wallet is trust boundary** for credential storage and selective disclosure. +- **OIDC identity may bootstrap wallet** or issuer trust. +- **Multiple credential formats** coexist (JWT, JSON-LD, SD-JWT). +- **Revocation/status checked at verification** time. +- **Pairwise issuance** possible for privacy-preserving credentials. + +## Identity-Canon Implications + +- OpenID4VCI issuance flow maps to **Credential** creation with **Claim**, + **Issuer** Scope, and **Evidence Source** (issuance event). +- OpenID4VP presentation maps to verifier **Trust Relationship** evaluating + **Credential** + **Claim** subset. +- **Wallet** maps to holder **Actor** + storage **Scope** (custody boundary). +- OIDC authentication preceding issuance maps to **Authenticated Subject** → + **Account** → VC **Subject** binding via **Identifier Binding**. +- Selective disclosure supports S14 (privacy-limited claims). +- Bridges federation (OIDC) and VC layers for S13 strong links. +- Reinforces projection pattern: OIDC for auth, VC for claims. + +## Terminology Conflicts + +- **Issuer**: OIDC issuer vs. VC issuer — often same entity, different roles. +- **Subject**: OIDC sub in token vs. VC credentialSubject. +- **Credential**: OAuth credential vs. Verifiable Credential. +- **Verifier vs. RP**: overlapping roles with added VP verification. +- **Wallet vs. Account**: wallet is credential store, not always login account. + +## Candidate Canonical Mappings + +| OpenID4VC concept | Candidate canonical concept | +| --- | --- | +| Credential Issuer | Issuer Scope + Trust Relationship | +| Wallet / Holder | Actor (custody) + Scope | +| Verifier | Verifier / RP Scope | +| Issued VC | Credential + Claim | +| Credential offer | Evidence Source (issuance initiation) | +| Presentation | Credential presentation (operational) | +| OIDC auth prior to issuance | Authenticated Subject → Identifier Binding | +| presentation_definition | Verifier policy (downstream) | +| SD-JWT selective disclosure | Privacy-limited Claim exposure | +| Status check | Lifecycle State verification | + +## Open Questions + +- Should wallet custody be a canonical Scope specialization (Holder Scope)? +- How should OIDC sub to VC subject binding strength be classified (weak vs. + strong Synonymity)? +- Does OpenID4VP verifier policy belong in canon or strictly downstream? +- Should SD-JWT credentials map to Credential subtype with disclosure metadata? + +## References + +- OpenID4VCI — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html +- OpenID4VP — https://openid.net/specs/openid-4-verifiable-presentations-1_0.html +- OpenID4VCI SD-JWT profile — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-sd-jwt-vc \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md b/infospace/assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md new file mode 100644 index 0000000..4d7d6b1 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md @@ -0,0 +1,110 @@ +# W3C Verifiable Credentials Data Model 2.0 + +## Source Type + +Standard. W3C Verifiable Credentials Data Model 2.0 (WD/CR as applicable). + +## Domain + +Verifiable claims, issuers, holders, verifiers, credential lifecycle, and +portable identity assertions. + +## Why This Source Matters + +Verifiable Credentials formalize issuer-holder-verifier semantics for portable, +cryptographically verifiable claims about subjects — central to evidence-based +identity modeling. + +## Key Concepts + +- **Verifiable Credential (VC)**: tamper-evident credential making claims about + a subject, signed by issuer. +- **Verifiable Presentation (VP)**: bundle of VCs (and proofs) presented by holder + to verifier. +- **Issuer**: entity that asserts claims and signs VC. +- **Holder**: entity possessing VC (may or may not be subject). +- **Verifier**: entity checking VC/VP validity. +- **Subject**: entity claims are about (`credentialSubject`). +- **Claim**: individual statement within credentialSubject. +- **Proof**: cryptographic proof of integrity and issuer authenticity. +- **Credential schema**: type and structure definition for VC. +- **Status**: revocation/suspension via StatusList2021 or similar. +- **ValidFrom / ValidUntil**: temporal validity window. +- **Evidence**: supporting documents referenced in VC (DID, attachments). + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Verifiable Credential | Signed claim set about subject. | +| Presentation | Holder-submitted package for verification. | +| Issuer | Signing authority for claims. | +| Holder | Party storing/presenting VC. | +| Verifier | Party validating VC/VP. | +| Subject | Entity described by credentialSubject. | +| credentialSubject | Claim object about subject. | +| Proof | Cryptographic verification data. | +| StatusList | Revocation/suspension mechanism. | +| type | VC semantic type(s). | +| validFrom / validUntil | Temporal bounds. | + +## Modeling Assumptions + +- **Claims are assertions, not ground truth** until verified by verifier policy. +- **Issuer authority is explicit** and cryptographically attributable. +- **Holder may differ from subject** (custodial credentials). +- **Revocation is first-class** via status mechanisms. +- **Temporal validity matters** for employment, membership, age claims. +- **Selective disclosure** may hide parts of credentialSubject (privacy). +- **Subject may be identified by DID, URI, or other identifier.** + +## Identity-Canon Implications + +- **VC** maps to **Credential** containing **Claim** set. +- **credentialSubject** claims map to individual **Claim** objects about + **Actor**, **Membership**, or attributes. +- **Issuer** maps to issuer **Scope** + **Trust Relationship**. +- **Holder** maps to **Actor** or **Account** holding credential. +- **Verifier** maps to relying party evaluating Trust + Evidence. +- **Subject** maps to **Actor** or Identifier target. +- **Status/revocation** maps to **Lifecycle State** on Credential/Claim. +- **validFrom/validUntil** map to relationship/assertion temporal bounds. +- Supports S13 (strong verified link), S03 (org membership claims), S06 + (guardian credentials if issued). +- Reinforces **P7** and **P8**: claims are evidenced assertions. + +## Terminology Conflicts + +- **Credential vs. Credential (auth)**: VC vs. password/OIDC token. +- **Subject**: VC subject vs. OIDC sub. +- **Claim vs. Attribute**: VC claim vs. directory/LDAP attribute. +- **Holder vs. Account**: holder is possession role, not login account. +- **Verifier vs. RP**: overlapping but VC adds cryptographic verification step. + +## Candidate Canonical Mappings + +| VC Data Model concept | Candidate canonical concept | +| --- | --- | +| Verifiable Credential | Credential | +| credentialSubject claim | Claim | +| Issuer | Issuer Scope + Trust Relationship | +| Holder | Actor / Account (possession role) | +| Verifier | Relying party / verifier Scope | +| Subject | Actor or Identifier target | +| Proof | Evidence Source (cryptographic) | +| StatusList entry | Lifecycle State (revoked/suspended) | +| validFrom / validUntil | Temporal bounds on Claim | +| Presentation | Credential bundle (operational) | + +## Open Questions + +- Should canon treat VC as Credential subtype or parallel Claim container? +- How should membership VCs map to Membership Relationship vs. Claim only? +- Does selective disclosure require Persona or Scoped Identifier linkage? +- Should issuer DID vs. issuer URL be standardized Identifier forms? + +## References + +- W3C VC Data Model 2.0 — https://www.w3.org/TR/vc-data-model-2.0/ +- VC Data Model 1.1 (widely deployed) — https://www.w3.org/TR/vc-data-model/ +- Status List 2021 — https://www.w3.org/TR/vc-status-list-2021/ \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/scenarios/ScenarioTests.md b/infospace/assimilation/canon-federation/source/scenarios/ScenarioTests.md new file mode 100644 index 0000000..42d260b --- /dev/null +++ b/infospace/assimilation/canon-federation/source/scenarios/ScenarioTests.md @@ -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. diff --git a/infospace/assimilation/canon-federation/source/terminology/TerminologyConflictMap.md b/infospace/assimilation/canon-federation/source/terminology/TerminologyConflictMap.md new file mode 100644 index 0000000..2fee6f3 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/terminology/TerminologyConflictMap.md @@ -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. \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/source/terminology/TerminologyInventory.md b/infospace/assimilation/canon-federation/source/terminology/TerminologyInventory.md new file mode 100644 index 0000000..4b1cd91 --- /dev/null +++ b/infospace/assimilation/canon-federation/source/terminology/TerminologyInventory.md @@ -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. \ No newline at end of file diff --git a/infospace/assimilation/canon-federation/views/family-area.md b/infospace/assimilation/canon-federation/views/family-area.md new file mode 100644 index 0000000..fcbd33d --- /dev/null +++ b/infospace/assimilation/canon-federation/views/family-area.md @@ -0,0 +1,111 @@ +# family-area 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/verifiable-claims/vc-data-model-2.md](../source/research/verifiable-claims/vc-data-model-2.md) — dae7bc679c6c. +- [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 + + +### S06. Family With Guardian And Dependent Accounts + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 71–82; SHA-256 `a3f0705f7168974632f544891e08403fdcdaa2b205f40ae899bc0483af445106`. +Historical wording; this is not a current model definition. + +```text +## 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. + +``` + +### 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. + +``` + +### 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. | +``` + +### 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. | +``` + +### family + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 89–89; SHA-256 `b1494107b59c6ed89546a86eeb073414ee575a2376f3c695ecb23b5c2668e32d`. +Historical wording; this is not a current model definition. + +```text +| family | Family or Household | proposal, GDPR-sensitive | Guardian/dependent semantics; privacy-sensitive. | +``` + +### household + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 90–90; SHA-256 `0719bdf791feaaf5a70b1990b2ea38f730312c1addbbdd6562ddb0b7abbb75ed`. +Historical wording; this is not a current model definition. + +```text +| household | Family or Household | family accounts | Co-residence unit; may differ from legal family. | +``` + +### 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. | +``` diff --git a/infospace/assimilation/canon-federation/views/itc-access.md b/infospace/assimilation/canon-federation/views/itc-access.md new file mode 100644 index 0000000..e43e2a7 --- /dev/null +++ b/infospace/assimilation/canon-federation/views/itc-access.md @@ -0,0 +1,301 @@ +# itc-access 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/authentication-federation/nist-800-63-4.md](../source/research/authentication-federation/nist-800-63-4.md) — 8697b739399c. +- [research/authentication-federation/oidc-core-subject-identifiers.md](../source/research/authentication-federation/oidc-core-subject-identifiers.md) — e1a0bf8a2754. +- [research/authentication-federation/saml-nameid-federation.md](../source/research/authentication-federation/saml-nameid-federation.md) — 394457cf75d2. +- [research/authentication-federation/shared-signals-caep-risc.md](../source/research/authentication-federation/shared-signals-caep-risc.md) — 7303fd449a83. +- [research/authorization-relationships/cedar-principal-action-resource-context.md](../source/research/authorization-relationships/cedar-principal-action-resource-context.md) — 1932a8632dd3. +- [research/authorization-relationships/cerbos-abac-derived-roles.md](../source/research/authorization-relationships/cerbos-abac-derived-roles.md) — c35f15042d45. +- [research/authorization-relationships/openfga-modeling.md](../source/research/authorization-relationships/openfga-modeling.md) — e2d03ddfa7be. +- [research/authorization-relationships/zanzibar-rebac.md](../source/research/authorization-relationships/zanzibar-rebac.md) — 1f736195ab4b. +- [research/identity-provisioning/keycloak-organizations.md](../source/research/identity-provisioning/keycloak-organizations.md) — 09c43cdc9ecf. +- [research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md](../source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md) — c3f3323a3f25. +- [research/identity-provisioning/ory-kratos-keto.md](../source/research/identity-provisioning/ory-kratos-keto.md) — 5cd12c38f8d3. +- [research/identity-provisioning/scim-rfc7643-rfc7644.md](../source/research/identity-provisioning/scim-rfc7643-rfc7644.md) — c5c03952ac2f. +- [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 + + +### S01. Single Person With One Local Account + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 13–24; SHA-256 `0040dd866009ad1199e89f89267e3aab86894859f6ae6d07f393e4f0b8cdb6f5`. +Historical wording; this is not a current model definition. + +```text +## 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. + +``` + +### Conflict: User + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 6–28; SHA-256 `03cc685a840d47b36bf124aa8c1465216dfcb1c463f911dbe5e934b7fa81e3b6`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 29–43; SHA-256 `acf3297ff3ac425a535639c97c8e9368833d0e4e78225679263bcd5ab6ecbbed`. +Historical wording; this is not a current model definition. + +```text +## 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: Subject, Principal, Actor + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 60–79; SHA-256 `5f7282450703c7ab38c6d6b044bf99731c274974dd8ece1785de74bdc1365feb`. +Historical wording; this is not a current model definition. + +```text +## 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: Identifier, Credential, Claim + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 150–162; SHA-256 `ff9f6502a126229aa65ea20817e698285a74df128aa35ea286cf24f87462216e`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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: Issuer + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 191–203; SHA-256 `e7ca901947a8931fb1c427fa217f22bac361c15aa6c57da67580d799676980a7`. +Historical wording; this is not a current model definition. + +```text +## 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. + +``` + +### subject + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 25–25; SHA-256 `904b2af8c84d271ad315098c387b00d51eef6463d3d4343c16469844f65f9cd5`. +Historical wording; this is not a current model definition. + +```text +| subject | Authenticated Subject | OIDC, SAML, SSF events | Protocol/security view after issuer identification. Not Actor or Principal. | +``` + +### principal + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 26–26; SHA-256 `3ab8b5d536f3e1da3f172f95431751a51786291480592b7e2e784338466657ba`. +Historical wording; this is not a current model definition. + +```text +| principal | Authorization Principal | Cedar, Cerbos, Zanzibar, OpenFGA | Decision-engine participant. OpenFGA `user:` prefix is not a human user. | +``` + +### 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. | +``` + +### representation + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 102–102; SHA-256 `1a93d64d4e3f608806754d3889b9655d0083e2f5ce92db14780c8513fbfff419`. +Historical wording; this is not a current model definition. + +```text +| representation | Representation Relationship | SCIM manager, DID controller | Acting on behalf of another. DID controller may differ from subject. | +``` + +### pairwise subject + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 115–115; SHA-256 `508a529137ad7a0e7f1409063b306cad3bb1f8aa1c9c15f179c21ab657f46d33`. +Historical wording; this is not a current model definition. + +```text +| pairwise subject | Scoped Identifier | OIDC | RP-specific sub preventing global correlation. | +``` + +### relationship tuple + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 116–116; SHA-256 `3cab1bbb2dfc5afd3dcde230e104ddd95e67ccddc46fb2bbcc38f99103a55f49`. +Historical wording; this is not a current model definition. + +```text +| relationship tuple | Relationship Tuple | Zanzibar, OpenFGA, Keto | Authz projection: subject#relation@object. | +``` + +### 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. | +``` + +### holder + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 128–128; SHA-256 `1e57bb144bb8a072a4180be14a8a91f8126c4f958397a8fd62e12c63db8806b6`. +Historical wording; this is not a current model definition. + +```text +| holder | Actor (custody role) | VC, OpenID4VC | Party possessing VC; may differ from subject. | +``` + +### data subject + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 132–132; SHA-256 `2aae43d6df259e4678d0a2d27fcf4efd546ecd99201d1a3e573cef845e78a822`. +Historical wording; this is not a current model definition. + +```text +| data subject | Natural Person | GDPR | Identifiable natural person for privacy regulation. | +``` + +### tuple (authz) + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 135–135; SHA-256 `89a5e53a0468189c92022352aac36ccf34b62a8a34b49c13241eb5fa91aa830c`. +Historical wording; this is not a current model definition. + +```text +| tuple (authz) | Relationship Tuple | Zanzibar | Authorization fact, not social relationship. | +``` + +### userset + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 136–136; SHA-256 `6ad9832f81b69b4e039e5bb2c0e8751894d408412f573668619adfa74cde2e8c`. +Historical wording; this is not a current model definition. + +```text +| userset | Authorization Principal (indirect) | Zanzibar, OpenFGA | Subject referenced via relation chain. | +``` + +### 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. | +``` diff --git a/infospace/assimilation/canon-federation/views/itc-evid.md b/infospace/assimilation/canon-federation/views/itc-evid.md new file mode 100644 index 0000000..f0c82f8 --- /dev/null +++ b/infospace/assimilation/canon-federation/views/itc-evid.md @@ -0,0 +1,156 @@ +# itc-evid 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/authentication-federation/nist-800-63-4.md](../source/research/authentication-federation/nist-800-63-4.md) — 8697b739399c. +- [research/authentication-federation/oidc-core-subject-identifiers.md](../source/research/authentication-federation/oidc-core-subject-identifiers.md) — e1a0bf8a2754. +- [research/authentication-federation/saml-nameid-federation.md](../source/research/authentication-federation/saml-nameid-federation.md) — 394457cf75d2. +- [research/authentication-federation/shared-signals-caep-risc.md](../source/research/authentication-federation/shared-signals-caep-risc.md) — 7303fd449a83. +- [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/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md](../source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md) — 12585f844728. +- [research/entity-resolution-privacy/gdpr-pseudonymization.md](../source/research/entity-resolution-privacy/gdpr-pseudonymization.md) — de2bfcf7f52b. +- [research/entity-resolution-privacy/synonymity-assertions.md](../source/research/entity-resolution-privacy/synonymity-assertions.md) — 6ba40ec37221. +- [research/identity-provisioning/keycloak-organizations.md](../source/research/identity-provisioning/keycloak-organizations.md) — 09c43cdc9ecf. +- [research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md](../source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md) — c3f3323a3f25. +- [research/identity-provisioning/ory-kratos-keto.md](../source/research/identity-provisioning/ory-kratos-keto.md) — 5cd12c38f8d3. +- [research/identity-provisioning/scim-rfc7643-rfc7644.md](../source/research/identity-provisioning/scim-rfc7643-rfc7644.md) — c5c03952ac2f. +- [research/identity-provisioning/zitadel-organizations-projects.md](../source/research/identity-provisioning/zitadel-organizations-projects.md) — f4b1b6f4cce3. +- [research/verifiable-claims/did-core.md](../source/research/verifiable-claims/did-core.md) — cbe5fd46e093. +- [research/verifiable-claims/openid4vc.md](../source/research/verifiable-claims/openid4vc.md) — e6fcc0612146. +- [research/verifiable-claims/vc-data-model-2.md](../source/research/verifiable-claims/vc-data-model-2.md) — dae7bc679c6c. +- [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 + + +### S12. Weak Identity Match From Imported Data + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 140–150; SHA-256 `b5f26ea04922d59bfe1c7dd240a2348e4afc6cc45a257ea5dfbb733e614649d5`. +Historical wording; this is not a current model definition. + +```text +## 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. + +``` + +### 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. + +``` + +### 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. | +``` + +### 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. | +``` + +### arbitration award + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 68–68; SHA-256 `5631838512e0e0b5452b591adc1f4f77f380df18cecf4e6164dab0546207ef67`. +Historical wording; this is not a current model definition. + +```text +| arbitration award | Adjudication Outcome | AAA, ICC, JAMS | Adjudicated-tier dispute result. | +``` + +### court judgment + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 69–69; SHA-256 `ba21ec0155b991faea17beea69f8fbcaa4489f51e522ced3b2ded31fe06f4c3e`. +Historical wording; this is not a current model definition. + +```text +| court judgment | Adjudication Outcome | courts | Adjudicated-tier enforcement outcome. | +``` + +### kyc / cip + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 78–78; SHA-256 `489f788d80be6f2e796a116a2338e697145669829f355c121e18975dbbfbf13f`. +Historical wording; this is not a current model definition. + +```text +| kyc / cip | Evidence Source + Assurance | FinCEN, FATF | Regulated commercial identity onboarding. | +``` + +### evidence + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 105–105; SHA-256 `f6a2c13eb05ca9f7299d1e704815b2dbf0a2d0c8ca75a032bc4aaca087b28b86`. +Historical wording; this is not a current model definition. + +```text +| evidence | Evidence Source | NIST proofing, entity resolution, SSF | Supports claims and synonymity. SSF SET = event Evidence Source. | +``` + +### 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. | +``` diff --git a/infospace/assimilation/canon-federation/views/itc-gov.md b/infospace/assimilation/canon-federation/views/itc-gov.md new file mode 100644 index 0000000..4c6cd12 --- /dev/null +++ b/infospace/assimilation/canon-federation/views/itc-gov.md @@ -0,0 +1,77 @@ +# itc-gov 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. +- [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 + + +### 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. + +``` + +### 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. | +``` + +### 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. | +``` diff --git a/infospace/assimilation/canon-federation/views/itc-ident.md b/infospace/assimilation/canon-federation/views/itc-ident.md new file mode 100644 index 0000000..2b224eb --- /dev/null +++ b/infospace/assimilation/canon-federation/views/itc-ident.md @@ -0,0 +1,1439 @@ +# itc-ident 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/authentication-federation/nist-800-63-4.md](../source/research/authentication-federation/nist-800-63-4.md) — 8697b739399c. +- [research/authentication-federation/oidc-core-subject-identifiers.md](../source/research/authentication-federation/oidc-core-subject-identifiers.md) — e1a0bf8a2754. +- [research/authentication-federation/saml-nameid-federation.md](../source/research/authentication-federation/saml-nameid-federation.md) — 394457cf75d2. +- [research/authentication-federation/shared-signals-caep-risc.md](../source/research/authentication-federation/shared-signals-caep-risc.md) — 7303fd449a83. +- [research/authorization-relationships/cedar-principal-action-resource-context.md](../source/research/authorization-relationships/cedar-principal-action-resource-context.md) — 1932a8632dd3. +- [research/authorization-relationships/cerbos-abac-derived-roles.md](../source/research/authorization-relationships/cerbos-abac-derived-roles.md) — c35f15042d45. +- [research/authorization-relationships/openfga-modeling.md](../source/research/authorization-relationships/openfga-modeling.md) — e2d03ddfa7be. +- [research/authorization-relationships/zanzibar-rebac.md](../source/research/authorization-relationships/zanzibar-rebac.md) — 1f736195ab4b. +- [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/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md](../source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md) — 12585f844728. +- [research/entity-resolution-privacy/gdpr-pseudonymization.md](../source/research/entity-resolution-privacy/gdpr-pseudonymization.md) — de2bfcf7f52b. +- [research/entity-resolution-privacy/synonymity-assertions.md](../source/research/entity-resolution-privacy/synonymity-assertions.md) — 6ba40ec37221. +- [research/identity-provisioning/keycloak-organizations.md](../source/research/identity-provisioning/keycloak-organizations.md) — 09c43cdc9ecf. +- [research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md](../source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md) — c3f3323a3f25. +- [research/identity-provisioning/ory-kratos-keto.md](../source/research/identity-provisioning/ory-kratos-keto.md) — 5cd12c38f8d3. +- [research/identity-provisioning/scim-rfc7643-rfc7644.md](../source/research/identity-provisioning/scim-rfc7643-rfc7644.md) — c5c03952ac2f. +- [research/identity-provisioning/zitadel-organizations-projects.md](../source/research/identity-provisioning/zitadel-organizations-projects.md) — f4b1b6f4cce3. +- [research/social-community-graphs/activitypub-actors-followers.md](../source/research/social-community-graphs/activitypub-actors-followers.md) — 8b28bfc385d1. +- [research/social-community-graphs/foaf-agent-person-group-onlineaccount.md](../source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md) — 4131e7685da5. +- [research/social-community-graphs/schema-org-person-organization-membership.md](../source/research/social-community-graphs/schema-org-person-organization-membership.md) — bc274f7cf1ff. +- [research/social-community-graphs/webid-solid-profile.md](../source/research/social-community-graphs/webid-solid-profile.md) — abf0c62e23b0. +- [research/verifiable-claims/did-core.md](../source/research/verifiable-claims/did-core.md) — cbe5fd46e093. +- [research/verifiable-claims/openid4vc.md](../source/research/verifiable-claims/openid4vc.md) — e6fcc0612146. +- [research/verifiable-claims/vc-data-model-2.md](../source/research/verifiable-claims/vc-data-model-2.md) — dae7bc679c6c. +- [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 + + +### S01. Single Person With One Local Account + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 13–24; SHA-256 `0040dd866009ad1199e89f89267e3aab86894859f6ae6d07f393e4f0b8cdb6f5`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 25–35; SHA-256 `69cabdc1680936fffd25378d9a1fcaa129c258eeca03663a3c9e9718def6fd59`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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. + +``` + +### S06. Family With Guardian And Dependent Accounts + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 71–82; SHA-256 `a3f0705f7168974632f544891e08403fdcdaa2b205f40ae899bc0483af445106`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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. + +``` + +### S08. Community With Members, Moderators, And Followers + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 94–105; SHA-256 `83de4820c3662f015970f7360ceb1278bca3fa8bf63037826316d63643e580ae`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 106–116; SHA-256 `fd342efc3924c194784c48d937333426addcac7e8404a1834881e284937777b3`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 117–127; SHA-256 `b7671fae9cd9c0c2070588558e72fc34e6a40a449b088738761253df23955228`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 128–139; SHA-256 `c26e3ad239e21e320a65dcee09b95260db582d26ff08c3b7cf537577c9501275`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 140–150; SHA-256 `b5f26ea04922d59bfe1c7dd240a2348e4afc6cc45a257ea5dfbb733e614649d5`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 151–161; SHA-256 `4d4ec21f4e4a70bd1095e0baa7691c39497f970fab42a073683a0200c5ee5949`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 162–172; SHA-256 `01618fb5fc15400461ceb46402bc5c908fdd3555c3e2aa04adb964faf466bab1`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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: User + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 6–28; SHA-256 `03cc685a840d47b36bf124aa8c1465216dfcb1c463f911dbe5e934b7fa81e3b6`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 29–43; SHA-256 `acf3297ff3ac425a535639c97c8e9368833d0e4e78225679263bcd5ab6ecbbed`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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: Subject, Principal, Actor + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 60–79; SHA-256 `5f7282450703c7ab38c6d6b044bf99731c274974dd8ece1785de74bdc1365feb`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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: Group, Role, Team, Community + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 100–119; SHA-256 `0a8cd0ebc16563b59014cbaf3e026ae6633f24aa8f26dabe1c2bfebf70b4f3d4`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 120–133; SHA-256 `59c522c4fa0602246033c3d4bf91b91d718119bc116ad60df9f9c7fda616cefc`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 134–149; SHA-256 `7e0380ec397e1c991a40391d366913e7087b4a3f45d416b92c068e34a71450b8`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 150–162; SHA-256 `ff9f6502a126229aa65ea20817e698285a74df128aa35ea286cf24f87462216e`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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: Credential (Auth) vs. Verifiable Credential + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 178–190; SHA-256 `ba22d9bb343b383c489c3887a36dafea1c1b93cbed3d9b799727eb5f2a03ecac`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 191–203; SHA-256 `e7ca901947a8931fb1c427fa217f22bac361c15aa6c57da67580d799676980a7`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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. + +``` + +### user + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 19–19; SHA-256 `0a171d978928b2781f3b7b7f28485e6d6ec53e8fe7808f42629ea7375101ec3c`. +Historical wording; this is not a current model definition. + +```text +| user | Convenience label only | SCIM, LDAP, Keycloak, ZITADEL, apps | Overloaded. Map by context: SCIM/LDAP User → Identity Record; Keycloak/ZITADEL User → Account. | +``` + +### account + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 20–20; SHA-256 `1901d71fbc43e06b5134161854710bf0f653141bc626bf67d95d4cfd3db0e10f`. +Historical wording; this is not a current model definition. + +```text +| account | Account | SCIM, LDAP posixAccount, FOAF OnlineAccount, Keycloak | Operational access record in a scope. FOAF separates account from person explicitly. | +``` + +### identity + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 21–21; SHA-256 `779546411717fd6156a3dd3a39eb0869c68d36b10b64fff51e2dc4db9031b422`. +Historical wording; this is not a current model definition. + +```text +| identity | Identity Record or Claim | Kratos, OIDC, DID, VC, apps | Kratos Identity = traits + credentials. Avoid bare `identity` as root noun. | +``` + +### identifier + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 22–22; SHA-256 `53e9132ea78c16e691b6b0e05371a99aed178d52df6d1e48704b43a40f3193cc`. +Historical wording; this is not a current model definition. + +```text +| 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 + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 23–23; SHA-256 `e4d333b9c4c275397cbeccd5e0b2eed27b457dff23cca482b42a086885cd2578`. +Historical wording; this is not a current model definition. + +```text +| scoped identifier | Scoped Identifier | OIDC pairwise, SAML transient, pseudonyms | Meaning limited to RP, sector, tenant, or session. | +``` + +### credential + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 24–24; SHA-256 `c9d2a6c53d2e11f93234cc4fffde742aa82990efc2cb6b83024b929616030248`. +Historical wording; this is not a current model definition. + +```text +| credential | Credential | NIST, Kratos, OIDC token, VC, DID keys | Proof material. Distinguish VC (claim container) from password/WebAuthn. | +``` + +### principal + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 26–26; SHA-256 `3ab8b5d536f3e1da3f172f95431751a51786291480592b7e2e784338466657ba`. +Historical wording; this is not a current model definition. + +```text +| principal | Authorization Principal | Cedar, Cerbos, Zanzibar, OpenFGA | Decision-engine participant. OpenFGA `user:` prefix is not a human user. | +``` + +### end-user + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 27–27; SHA-256 `74c3cc32b9d4ce44cf2b61a4673ea73073be69d31900f302937110ab74c43c4c`. +Historical wording; this is not a current model definition. + +```text +| end-user | Natural Person (inferred) | OIDC | OIDC names the human implicitly; does not model as entity. | +``` + +### profile + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 28–28; SHA-256 `f332b51b59675a5ce79ed19eb9b6ab8d7bbe4e1d651f56099068a1596669db24`. +Historical wording; this is not a current model definition. + +```text +| profile | Profile | FOAF, WebID/Solid, SCIM attrs, ActivityPub | Presentation or attribute surface. Solid profile is user-controlled data. | +``` + +### persona + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 29–29; SHA-256 `8815441b1d1f825051d8208b5a126c28d1b0a0cec1dc92fc6550b6a79f38eb2d`. +Historical wording; this is not a current model definition. + +```text +| persona | Persona | proposal, privacy patterns | Contextual presentation; pairwise/pseudonymous profiles map here. | +``` + +### bot + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 31–31; SHA-256 `827962be82a98f1c17ffb62c4f4cd943a66a753d67e5cca0fc8ef77756e8ffad`. +Historical wording; this is not a current model definition. + +```text +| bot | Artificial Agent | ActivityPub Service, apps | Automated actor; may use Service Account. | +``` + +### service account + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 32–32; SHA-256 `64c7a3372e658872cc40799f62c5c3d7d9a8b319340a8134a829ee0a6f6082b0`. +Historical wording; this is not a current model definition. + +```text +| service account | Service Account | Keycloak, ZITADEL machine user, Kratos | Non-human login or API identity. ZITADEL machine user, Kratos service patterns. | +``` + +### machine user + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 33–33; SHA-256 `5012066796bdd788383852ec7bc34a06a2fa82433dac3afbeca5f625f8b8df13`. +Historical wording; this is not a current model definition. + +```text +| machine user | Service Account | ZITADEL | Product term for non-human org identity. | +``` + +### 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. | +``` + +### 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. | +``` + +### 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 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. | +``` + +### 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. | +``` + +### 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, …). | +``` + +### 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. | +``` + +### 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. | +``` + +### fluid identity + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 80–80; SHA-256 `3c171e79b1f6966812977a4de526300db7dea729ac4bef4f86737575e836d54e`. +Historical wording; this is not a current model definition. + +```text +| fluid identity | Persona / weak binding | theory | Low commercial stake; intentional mutability. | +``` + +### tenant + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 82–82; SHA-256 `8ea48ff21a23148aea6923f844adb270f01af86f334bd9fd2e6642e6ac35dc40`. +Historical wording; this is not a current model definition. + +```text +| tenant | Tenant | ZITADEL org, SaaS, Keycloak (informal) | Administrative/isolation scope. Keycloak realm sometimes called tenant. | +``` + +### realm + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 83–83; SHA-256 `faaa0b5ee2eee0c243c2eda3a90df392858d974bfc1df02422a8df0b71276980`. +Historical wording; this is not a current model definition. + +```text +| realm | Realm | Keycloak | Hard identity/admin namespace. Candidate Scope specialization. | +``` + +### scope + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 84–84; SHA-256 `05dc1d57cb500d7c30328b063db392cb4e4be19479c2596f739b474e640ec6bb`. +Historical wording; this is not a current model definition. + +```text +| scope | Scope | OIDC, Cerbos, OpenFGA store, proposal | Boundary for meaning, policy, or correlation. | +``` + +### namespace + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 85–85; SHA-256 `348ff0b2f98a4a7b53947188a958999ec7779c636bb8fcca133075dabe031750`. +Historical wording; this is not a current model definition. + +```text +| namespace | Scope | LDAP dc, Keto/OpenFGA, DID method | Naming or authorization partition. | +``` + +### instance + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 86–86; SHA-256 `a091b4ac6ab9f52f953832634e1f942fd000ead687ce46a57d4983fd7e79f33d`. +Historical wording; this is not a current model definition. + +```text +| instance | Scope | ZITADEL | Deployment-level boundary above organizations. | +``` + +### project + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 87–87; SHA-256 `329b17d1d24ed30b039ced9d3e3277cb23e49ea59f4c7ac7acf9ddae3e83dfc7`. +Historical wording; this is not a current model definition. + +```text +| project | Application Scope | ZITADEL | Application/product container within org. | +``` + +### role + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 93–93; SHA-256 `bf4b3c078725e3a9b4c661c358df673204d21865de9386223c00682de7a76d2a`. +Historical wording; this is not a current model definition. + +```text +| role | Role | Keycloak, ZITADEL, Cedar, Cerbos, Schema.org OrganizationRole | Capability bundle or relationship label. Cerbos derived role may hide Ownership. | +``` + +### grant + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 94–94; SHA-256 `ca2c9b2882bd176716d5f40b570f7d142e820881529353bdd9829ca2fff5acfd`. +Historical wording; this is not a current model definition. + +```text +| grant | Role assignment | ZITADEL | Project role assignment; map to Delegation-like relationship. | +``` + +### member + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 95–95; SHA-256 `a6600f7dd9604883a0c366467ad89a90ceee68aefbe6aca09067ada754baae23`. +Historical wording; this is not a current model definition. + +```text +| member | Membership Relationship | SCIM, LDAP, FOAF, Schema.org, Zanzibar | Relationship edge, not a noun for the participant. | +``` + +### affiliation + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 96–96; SHA-256 `06170379083ad57eb7ec1dee172d3f2e370140f32c1e8b3ccf5a700c3fffdb66`. +Historical wording; this is not a current model definition. + +```text +| affiliation | Affiliation Relationship | Schema.org, FOAF knows | Looser than membership. FOAF knows is weak social affiliation. | +``` + +### follower + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 97–97; SHA-256 `62256899610e66f10a97b6f7011d52ff02ce79f6d4060c0d403bc8a520f3e6ff`. +Historical wording; this is not a current model definition. + +```text +| follower | Following Relationship | ActivityPub | Directed social subscription; not membership or authz. | +``` + +### follow + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 98–98; SHA-256 `1c77e34bdf1206d046ef8eee40d4a94393faf67a5af97821834b12b9f9bcea81`. +Historical wording; this is not a current model definition. + +```text +| follow | Following Relationship | ActivityPub | Activity establishing follower edge. | +``` + +### owner + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 99–99; SHA-256 `78b48373de87a79fc4d67b68b30f7a16c2fbab573b24ddd44f8cfb13487e6896`. +Historical wording; this is not a current model definition. + +```text +| owner | Ownership Relationship | Zanzibar, Cerbos derived | Control/responsibility. Cerbos may encode as attribute not relationship. | +``` + +### administrator + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 100–100; SHA-256 `8325a4edc6753be9dadce60ad0fcfd5b46ad0528e0efc0ea9ad3a8d116a93f76`. +Historical wording; this is not a current model definition. + +```text +| administrator | Administration Relationship | IAM, ZITADEL grants | Delegated management in scope. | +``` + +### delegation + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 101–101; SHA-256 `538948038bf8b7c7e6c562238017e8efd2c4d2112e542bc9cb7d1d47d521df09`. +Historical wording; this is not a current model definition. + +```text +| delegation | Delegation Relationship | Cedar context, agents | Bounded authority grant. Cedar context may carry delegatedBy. | +``` + +### representation + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 102–102; SHA-256 `1a93d64d4e3f608806754d3889b9655d0083e2f5ce92db14780c8513fbfff419`. +Historical wording; this is not a current model definition. + +```text +| representation | Representation Relationship | SCIM manager, DID controller | Acting on behalf of another. DID controller may differ from subject. | +``` + +### trust + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 103–103; SHA-256 `3a652a6f5721c7c3616ea4fb93db81e7514538d1f2052eb00cd3333e881dd3c6`. +Historical wording; this is not a current model definition. + +```text +| trust | Trust Relationship | federation, VC, DID | Reliance on issuer/verifier; federation metadata trust. | +``` + +### claim + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 104–104; SHA-256 `1ce7bcc854285f598ad1927182e0821d7db9e9fb2a09cbd0d7e743549ca2b37e`. +Historical wording; this is not a current model definition. + +```text +| claim | Claim | OIDC, SAML attributes, VC | Statement by issuer. SAML AttributeStatement → Claim. | +``` + +### assurance + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 106–106; SHA-256 `130c61dcb0687328ed992999688e1f37c07958e258a96db49787d1d9fce90dad`. +Historical wording; this is not a current model definition. + +```text +| assurance | Assurance Level | NIST IAL/AAL/FAL | Orthogonal identity, authentication, federation confidence. | +``` + +### identifier binding + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 107–107; SHA-256 `384043ffa3353df53a5a4769971853cedccf232fe72d1a8044d1dd3b53cfc378`. +Historical wording; this is not a current model definition. + +```text +| identifier binding | Identifier Binding | OIDC iss+sub, WebID-OIDC, SAML | Assertion that identifier refers to target in scope. | +``` + +### synonymity + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 108–108; SHA-256 `58d9d36c18fda3e8df9a74af3c2fae1f3103a6f62df39d0b5db951ce3b6fe5e3`. +Historical wording; this is not a current model definition. + +```text +| synonymity | Synonymity Assertion | entity resolution, OIDC linking, schema.org sameAs | Scoped evidenced equivalence. sameAs is weak by default. | +``` + +### weak match + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 109–109; SHA-256 `3f35848a32547aa86fe3ec9e7e755e4fd6392d71ef3d683953df7b08a5c1dd95`. +Historical wording; this is not a current model definition. + +```text +| weak match | Weak Synonymity Assertion | probabilistic matching | Probabilistic link; never destructive merge. | +``` + +### strong link + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 110–110; SHA-256 `5f0902c8bed0e10535d0f76427677ac135a5c09b10b223aa49dbe05d8fc6c468`. +Historical wording; this is not a current model definition. + +```text +| strong link | Strong Synonymity Assertion | deterministic match, verified linking | Authoritative or verified; still scoped. | +``` + +### same_as + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 111–111; SHA-256 `9236ea638789b858a465b91a73dfb82c2f91434f04d7fe3bb0bcdfa623c6e951`. +Historical wording; this is not a current model definition. + +```text +| same_as | Synonymity Assertion (strong) | synonymity model | High-confidence equivalence relation type. | +``` + +### probably_same_as + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 112–112; SHA-256 `1ce7ba621eeb91881b9be16c1e87ce7a78a2a1dd26a0ff7da82b6d3fa04f2069`. +Historical wording; this is not a current model definition. + +```text +| probably_same_as | Synonymity Assertion (weak) | probabilistic matching | Probabilistic equivalence relation type. | +``` + +### linked_to + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 113–113; SHA-256 `33b998acec8a52176199992c4d0f5d1ca9016d586682e8fa5d18dbdd27957181`. +Historical wording; this is not a current model definition. + +```text +| linked_to | Synonymity Assertion (operational) | account linking | Convenience link without semantic sameness claim. | +``` + +### pseudonym + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 114–114; SHA-256 `01ebfceff32122591e256df20f312f68881ef3e6d4ebfc5738cdfa4cc28d3d69`. +Historical wording; this is not a current model definition. + +```text +| pseudonym | Pseudonymous Identifier | GDPR, OIDC pairwise | Limits cross-scope correlation. | +``` + +### pairwise subject + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 115–115; SHA-256 `508a529137ad7a0e7f1409063b306cad3bb1f8aa1c9c15f179c21ab657f46d33`. +Historical wording; this is not a current model definition. + +```text +| pairwise subject | Scoped Identifier | OIDC | RP-specific sub preventing global correlation. | +``` + +### relationship tuple + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 116–116; SHA-256 `3cab1bbb2dfc5afd3dcde230e104ddd95e67ccddc46fb2bbcc38f99103a55f49`. +Historical wording; this is not a current model definition. + +```text +| relationship tuple | Relationship Tuple | Zanzibar, OpenFGA, Keto | Authz projection: subject#relation@object. | +``` + +### 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. | +``` + +### lifecycle state + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 118–118; SHA-256 `b39c636369a3c10a22a75c8c686d145f54addfd5720ae90da49321571406d6c6`. +Historical wording; this is not a current model definition. + +```text +| lifecycle state | Lifecycle State | SCIM active, SSF/RISC events, VC status | Applies to records, credentials, relationships, assertions. | +``` + +### subscriber + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 119–119; SHA-256 `778a574609c40787ae9fec045e791faafd3d39b49fd187b3c10bc6dad0133e4c`. +Historical wording; this is not a current model definition. + +```text +| subscriber | Account / Identity Record | NIST | Enrolled party at CSP; not synonymous with Natural Person until IAL binding. | +``` + +### issuer + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 120–120; SHA-256 `036456fa64e621bcbf2df81938ec5e5bce4af61c757456935846ef3c2c026282`. +Historical wording; this is not a current model definition. + +```text +| issuer | Scope + Trust Relationship | OIDC iss, VC issuer, SAML IdP | Namespace authority for identifiers and claims. | +``` + +### relying party + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 121–121; SHA-256 `36a83f3b965a6b2e71938360eb02a5ed64bd665797952d5f592b535e73cfa436`. +Historical wording; this is not a current model definition. + +```text +| relying party | Scope | OIDC RP, SAML SP, NIST | Consumer of assertions; RP-local account binding. | +``` + +### nameid + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 122–122; SHA-256 `dbe31e5c4483f1b3f8c83c7abe1239137c7da04456f601d8550035a0c308df12`. +Historical wording; this is not a current model definition. + +```text +| nameid | Identifier | SAML | Format attribute determines persistence and privacy semantics. | +``` + +### distinguished name + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 123–123; SHA-256 `ac1bda1aaeb885049b4ae754e1a507b1e872321069f4ca1a3fc3617660d90454`. +Historical wording; this is not a current model definition. + +```text +| distinguished name | Identifier | LDAP | Compound locator in directory namespace. | +``` + +### externalid + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 124–124; SHA-256 `e1872cf38aa8e72a824036d017710553cf8ea6f990ef05217c2e972e77c6a978`. +Historical wording; this is not a current model definition. + +```text +| externalid | Identifier | SCIM | Client-supplied cross-system correlation key. | +``` + +### traits + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 125–125; SHA-256 `aadb34d5ce8bc3500c5a4d49641d87b11b5da9a481b27dbe0d436d5c0e95117f`. +Historical wording; this is not a current model definition. + +```text +| traits | Profile attributes | Kratos | Schema-validated identity attributes. | +``` + +### verification method + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 126–126; SHA-256 `ade6d356c8a8d8db36f1991f72e711738d9281166feda19b6bf5a5ef341d2f10`. +Historical wording; this is not a current model definition. + +```text +| verification method | Credential | DID Core | Cryptographic key in DID document. | +``` + +### verifiable credential + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 127–127; SHA-256 `10b80fe4d8c1fd5880c5fb3f626bfff061b2fa2457d93bcaeaa9a6c5d27a69d3`. +Historical wording; this is not a current model definition. + +```text +| verifiable credential | Credential + Claim | VC Data Model | Signed claim set; distinct from login credential. | +``` + +### verifier + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 129–129; SHA-256 `d37d10d4b1113114369aa128754a243e56f9ee71e5f95d5d9f966d75fe94088b`. +Historical wording; this is not a current model definition. + +```text +| verifier | Scope (evaluation role) | VC, OpenID4VC | Validates presentations. | +``` + +### did + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 130–130; SHA-256 `4de4b5bba75e89eb1ad4dc0525dc0eeb3eb1102e26c3535c0e85c41a68a68551`. +Historical wording; this is not a current model definition. + +```text +| did | Identifier | DID Core | Decentralized identifier with method-specific resolution. | +``` + +### webid + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 131–131; SHA-256 `e08c6ed7932919efd4c8f8ae55161be7a02e983d667cf3359fcff0affde44a1b`. +Historical wording; this is not a current model definition. + +```text +| webid | Identifier | WebID/Solid | HTTP URI identifying agent with dereferenceable profile. | +``` + +### pseudonymization + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 133–133; SHA-256 `157015a6434ede26ec98e5b223c0d07e1cbf3f9e791ede4c11b8b2958bb67963`. +Historical wording; this is not a current model definition. + +```text +| pseudonymization | Processing pattern | GDPR | Technique; maps to Scoped Identifier + separated re-id key. | +``` + +### tuple (authz) + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 135–135; SHA-256 `89a5e53a0468189c92022352aac36ccf34b62a8a34b49c13241eb5fa91aa830c`. +Historical wording; this is not a current model definition. + +```text +| tuple (authz) | Relationship Tuple | Zanzibar | Authorization fact, not social relationship. | +``` + +### derived role + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 137–137; SHA-256 `cbfaa9a627d2d32e194e4301e908fd193eb67c788ac3afad98079ce92e898fce`. +Historical wording; this is not a current model definition. + +```text +| derived role | Role (computed) | Cerbos | Role from attributes; should trace to Relationship when possible. | +``` + +### 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. | +``` + +### sameas + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 139–139; SHA-256 `be040500605effc4252c681b4b06d22cc0a7f37fbf622b0987690f4f8d39c86a`. +Historical wording; this is not a current model definition. + +```text +| sameas | Weak Synonymity Assertion | Schema.org | Informal web equivalence; not strong link without evidence. | +``` + +### assurance level change + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 141–141; SHA-256 `1b1531452b8b67df5a400492a351662c05da740832cc507356df0f1414b40c2b`. +Historical wording; this is not a current model definition. + +```text +| assurance level change | Assurance Level update | SSF/CAEP | Event affecting IAL/AAL/FAL metadata. | +``` diff --git a/infospace/assimilation/canon-federation/views/itc-org.md b/infospace/assimilation/canon-federation/views/itc-org.md new file mode 100644 index 0000000..5b9a80c --- /dev/null +++ b/infospace/assimilation/canon-federation/views/itc-org.md @@ -0,0 +1,905 @@ +# itc-org 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/authorization-relationships/cedar-principal-action-resource-context.md](../source/research/authorization-relationships/cedar-principal-action-resource-context.md) — 1932a8632dd3. +- [research/authorization-relationships/cerbos-abac-derived-roles.md](../source/research/authorization-relationships/cerbos-abac-derived-roles.md) — c35f15042d45. +- [research/authorization-relationships/openfga-modeling.md](../source/research/authorization-relationships/openfga-modeling.md) — e2d03ddfa7be. +- [research/authorization-relationships/zanzibar-rebac.md](../source/research/authorization-relationships/zanzibar-rebac.md) — 1f736195ab4b. +- [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/ldap-rfc4519-inetorgperson-rfc2798.md](../source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md) — c3f3323a3f25. +- [research/identity-provisioning/ory-kratos-keto.md](../source/research/identity-provisioning/ory-kratos-keto.md) — 5cd12c38f8d3. +- [research/identity-provisioning/scim-rfc7643-rfc7644.md](../source/research/identity-provisioning/scim-rfc7643-rfc7644.md) — c5c03952ac2f. +- [research/identity-provisioning/zitadel-organizations-projects.md](../source/research/identity-provisioning/zitadel-organizations-projects.md) — f4b1b6f4cce3. +- [research/social-community-graphs/activitypub-actors-followers.md](../source/research/social-community-graphs/activitypub-actors-followers.md) — 8b28bfc385d1. +- [research/social-community-graphs/foaf-agent-person-group-onlineaccount.md](../source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md) — 4131e7685da5. +- [research/social-community-graphs/schema-org-person-organization-membership.md](../source/research/social-community-graphs/schema-org-person-organization-membership.md) — bc274f7cf1ff. +- [research/social-community-graphs/webid-solid-profile.md](../source/research/social-community-graphs/webid-solid-profile.md) — abf0c62e23b0. +- [research/verifiable-claims/did-core.md](../source/research/verifiable-claims/did-core.md) — cbe5fd46e093. +- [research/verifiable-claims/openid4vc.md](../source/research/verifiable-claims/openid4vc.md) — e6fcc0612146. +- [research/verifiable-claims/vc-data-model-2.md](../source/research/verifiable-claims/vc-data-model-2.md) — dae7bc679c6c. +- [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 + + +### S01. Single Person With One Local Account + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 13–24; SHA-256 `0040dd866009ad1199e89f89267e3aab86894859f6ae6d07f393e4f0b8cdb6f5`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 25–35; SHA-256 `69cabdc1680936fffd25378d9a1fcaa129c258eeca03663a3c9e9718def6fd59`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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. + +``` + +### S06. Family With Guardian And Dependent Accounts + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 71–82; SHA-256 `a3f0705f7168974632f544891e08403fdcdaa2b205f40ae899bc0483af445106`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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. + +``` + +### S08. Community With Members, Moderators, And Followers + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 94–105; SHA-256 `83de4820c3662f015970f7360ceb1278bca3fa8bf63037826316d63643e580ae`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 106–116; SHA-256 `fd342efc3924c194784c48d937333426addcac7e8404a1834881e284937777b3`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 117–127; SHA-256 `b7671fae9cd9c0c2070588558e72fc34e6a40a449b088738761253df23955228`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 128–139; SHA-256 `c26e3ad239e21e320a65dcee09b95260db582d26ff08c3b7cf537577c9501275`. +Historical wording; this is not a current model definition. + +```text +## 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. + +``` + +### 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: User + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 6–28; SHA-256 `03cc685a840d47b36bf124aa8c1465216dfcb1c463f911dbe5e934b7fa81e3b6`. +Historical wording; this is not a current model definition. + +```text +## 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: 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: Subject, Principal, Actor + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 60–79; SHA-256 `5f7282450703c7ab38c6d6b044bf99731c274974dd8ece1785de74bdc1365feb`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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: Group, Role, Team, Community + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 100–119; SHA-256 `0a8cd0ebc16563b59014cbaf3e026ae6633f24aa8f26dabe1c2bfebf70b4f3d4`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 120–133; SHA-256 `59c522c4fa0602246033c3d4bf91b91d718119bc116ad60df9f9c7fda616cefc`. +Historical wording; this is not a current model definition. + +```text +## 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 + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 134–149; SHA-256 `7e0380ec397e1c991a40391d366913e7087b4a3f45d416b92c068e34a71450b8`. +Historical wording; this is not a current model definition. + +```text +## 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: 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: Issuer + +Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 191–203; SHA-256 `e7ca901947a8931fb1c427fa217f22bac361c15aa6c57da67580d799676980a7`. +Historical wording; this is not a current model definition. + +```text +## 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 + +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. + +``` + +### actor + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 17–17; SHA-256 `6ceb7d60a09ca5471237860930d88dd8367e7bbda1cd4605eee58d89f9a5bd72`. +Historical wording; this is not a current model definition. + +```text +| actor | Actor | ActivityPub, FOAF, Cedar, proposal | Participation root. ActivityPub actor is server-hosted; FOAF Agent includes persons. | +``` + +### natural person + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 18–18; SHA-256 `973e4a0177d5241ce7090eb6e36e29cb8036bd3b23c3c4b793bfdc476ccbbb39`. +Historical wording; this is not a current model definition. + +```text +| natural person | Natural Person | FOAF, Schema.org, NIST, GDPR | Human being; FOAF Person and Schema.org Person align strongly. | +``` + +### account + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 20–20; SHA-256 `1901d71fbc43e06b5134161854710bf0f653141bc626bf67d95d4cfd3db0e10f`. +Historical wording; this is not a current model definition. + +```text +| account | Account | SCIM, LDAP posixAccount, FOAF OnlineAccount, Keycloak | Operational access record in a scope. FOAF separates account from person explicitly. | +``` + +### subject + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 25–25; SHA-256 `904b2af8c84d271ad315098c387b00d51eef6463d3d4343c16469844f65f9cd5`. +Historical wording; this is not a current model definition. + +```text +| subject | Authenticated Subject | OIDC, SAML, SSF events | Protocol/security view after issuer identification. Not Actor or Principal. | +``` + +### end-user + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 27–27; SHA-256 `74c3cc32b9d4ce44cf2b61a4673ea73073be69d31900f302937110ab74c43c4c`. +Historical wording; this is not a current model definition. + +```text +| end-user | Natural Person (inferred) | OIDC | OIDC names the human implicitly; does not model as entity. | +``` + +### agent + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 30–30; SHA-256 `30a826d21d04b01e4de5648711bdd38e1e106bbb25d2ab2f1f611912d0f7b3b1`. +Historical wording; this is not a current model definition. + +```text +| agent | Actor or Artificial Agent | FOAF, ActivityPub, WebID | FOAF Agent includes humans; ActivityPub Service = Artificial Agent. | +``` + +### bot + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 31–31; SHA-256 `827962be82a98f1c17ffb62c4f4cd943a66a753d67e5cca0fc8ef77756e8ffad`. +Historical wording; this is not a current model definition. + +```text +| bot | Artificial Agent | ActivityPub Service, apps | Automated actor; may use Service Account. | +``` + +### organization + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 34–34; SHA-256 `b3deaa2097bfa8f94206f0d599bf434e202e1a3a72ff5ff0ac556ab9ad00efe3`. +Historical wording; this is not a current model definition. + +```text +| organization | Organization | Schema.org, Keycloak Orgs, ZITADEL, SCIM ext | Collective actor. SCIM `organization` attribute is not an Organization actor. | +``` + +### 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. | +``` + +### 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. | +``` + +### 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. | +``` + +### 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. | +``` + +### 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, …). | +``` + +### 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. | +``` + +### 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. | +``` + +### community + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 88–88; SHA-256 `0511a75af9b3a29cc2519527193f01cf70d04c0b0e04546127b14a7bd2ec5c8a`. +Historical wording; this is not a current model definition. + +```text +| community | Community | ActivityPub Group, proposal | Participation-oriented collective. ActivityPub Group may be Community or Group. | +``` + +### family + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 89–89; SHA-256 `b1494107b59c6ed89546a86eeb073414ee575a2376f3c695ecb23b5c2668e32d`. +Historical wording; this is not a current model definition. + +```text +| family | Family or Household | proposal, GDPR-sensitive | Guardian/dependent semantics; privacy-sensitive. | +``` + +### household + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 90–90; SHA-256 `0719bdf791feaaf5a70b1990b2ea38f730312c1addbbdd6562ddb0b7abbb75ed`. +Historical wording; this is not a current model definition. + +```text +| household | Family or Household | family accounts | Co-residence unit; may differ from legal family. | +``` + +### group + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 91–91; SHA-256 `46830fccca86caeda6623d000dc25708edfbc3fbce2be1d4746a7b4d3482dd43`. +Historical wording; this is not a current model definition. + +```text +| group | Group | LDAP, SCIM, FOAF, ActivityPub, Cedar | Named collection. LDAP/SCIM group ≠ social community without context. | +``` + +### team + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 92–92; SHA-256 `ad2667febbf25827e07ad34d4f413f4165078eda36f90fccd92361b88bc56737`. +Historical wording; this is not a current model definition. + +```text +| team | Group or Organization Unit | Schema.org, collaboration | Collaboration unit; may be org sub-unit. | +``` + +### role + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 93–93; SHA-256 `bf4b3c078725e3a9b4c661c358df673204d21865de9386223c00682de7a76d2a`. +Historical wording; this is not a current model definition. + +```text +| role | Role | Keycloak, ZITADEL, Cedar, Cerbos, Schema.org OrganizationRole | Capability bundle or relationship label. Cerbos derived role may hide Ownership. | +``` + +### grant + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 94–94; SHA-256 `ca2c9b2882bd176716d5f40b570f7d142e820881529353bdd9829ca2fff5acfd`. +Historical wording; this is not a current model definition. + +```text +| grant | Role assignment | ZITADEL | Project role assignment; map to Delegation-like relationship. | +``` + +### member + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 95–95; SHA-256 `a6600f7dd9604883a0c366467ad89a90ceee68aefbe6aca09067ada754baae23`. +Historical wording; this is not a current model definition. + +```text +| member | Membership Relationship | SCIM, LDAP, FOAF, Schema.org, Zanzibar | Relationship edge, not a noun for the participant. | +``` + +### affiliation + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 96–96; SHA-256 `06170379083ad57eb7ec1dee172d3f2e370140f32c1e8b3ccf5a700c3fffdb66`. +Historical wording; this is not a current model definition. + +```text +| affiliation | Affiliation Relationship | Schema.org, FOAF knows | Looser than membership. FOAF knows is weak social affiliation. | +``` + +### follower + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 97–97; SHA-256 `62256899610e66f10a97b6f7011d52ff02ce79f6d4060c0d403bc8a520f3e6ff`. +Historical wording; this is not a current model definition. + +```text +| follower | Following Relationship | ActivityPub | Directed social subscription; not membership or authz. | +``` + +### 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. | +``` + +### subscriber + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 119–119; SHA-256 `778a574609c40787ae9fec045e791faafd3d39b49fd187b3c10bc6dad0133e4c`. +Historical wording; this is not a current model definition. + +```text +| subscriber | Account / Identity Record | NIST | Enrolled party at CSP; not synonymous with Natural Person until IAL binding. | +``` + +### holder + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 128–128; SHA-256 `1e57bb144bb8a072a4180be14a8a91f8126c4f958397a8fd62e12c63db8806b6`. +Historical wording; this is not a current model definition. + +```text +| holder | Actor (custody role) | VC, OpenID4VC | Party possessing VC; may differ from subject. | +``` + +### verifier + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 129–129; SHA-256 `d37d10d4b1113114369aa128754a243e56f9ee71e5f95d5d9f966d75fe94088b`. +Historical wording; this is not a current model definition. + +```text +| verifier | Scope (evaluation role) | VC, OpenID4VC | Validates presentations. | +``` + +### webid + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 131–131; SHA-256 `e08c6ed7932919efd4c8f8ae55161be7a02e983d667cf3359fcff0affde44a1b`. +Historical wording; this is not a current model definition. + +```text +| webid | Identifier | WebID/Solid | HTTP URI identifying agent with dereferenceable profile. | +``` + +### data subject + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 132–132; SHA-256 `2aae43d6df259e4678d0a2d27fcf4efd546ecd99201d1a3e573cef845e78a822`. +Historical wording; this is not a current model definition. + +```text +| data subject | Natural Person | GDPR | Identifiable natural person for privacy regulation. | +``` + +### controller + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 134–134; SHA-256 `161324c016daae2806cd837b82beceffd4ea2b3ce981683b5ed39f58132b19e8`. +Historical wording; this is not a current model definition. + +```text +| controller | Organization (legal role) | GDPR | Downstream legal role; not canonical identity root. | +``` + +### derived role + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 137–137; SHA-256 `cbfaa9a627d2d32e194e4301e908fd193eb67c788ac3afad98079ce92e898fce`. +Historical wording; this is not a current model definition. + +```text +| derived role | Role (computed) | Cerbos | Role from attributes; should trace to Relationship when possible. | +``` + +### 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. | +``` + +### organizationrole + +Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 140–140; SHA-256 `ca2eda7a31f21b54ff220456146ef06584ab01844034832e519a9c9c0febf576`. +Historical wording; this is not a current model definition. + +```text +| organizationrole | Role + Membership | Schema.org | Temporal role with start/end dates. | +``` diff --git a/infospace/indexes/artifact-tree.yaml b/infospace/indexes/artifact-tree.yaml index cf0565c..5522b0b 100644 --- a/infospace/indexes/artifact-tree.yaml +++ b/infospace/indexes/artifact-tree.yaml @@ -1,5 +1,5 @@ root: infospace -file_count: 215 +file_count: 276 files: - path: README.md directory: . @@ -235,6 +235,189 @@ files: - path: assimilation/README.md directory: assimilation name: README.md +- path: assimilation/canon-federation/ASSIMILATION.md + directory: assimilation/canon-federation + name: ASSIMILATION.md +- path: assimilation/canon-federation/README.md + directory: assimilation/canon-federation + name: README.md +- path: assimilation/canon-federation/assimilation.yaml + directory: assimilation/canon-federation + name: assimilation.yaml +- path: assimilation/canon-federation/comparison-matrix.md + directory: assimilation/canon-federation + name: comparison-matrix.md +- path: assimilation/canon-federation/distribution.json + directory: assimilation/canon-federation + name: distribution.json +- path: assimilation/canon-federation/extracted-concepts.yaml + directory: assimilation/canon-federation + name: extracted-concepts.yaml +- path: assimilation/canon-federation/mappings.yaml + directory: assimilation/canon-federation + name: mappings.yaml +- path: assimilation/canon-federation/open-questions.md + directory: assimilation/canon-federation + name: open-questions.md +- path: assimilation/canon-federation/proposed-changes.md + directory: assimilation/canon-federation + name: proposed-changes.md +- path: assimilation/canon-federation/source/research/CorpusIndex.md + directory: assimilation/canon-federation/source/research + name: CorpusIndex.md +- path: assimilation/canon-federation/source/research/README.md + directory: assimilation/canon-federation/source/research + name: README.md +- path: assimilation/canon-federation/source/research/ResearchSeed.md + directory: assimilation/canon-federation/source/research + name: ResearchSeed.md +- path: assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md + directory: assimilation/canon-federation/source/research/authentication-federation + name: nist-800-63-4.md +- path: assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md + directory: assimilation/canon-federation/source/research/authentication-federation + name: oidc-core-subject-identifiers.md +- path: assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md + directory: assimilation/canon-federation/source/research/authentication-federation + name: saml-nameid-federation.md +- path: assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md + directory: assimilation/canon-federation/source/research/authentication-federation + name: shared-signals-caep-risc.md +- path: assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md + directory: assimilation/canon-federation/source/research/authorization-relationships + name: cedar-principal-action-resource-context.md +- path: assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md + directory: assimilation/canon-federation/source/research/authorization-relationships + name: cerbos-abac-derived-roles.md +- path: assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md + directory: assimilation/canon-federation/source/research/authorization-relationships + name: openfga-modeling.md +- path: assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md + directory: assimilation/canon-federation/source/research/authorization-relationships + name: zanzibar-rebac.md +- path: assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: beneficial-ownership-kyc-boi.md +- path: assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: commercial-identity-nuance-settlement.md +- path: assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: commercial-identity-synthesis.md +- path: assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: commercial-trust-binding-theory.md +- path: assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: crm-pipeline-commitment-threshold.md +- path: assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: duns-commercial-credit-identity.md +- path: assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: eidas-eudi-legal-person-wallet.md +- path: assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: kyc-aml-commercial-identity-binding.md +- path: assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: legal-person-agency-contract.md +- path: assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: lei-gleif-legal-entity-identifier.md +- path: assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: payment-credential-pci-boundary.md +- path: assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: registry-identifier-subtypes.md +- path: assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: reputation-assurance-gradient.md +- path: assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md + directory: assimilation/canon-federation/source/research/commercial-identity + name: salesforce-crm-commercial-record.md +- path: assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md + directory: assimilation/canon-federation/source/research/commercial-subscription + name: b2b-saas-subscriber-tenancy.md +- path: assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md + directory: assimilation/canon-federation/source/research/commercial-subscription + name: stripe-customer-billing.md +- path: assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md + directory: assimilation/canon-federation/source/research/entity-resolution-privacy + name: deterministic-vs-probabilistic-matching.md +- path: assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md + directory: assimilation/canon-federation/source/research/entity-resolution-privacy + name: gdpr-pseudonymization.md +- path: assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md + directory: assimilation/canon-federation/source/research/entity-resolution-privacy + name: synonymity-assertions.md +- path: assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md + directory: assimilation/canon-federation/source/research/identity-provisioning + name: keycloak-organizations.md +- path: assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md + directory: assimilation/canon-federation/source/research/identity-provisioning + name: ldap-rfc4519-inetorgperson-rfc2798.md +- path: assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md + directory: assimilation/canon-federation/source/research/identity-provisioning + name: ory-kratos-keto.md +- path: assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md + directory: assimilation/canon-federation/source/research/identity-provisioning + name: scim-rfc7643-rfc7644.md +- path: assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md + directory: assimilation/canon-federation/source/research/identity-provisioning + name: zitadel-organizations-projects.md +- path: assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md + directory: assimilation/canon-federation/source/research/social-community-graphs + name: activitypub-actors-followers.md +- path: assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md + directory: assimilation/canon-federation/source/research/social-community-graphs + name: foaf-agent-person-group-onlineaccount.md +- path: assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md + directory: assimilation/canon-federation/source/research/social-community-graphs + name: schema-org-person-organization-membership.md +- path: assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md + directory: assimilation/canon-federation/source/research/social-community-graphs + name: webid-solid-profile.md +- path: assimilation/canon-federation/source/research/verifiable-claims/did-core.md + directory: assimilation/canon-federation/source/research/verifiable-claims + name: did-core.md +- path: assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md + directory: assimilation/canon-federation/source/research/verifiable-claims + name: openid4vc.md +- path: assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md + directory: assimilation/canon-federation/source/research/verifiable-claims + name: vc-data-model-2.md +- path: assimilation/canon-federation/source/scenarios/ScenarioTests.md + directory: assimilation/canon-federation/source/scenarios + name: ScenarioTests.md +- path: assimilation/canon-federation/source/terminology/TerminologyConflictMap.md + directory: assimilation/canon-federation/source/terminology + name: TerminologyConflictMap.md +- path: assimilation/canon-federation/source/terminology/TerminologyInventory.md + directory: assimilation/canon-federation/source/terminology + name: TerminologyInventory.md +- path: assimilation/canon-federation/source-summary.md + directory: assimilation/canon-federation + name: source-summary.md +- path: assimilation/canon-federation/views/family-area.md + directory: assimilation/canon-federation/views + name: family-area.md +- path: assimilation/canon-federation/views/itc-access.md + directory: assimilation/canon-federation/views + name: itc-access.md +- path: assimilation/canon-federation/views/itc-evid.md + directory: assimilation/canon-federation/views + name: itc-evid.md +- path: assimilation/canon-federation/views/itc-gov.md + directory: assimilation/canon-federation/views + name: itc-gov.md +- path: assimilation/canon-federation/views/itc-ident.md + directory: assimilation/canon-federation/views + name: itc-ident.md +- path: assimilation/canon-federation/views/itc-org.md + directory: assimilation/canon-federation/views + name: itc-org.md - path: assimilation/emission-cadence/ASSIMILATION.md directory: assimilation/emission-cadence name: ASSIMILATION.md diff --git a/infospace/indexes/concept-ownership.yaml b/infospace/indexes/concept-ownership.yaml index 9259e83..dcf5a73 100644 --- a/infospace/indexes/concept-ownership.yaml +++ b/infospace/indexes/concept-ownership.yaml @@ -1,5 +1,9 @@ -concept_count: 162 +concept_count: 163 concepts: +- concept: Canon federation research provenance + owner: assimilation/canon-federation + path: assimilation/canon-federation/ASSIMILATION.md + source: artifact_title - concept: "Assimilation \u2014 EmissionCadenceDeclaration handover" owner: assimilation/emission-cadence path: assimilation/emission-cadence/ASSIMILATION.md diff --git a/infospace/indexes/import-matrix.yaml b/infospace/indexes/import-matrix.yaml index 3b08abe..16c4e89 100644 --- a/infospace/indexes/import-matrix.yaml +++ b/infospace/indexes/import-matrix.yaml @@ -1,4 +1,5 @@ artifacts: +- assimilation/canon-federation - assimilation/emission-cadence - assimilation/it-capability-canon - benchmark/caring/kubernetes-rbac @@ -79,6 +80,18 @@ artifacts: - standard/repository-layout - standard/tagging rows: +- artifact: assimilation/canon-federation + targets: + concept-area/family: + - uses + model/access-control: + - uses + model/evidence: + - uses + model/identity: + - uses + model/organization: + - uses - artifact: assimilation/emission-cadence targets: kernel/itc-core: diff --git a/infospace/views/by-concept.md b/infospace/views/by-concept.md index 412d63b..ce77adf 100644 --- a/infospace/views/by-concept.md +++ b/infospace/views/by-concept.md @@ -2,10 +2,11 @@ # By Concept -Concept count: **162** +Concept count: **163** | Concept | Owner | Source | | --- | --- | --- | +| Canon federation research provenance | `assimilation/canon-federation` | `artifact_title` | | Assimilation — EmissionCadenceDeclaration handover | `assimilation/emission-cadence` | `artifact_title` | | Assimilation — IT Capability Canon (ITCC) v0.1 | `assimilation/it-capability-canon` | `artifact_title` | | CARING Kubernetes RBAC Benchmark | `benchmark/caring/kubernetes-rbac` | `artifact_title` | diff --git a/infospace/views/by-mapping-target.md b/infospace/views/by-mapping-target.md index 01603e8..80c4543 100644 --- a/infospace/views/by-mapping-target.md +++ b/infospace/views/by-mapping-target.md @@ -41,6 +41,7 @@ ## `concept-area/family` +- `assimilation/canon-federation` via `uses` - `kernel/itc-kernel-map` via `maps` ## `concept-catalog/purpose-demand` @@ -106,6 +107,7 @@ ## `model/access-control` +- `assimilation/canon-federation` via `uses` - `benchmark/caring/kubernetes-rbac` via `stress_tests` - `benchmark/caring/kubernetes-rbac/access-descriptors` via `uses` - `benchmark/caring/kubernetes-rbac/caring-mapping` via `maps` @@ -156,6 +158,7 @@ ## `model/evidence` +- `assimilation/canon-federation` via `uses` - `kernel/itc-kernel-map` via `maps` - `model/access-control` via `uses` - `model/capability` via `uses` @@ -212,6 +215,7 @@ ## `model/identity` +- `assimilation/canon-federation` via `uses` - `kernel/itc-kernel-map` via `maps` - `model/access-control` via `uses` - `model/information-space` via `uses` @@ -270,6 +274,7 @@ ## `model/organization` +- `assimilation/canon-federation` via `uses` - `concept-area/family` via `uses` - `evaluation/user-engine` via `uses` - `evaluation/user-engine/questions` via `uses` diff --git a/infospace/views/import-matrix.md b/infospace/views/import-matrix.md index 1ae94b7..9f70404 100644 --- a/infospace/views/import-matrix.md +++ b/infospace/views/import-matrix.md @@ -2,84 +2,85 @@ # Import Matrix -| Artifact | `assimilation/emission-cadence` | `assimilation/it-capability-canon` | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `capability-catalog/itc-cap` | `catalog/attribute-value-types` | `catalog/evidence-basis` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-area/family` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `example/emission-cadence/qonto-assistant` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/capability-anchors` | `mapping/emission-cadence-handover` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/capability` | `model/data` | `model/devsecops` | `model/evidence` | `model/governance` | `model/identity` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `practice-pattern/agentic-drives-functional` | `practice-pattern/interface-deprecation-strangler` | `practice/intake-and-assimilation` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `scheme/practice-pattern` | `small-saas/capability-requirements/production` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/emission-cadence` | `standard/repository-layout` | `standard/tagging` | -| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| `assimilation/emission-cadence` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `assimilation/it-capability-canon` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `benchmark/caring/kubernetes-rbac` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `stress_tests` | | | `stress_tests` | | `stress_tests` | | | | `stress_tests` | `stress_tests` | | | `stress_tests` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `uses` | -| `benchmark/caring/kubernetes-rbac/access-descriptors` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | -| `benchmark/caring/kubernetes-rbac/caring-mapping` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | `maps` | | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | -| `benchmark/caring/kubernetes-rbac/findings` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | | | | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | -| `benchmark/caring/kubernetes-rbac/native-concepts` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | -| `capability-catalog/itc-cap` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `catalog/attribute-value-types` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `catalog/evidence-basis` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `comparison/repo-scoping/canon-benefit-analysis` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | `maps` | | | | | `maps` | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | -| `comparison/repo-scoping/consumer-workplan-brief` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `comparison/repo-scoping/extension-candidates` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | `proposes` | | | | | `proposes` | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `comparison/repo-scoping/frame` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `comparison/repo-scoping/report` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | `compares` | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `concept-area/family` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `concept-catalog/purpose-demand` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `conformance/railiance-fabric` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | -| `conformance/railiance-fabric/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `conformance/railiance-fabric/entity-edge-capture-criteria` | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `conformance/railiance-fabric/mapping-expectations` | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `maps` | `maps` | | `maps` | | | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `conformance/railiance-fabric/visualization-examples` | | | | | | | | | | | | | | | | | | `part_of` | | `illustrates` | `illustrates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `evaluation/user-engine` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | `uses` | | | | | | `uses` | `uses` | `uses` | `uses` | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | -| `evaluation/user-engine/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `evaluation/user-engine/interface-card-expectations` | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | -| `evaluation/user-engine/questions` | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | `uses` | | `uses` | | | `uses` | | | | | | `uses` | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `evaluation/user-engine/small-saas-alignment` | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | `uses` | | | | | `uses` | | | | | | `uses` | | | | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | | | | | -| `example/consumer-purpose-portfolio` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `illustrates` | | | `illustrates` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | -| `example/emission-cadence/qonto-assistant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | -| `kernel/itc-core` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `kernel/itc-kernel-map` | | | | | | | | | | | | | | | | `maps` | | | | | | | | | | | | | | `maps` | | | | | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | `maps` | -| `mapping/capability-anchors` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `mapping/emission-cadence-handover` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | -| `mapping/purpose-demand-governance-candidates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | | `maps` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/access-control` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | `uses` | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/capability` | | `derived_from` | | | | | | `introduces` | | `uses` | | | | | | | | | | | | | | | | | | | | `conforms_to` | | `introduces` | | | | | | | `uses` | `uses` | | | `uses` | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/data` | | | | | | | | | `introduces` | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/devsecops` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/evidence` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/governance` | | | | | | | | | | `introduces` | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/identity` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `uses` | | | | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/information-space` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/landscape` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/network` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/observability` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/organization` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/purpose-demand-extension` | | | | | | | | | | | | | | | | | `introduces` | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `extends` | | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/security` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `uses` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/task` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `pattern/intent-scope-purposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `implements` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `practice-pattern/agentic-drives-functional` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | | | | `uses` | | | | `uses` | | | `related_to` | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | -| `practice-pattern/interface-deprecation-strangler` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | -| `practice/intake-and-assimilation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `profile/small-saas` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `requires` | | `requires` | `requires` | | `requires` | | | `requires` | `requires` | `requires` | `requires` | | `requires` | `requires` | | | | | | | | | | | | | | | | | | | | | | | | | | | `requires` | | | `requires` | -| `review-kit/alignment` | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | -| `review-kit/alignment/model-selection-guide` | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | | | | | `uses` | `part_of` | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` | -| `review-kit/alignment/schema` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | -| `review-kit/alignment/scorecard` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | -| `review-kit/alignment/workflow` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | -| `review-kit/alignment/workplan-template` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | -| `scheme/practice-pattern` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `small-saas/capability-requirements/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | `applies_to` | | | | | | | | | | | -| `small-saas/control/namespace-per-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | | | `evidenced_by` | | | | | | | | | | `uses` | | | | -| `small-saas/dataset/subscription-ledger` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | `governed_by` | `owned_by` | | | | `partitioned_for` | `partitioned_for` | | | | | | -| `small-saas/deployment/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | | | | | | | | | `instantiates` | | | | | | | | | `implements` | | | | | | `deploys` | | | | `separates` | `separates` | | | | | | -| `small-saas/evidence/access-review-2026-05` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | | | | -| `small-saas/incident/cross-tenant-access-attempt` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | `constrained_by` | | | `evidenced_by` | | | | | | | | | | | | | | -| `small-saas/policy/tenant-isolation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | `instantiates` | | | | | | | | | `requires` | | | `evidenced_by` | | | | | | | | | | | | | | -| `small-saas/service/billing-portal` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | `part_of` | | `owned_by` | | | | | | | | -| `small-saas/system/billing-system` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | `serves` | `serves` | | | | | | -| `small-saas/task/onboard-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | `instantiates` | | | | | | | | | | | | | | `governed_by` | | | | `owned_by` | `changes` | | | | | | | -| `small-saas/team/platform` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | | | | -| `small-saas/tenant/acme` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | `isolated_by` | | | | | | | | | | | | `represented_by` | | | | | -| `small-saas/tenant/globex` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | `isolated_by` | | | | | | | | | | | | | | | | | -| `small-saas/user/ada-admin` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | `access_evidenced_by` | | `has_access_under` | | | | `member_of` | | | | | | | | -| `standard/caring` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `imports` | | `imports` | `imports` | `uses` | `imports` | | | | `imports` | `imports` | `imports` | | `imports` | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `imports` | -| `standard/emission-cadence` | `derived_from` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `imports` | | | | | `imports` | | | `related_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `standard/repository-layout` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `imports` | | `imports` | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `standard/tagging` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| Artifact | `assimilation/canon-federation` | `assimilation/emission-cadence` | `assimilation/it-capability-canon` | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `capability-catalog/itc-cap` | `catalog/attribute-value-types` | `catalog/evidence-basis` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-area/family` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `example/emission-cadence/qonto-assistant` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/capability-anchors` | `mapping/emission-cadence-handover` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/capability` | `model/data` | `model/devsecops` | `model/evidence` | `model/governance` | `model/identity` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `practice-pattern/agentic-drives-functional` | `practice-pattern/interface-deprecation-strangler` | `practice/intake-and-assimilation` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `scheme/practice-pattern` | `small-saas/capability-requirements/production` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/emission-cadence` | `standard/repository-layout` | `standard/tagging` | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | +| `assimilation/canon-federation` | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `assimilation/emission-cadence` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `assimilation/it-capability-canon` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `benchmark/caring/kubernetes-rbac` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `stress_tests` | | | `stress_tests` | | `stress_tests` | | | | `stress_tests` | `stress_tests` | | | `stress_tests` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `uses` | +| `benchmark/caring/kubernetes-rbac/access-descriptors` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | +| `benchmark/caring/kubernetes-rbac/caring-mapping` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | `maps` | | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | +| `benchmark/caring/kubernetes-rbac/findings` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | | | | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | +| `benchmark/caring/kubernetes-rbac/native-concepts` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | +| `capability-catalog/itc-cap` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `catalog/attribute-value-types` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `catalog/evidence-basis` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `comparison/repo-scoping/canon-benefit-analysis` | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | `maps` | | | | | `maps` | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | +| `comparison/repo-scoping/consumer-workplan-brief` | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `comparison/repo-scoping/extension-candidates` | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | `proposes` | | | | | `proposes` | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `comparison/repo-scoping/frame` | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `comparison/repo-scoping/report` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | `compares` | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `concept-area/family` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `concept-catalog/purpose-demand` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `conformance/railiance-fabric` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | +| `conformance/railiance-fabric/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `conformance/railiance-fabric/entity-edge-capture-criteria` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `conformance/railiance-fabric/mapping-expectations` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `maps` | `maps` | | `maps` | | | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `conformance/railiance-fabric/visualization-examples` | | | | | | | | | | | | | | | | | | | `part_of` | | `illustrates` | `illustrates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `evaluation/user-engine` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | `uses` | | | | | | `uses` | `uses` | `uses` | `uses` | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | +| `evaluation/user-engine/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `evaluation/user-engine/interface-card-expectations` | | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | +| `evaluation/user-engine/questions` | | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | `uses` | | `uses` | | | `uses` | | | | | | `uses` | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `evaluation/user-engine/small-saas-alignment` | | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | `uses` | | | | | `uses` | | | | | | `uses` | | | | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `example/consumer-purpose-portfolio` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `illustrates` | | | `illustrates` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `example/emission-cadence/qonto-assistant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | +| `kernel/itc-core` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `kernel/itc-kernel-map` | | | | | | | | | | | | | | | | | `maps` | | | | | | | | | | | | | | `maps` | | | | | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | `maps` | +| `mapping/capability-anchors` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `mapping/emission-cadence-handover` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | +| `mapping/purpose-demand-governance-candidates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | | `maps` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/access-control` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | `uses` | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/capability` | | | `derived_from` | | | | | | `introduces` | | `uses` | | | | | | | | | | | | | | | | | | | | `conforms_to` | | `introduces` | | | | | | | `uses` | `uses` | | | `uses` | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/data` | | | | | | | | | | `introduces` | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/devsecops` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/evidence` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/governance` | | | | | | | | | | | `introduces` | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/identity` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `uses` | | | | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/information-space` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/landscape` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/network` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/observability` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/organization` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/purpose-demand-extension` | | | | | | | | | | | | | | | | | | `introduces` | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `extends` | | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/security` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `uses` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/task` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `pattern/intent-scope-purposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `implements` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `practice-pattern/agentic-drives-functional` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | | | | `uses` | | | | `uses` | | | `related_to` | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | +| `practice-pattern/interface-deprecation-strangler` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | +| `practice/intake-and-assimilation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `profile/small-saas` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `requires` | | `requires` | `requires` | | `requires` | | | `requires` | `requires` | `requires` | `requires` | | `requires` | `requires` | | | | | | | | | | | | | | | | | | | | | | | | | | | `requires` | | | `requires` | +| `review-kit/alignment` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | +| `review-kit/alignment/model-selection-guide` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | | | | | `uses` | `part_of` | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` | +| `review-kit/alignment/schema` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | +| `review-kit/alignment/scorecard` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | +| `review-kit/alignment/workflow` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | +| `review-kit/alignment/workplan-template` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | +| `scheme/practice-pattern` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `small-saas/capability-requirements/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | `applies_to` | | | | | | | | | | | +| `small-saas/control/namespace-per-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | | | `evidenced_by` | | | | | | | | | | `uses` | | | | +| `small-saas/dataset/subscription-ledger` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | `governed_by` | `owned_by` | | | | `partitioned_for` | `partitioned_for` | | | | | | +| `small-saas/deployment/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | | | | | | | | | `instantiates` | | | | | | | | | `implements` | | | | | | `deploys` | | | | `separates` | `separates` | | | | | | +| `small-saas/evidence/access-review-2026-05` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `small-saas/incident/cross-tenant-access-attempt` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | `constrained_by` | | | `evidenced_by` | | | | | | | | | | | | | | +| `small-saas/policy/tenant-isolation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | `instantiates` | | | | | | | | | `requires` | | | `evidenced_by` | | | | | | | | | | | | | | +| `small-saas/service/billing-portal` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | `part_of` | | `owned_by` | | | | | | | | +| `small-saas/system/billing-system` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | `serves` | `serves` | | | | | | +| `small-saas/task/onboard-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | `instantiates` | | | | | | | | | | | | | | `governed_by` | | | | `owned_by` | `changes` | | | | | | | +| `small-saas/team/platform` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `small-saas/tenant/acme` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | `isolated_by` | | | | | | | | | | | | `represented_by` | | | | | +| `small-saas/tenant/globex` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | `isolated_by` | | | | | | | | | | | | | | | | | +| `small-saas/user/ada-admin` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | `access_evidenced_by` | | `has_access_under` | | | | `member_of` | | | | | | | | +| `standard/caring` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `imports` | | `imports` | `imports` | `uses` | `imports` | | | | `imports` | `imports` | `imports` | | `imports` | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `imports` | +| `standard/emission-cadence` | | `derived_from` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `imports` | | | | | `imports` | | | `related_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `standard/repository-layout` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `imports` | | `imports` | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `standard/tagging` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | diff --git a/infospace/views/kernel-overview.md b/infospace/views/kernel-overview.md index b48705d..e316e9b 100644 --- a/infospace/views/kernel-overview.md +++ b/infospace/views/kernel-overview.md @@ -3,7 +3,7 @@ # Kernel Overview - Infospace: `canon` -- Artifacts: 79 +- Artifacts: 80 ## Artifact Kinds @@ -12,7 +12,7 @@ - `alignment-review-schema`: 1 - `alignment-review-workflow`: 1 - `alignment-scorecard`: 1 -- `assimilation`: 2 +- `assimilation`: 3 - `benchmark-findings`: 1 - `benchmark-workspace`: 1 - `benefit-analysis`: 1 @@ -81,4 +81,4 @@ - `separates`: 2 - `serves`: 2 - `stress_tests`: 6 -- `uses`: 147 +- `uses`: 152 diff --git a/infospace/views/repository-tree.md b/infospace/views/repository-tree.md index b0cca34..33a4f0a 100644 --- a/infospace/views/repository-tree.md +++ b/infospace/views/repository-tree.md @@ -2,7 +2,7 @@ # Repository Tree -File count: **215** +File count: **276** - `README.md` - `agent/README.md` @@ -82,6 +82,67 @@ File count: **215** - `agent/templates/consumer-brief.template.md` - `artifacts/index.yaml` - `assimilation/README.md` +- `assimilation/canon-federation/ASSIMILATION.md` +- `assimilation/canon-federation/README.md` +- `assimilation/canon-federation/assimilation.yaml` +- `assimilation/canon-federation/comparison-matrix.md` +- `assimilation/canon-federation/distribution.json` +- `assimilation/canon-federation/extracted-concepts.yaml` +- `assimilation/canon-federation/mappings.yaml` +- `assimilation/canon-federation/open-questions.md` +- `assimilation/canon-federation/proposed-changes.md` +- `assimilation/canon-federation/source/research/CorpusIndex.md` +- `assimilation/canon-federation/source/research/README.md` +- `assimilation/canon-federation/source/research/ResearchSeed.md` +- `assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md` +- `assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md` +- `assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md` +- `assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md` +- `assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md` +- `assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md` +- `assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md` +- `assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md` +- `assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md` +- `assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md` +- `assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md` +- `assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md` +- `assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md` +- `assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md` +- `assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md` +- `assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md` +- `assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md` +- `assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md` +- `assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md` +- `assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md` +- `assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md` +- `assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md` +- `assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md` +- `assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md` +- `assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md` +- `assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md` +- `assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md` +- `assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md` +- `assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md` +- `assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md` +- `assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md` +- `assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md` +- `assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md` +- `assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md` +- `assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md` +- `assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md` +- `assimilation/canon-federation/source/research/verifiable-claims/did-core.md` +- `assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md` +- `assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md` +- `assimilation/canon-federation/source/scenarios/ScenarioTests.md` +- `assimilation/canon-federation/source/terminology/TerminologyConflictMap.md` +- `assimilation/canon-federation/source/terminology/TerminologyInventory.md` +- `assimilation/canon-federation/source-summary.md` +- `assimilation/canon-federation/views/family-area.md` +- `assimilation/canon-federation/views/itc-access.md` +- `assimilation/canon-federation/views/itc-evid.md` +- `assimilation/canon-federation/views/itc-gov.md` +- `assimilation/canon-federation/views/itc-ident.md` +- `assimilation/canon-federation/views/itc-org.md` - `assimilation/emission-cadence/ASSIMILATION.md` - `assimilation/emission-cadence/assimilation.yaml` - `assimilation/emission-cadence/comparison-matrix.md` diff --git a/tests/test_cli.py b/tests/test_cli.py index 2f1ea8a..d1bfa64 100644 --- a/tests/test_cli.py +++ b/tests/test_cli.py @@ -11,7 +11,7 @@ def test_cli_inspect_emits_json(capsys) -> None: assert exit_code == 0 payload = json.loads(capsys.readouterr().out) assert payload["ok"] is True - assert payload["infospace"]["artifact_count"] == 79 + assert payload["infospace"]["artifact_count"] == 80 def test_cli_missing_profile_uses_structured_error(capsys) -> None: diff --git a/tests/test_service.py b/tests/test_service.py index 821be2b..0ef7049 100644 --- a/tests/test_service.py +++ b/tests/test_service.py @@ -25,11 +25,11 @@ def test_inspect_canon_counts_artifact_kinds() -> None: assert payload["ok"] is True assert payload["infospace"]["slug"] == "canon" - assert payload["infospace"]["artifact_count"] == 79 + assert payload["infospace"]["artifact_count"] == 80 assert payload["infospace"]["kinds"] == { "access-descriptor-set": 1, "alignment-review-kit": 1, - "assimilation": 2, + "assimilation": 3, "alignment-review-schema": 1, "alignment-review-workflow": 1, "alignment-scorecard": 1, @@ -100,14 +100,14 @@ def test_validate_canon_passes_scaffold() -> None: assert payload["ok"] is True assert payload["errors"] == [] assert "warnings" in payload - assert payload["details"]["artifact_count"] == 79 + assert payload["details"]["artifact_count"] == 80 def test_graph_exports_relationship_summary() -> None: payload = artifact_graph() assert payload["ok"] is True - assert payload["graph"]["node_count"] == 79 + assert payload["graph"]["node_count"] == 80 assert payload["graph"]["edge_count"] > 15 diff --git a/workplans/INFO-WP-0024-corpus-provenance.md b/workplans/INFO-WP-0024-corpus-provenance.md new file mode 100644 index 0000000..6d87220 --- /dev/null +++ b/workplans/INFO-WP-0024-corpus-provenance.md @@ -0,0 +1,62 @@ +--- +id: INFO-WP-0024 +type: workplan +title: "Federation corpus provenance distribution" +domain: infotech +repo: info-tech-canon +status: finished +owner: codex +topic_slug: canon +created: "2026-09-06" +updated: "2026-09-06" +state_hub_workstream_id: "3bea30f6-8640-5c16-b782-8258babdba35" +--- + +# Federation corpus provenance distribution + +Implements CFED-WP-0001-T07; observe completed research without adopting new canon. + +## Freeze and route the source material + +```task +id: INFO-WP-0024-T01 +status: done +priority: medium +state_hub_task_id: "6b5f14d1-0513-5ca0-a173-1daa5624da14" +``` + +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: INFO-WP-0024-T02 +status: done +priority: medium +state_hub_task_id: "444d1943-60e4-5ef4-a0e5-d05e27cec81d" +``` + +Route exact terminology rows, conflict sections and scenarios by destination +interest. Mark historical conflicts and reuse accepted ownership mappings. + +## Verify and reconcile + +```task +id: INFO-WP-0024-T03 +status: done +priority: medium +state_hub_task_id: "bd04a7b9-2b02-5e05-9991-e561f7622ae9" +``` + +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). diff --git a/workplans/index.yaml b/workplans/index.yaml index 9c6bc52..25a78b9 100644 --- a/workplans/index.yaml +++ b/workplans/index.yaml @@ -16,6 +16,14 @@ implementation_decisions: consumer_workplans_live_in_consumer_repos: true workplans: + - id: INFO-WP-0024 + title: Federation corpus provenance distribution + status: finished + priority: medium + path: workplans/INFO-WP-0024-corpus-provenance.md + depends_on: [INFO-WP-0023] + produces: [frozen research snapshots, destination provenance indexes] + - id: INFO-WP-0023 title: Limited Family concept-area seed status: finished