coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md
tegwick 372f671eef
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Distribute frozen federation corpus by concept destination 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
2026-09-06 00:44:37 +02:00

4.8 KiB
Raw Blame History

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