# 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/