# 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