Files

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

5.3 KiB

Raw Blame History

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

5.3 KiB Raw Blame History