generated from coulomb/repo-seed
Complete IDENTITY-WP-0003 corpus backfill and model refinement
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
This commit is contained in:
@@ -2,49 +2,105 @@
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Concept synthesis from identity-canon ResearchSeed, entity resolution practice,
|
||||
federation account linking, and semantic web `sameAs` patterns.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Identity linking, scoped equivalence, account linking, and non-destructive record
|
||||
association.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Weak, strong, scoped, operational, legal, and privacy-preserving synonymity assertions.
|
||||
Synonymity assertions are the identity-canon-native model for linking records
|
||||
without merge — synthesizing federation binding, entity resolution, and
|
||||
semantic equivalence patterns.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **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
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| 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
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **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
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- 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
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **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
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| 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
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- 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
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- 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/
|
||||
Reference in New Issue
Block a user