Files
identity-canon/research/authentication-federation/oidc-core-subject-identifiers.md
tegwick 1c1b5c9bc6 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.
2026-06-21 20:22:20 +02:00

125 lines
5.3 KiB
Markdown

# 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