generated from coulomb/repo-seed
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.
This commit is contained in:
@@ -1,50 +1,125 @@
|
||||
# Oidc Core Subject Identifiers
|
||||
# OIDC Core Subject Identifiers
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Standard. OpenID Connect Core 1.0 incorporating errata; subject identifier
|
||||
types defined in Core and the Subject Identifier Types specification.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source 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.
|
||||
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
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **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
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| 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
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **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
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- 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
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **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
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| 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
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- 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
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- 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
|
||||
Reference in New Issue
Block a user