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,129 @@
|
||||
# Nist 800 63 4
|
||||
# NIST SP 800-63-4
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Government guideline. NIST Special Publication 800-63-4, Digital Identity
|
||||
Guidelines (2025).
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Identity assurance, authentication assurance, federation assurance, and
|
||||
identity lifecycle.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
NIST Digital Identity Guidelines: identity proofing, authenticator assurance, federation assurance.
|
||||
NIST identity guidance separates identity proofing, authentication assurance,
|
||||
federation assurance, and lifecycle management.
|
||||
|
||||
NIST 800-63 provides the most explicit assurance-level vocabulary for
|
||||
separating how strongly an identity is bound to a person, how strongly
|
||||
authentication occurred, and how federation preserves or degrades assurance.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **IAL (Identity Assurance Level)**: confidence that a subscriber is who they
|
||||
claim to be (IAL1–IAL3).
|
||||
- **AAL (Authenticator Assurance Level)**: confidence in authentication
|
||||
mechanism strength (AAL1–AAL3).
|
||||
- **FAL (Federation Assurance Level)**: confidence in federation protocol and
|
||||
assertion protection (FAL1–FAL3).
|
||||
- **Subscriber**: party enrolled with a CSP (credential service provider).
|
||||
- **Credential Service Provider (CSP)**: issues credentials and performs
|
||||
identity proofing.
|
||||
- **Relying Party (RP)**: depends on CSP assertions.
|
||||
- **Identity Provider (IdP) / Asserting Party (AP)**: federates authentication
|
||||
to RPs.
|
||||
- **Verifier**: entity confirming claimant possession of authenticator.
|
||||
- **Binding**: association between subscriber, identity, and authenticator.
|
||||
- **Identity proofing**: collection and validation of evidence about a person.
|
||||
- **Authenticator**: something the subscriber possesses/controls for auth.
|
||||
- **Federation assertion**: signed statement from IdP to RP about
|
||||
authentication and attributes.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Subscriber | Enrolled party at CSP; not necessarily named "user." |
|
||||
| CSP | Provider performing proofing and credential issuance. |
|
||||
| RP | Consumer of identity/authentication assertions. |
|
||||
| IAL | Identity proofing strength level. |
|
||||
| AAL | Authentication event strength level. |
|
||||
| FAL | Federation protocol/assertion protection level. |
|
||||
| Claimant | Party attempting authentication. |
|
||||
| Verifier | Confirms authenticator use. |
|
||||
| Binding | Link between subscriber identity and authenticator. |
|
||||
| Supervised remote proofing | IAL2+ proofing with human or tech supervision. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **Identity assurance, authentication, and federation are separable**
|
||||
dimensions with independent levels.
|
||||
- **Subscriber is the enrolled entity**, not the legal person directly; binding
|
||||
connects them.
|
||||
- **Proofing evidence matters** and should be retained per policy.
|
||||
- **Federation may preserve or reduce assurance** depending on FAL and
|
||||
assertion contents.
|
||||
- **Lifecycle includes enrollment, binding, maintenance, and termination.**
|
||||
- **Pseudonymous enrollment is allowed** at IAL1 without real-name binding.
|
||||
- **Agency/customer relationship** is outside the technical model but affects
|
||||
policy.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- NIST **Subscriber** maps to **Account** or enrolled **Identity Record**
|
||||
bound to **Natural Person** at higher IAL.
|
||||
- **IAL** maps to **Assurance Level** on Identity Record / Person binding.
|
||||
- **AAL** maps to **Assurance Level** on authentication event / Credential use.
|
||||
- **FAL** maps to **Assurance Level** on **Trust Relationship** or federation
|
||||
assertion.
|
||||
- **Binding** maps to **Synonymity Assertion** or **Identifier Binding**
|
||||
between subscriber, person, and authenticator.
|
||||
- **Identity proofing evidence** maps to **Evidence Source**.
|
||||
- Reinforces **P7** (synonymity as assertion) and **P8** (preserve evidence).
|
||||
- Supports S12 (weak match insufficient for IAL2+), S13 (strong link with
|
||||
verification), S06 (family/guardian proofing).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **Subscriber vs. User**: NIST subscriber is enrolled party; apps say user.
|
||||
- **Identity vs. Subscriber**: NIST separates identity proofing from
|
||||
subscriber record.
|
||||
- **Credential vs. Authenticator**: NIST distinguishes credential (issued)
|
||||
from authenticator (possessed); products conflate.
|
||||
- **IAL vs. Account trust**: assurance on person binding ≠ account permissions.
|
||||
- **Federation vs. Synonymity**: federation assertion ≠ same-person claim
|
||||
across systems.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| NIST concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Subscriber | Account / enrolled Identity Record |
|
||||
| CSP / IdP | Issuer Scope + Trust Relationship |
|
||||
| RP | Relying party Scope |
|
||||
| IAL | Assurance Level (identity proofing) |
|
||||
| AAL | Assurance Level (authentication) |
|
||||
| FAL | Assurance Level (federation) |
|
||||
| Authenticator | Credential |
|
||||
| Binding | Identifier Binding / Synonymity Assertion |
|
||||
| Proofing evidence | Evidence Source |
|
||||
| Federation assertion | Claim + Credential (signed) |
|
||||
| Claimant | Actor attempting authentication (projection) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- Should IAL/AAL/FAL be a unified Assurance Level vocabulary or three
|
||||
orthogonal dimensions in canon?
|
||||
- How should pseudonymous IAL1 subscribers map when no Natural Person binding
|
||||
exists?
|
||||
- Does guardian-assisted proofing for minors warrant a distinct Relationship
|
||||
type with assurance caps?
|
||||
- Should CSP subscriber ID be a Scoped Identifier under CSP Scope?
|
||||
|
||||
## References
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- NIST SP 800-63-4 — https://pages.nist.gov/800-63-4/
|
||||
- NIST SP 800-63A (Enrollment and Identity Proofing) — https://pages.nist.gov/800-63-4/sp800-63A.html
|
||||
- NIST SP 800-63B (Authentication and Lifecycle) — https://pages.nist.gov/800-63-4/sp800-63B.html
|
||||
- NIST SP 800-63C (Federation and Assertions) — https://pages.nist.gov/800-63-4/sp800-63C.html
|
||||
@@ -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
|
||||
@@ -1,50 +1,128 @@
|
||||
# Saml Nameid Federation
|
||||
# SAML NameID Federation
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Standard. OASIS SAML 2.0 Core and Profiles for Web Browser SSO; NameID formats
|
||||
and federation metadata conventions.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Enterprise federation, single sign-on, assertion semantics, and cross-domain
|
||||
identity correlation.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
SAML assertions, NameID formats, identity provider/service provider federation terminology.
|
||||
SAML 2.0 remains central to enterprise federation. NameID formats, assertion
|
||||
subject statements, attribute statements, and IdP/SP metadata define how
|
||||
enterprise identities cross organizational boundaries.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **Identity Provider (IdP)**: asserts authentication and attributes about a
|
||||
subject to service providers.
|
||||
- **Service Provider (SP)**: consumes assertions and establishes local session.
|
||||
- **Assertion**: XML security token containing subject, conditions, authn
|
||||
statements, and attribute statements.
|
||||
- **Subject / NameID**: identifier for the principal at the IdP; carries
|
||||
Format attribute defining syntax and semantics.
|
||||
- **NameID formats**: transient, persistent, emailAddress, X509SubjectName,
|
||||
kerberos, entity, unspecified, and others.
|
||||
- **Persistent NameID**: stable, opaque identifier for a principal at an IdP.
|
||||
- **Transient NameID**: one-time identifier for a single federation session.
|
||||
- **AttributeStatement**: SAML attributes (mail, eduPersonPrincipalName, group
|
||||
memberships) about the subject.
|
||||
- **AuthnStatement**: authentication instant, session index, and context class.
|
||||
- **AudienceRestriction**: scopes assertion to intended SP entity IDs.
|
||||
- **Metadata**: XML describing IdP/SP endpoints, certificates, NameID formats,
|
||||
and supported attributes.
|
||||
- **Affiliation / discovery**: federations aggregate metadata for trust circles.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Principal | Authenticated entity; identified by NameID in assertion. |
|
||||
| NameID | Subject identifier chosen by IdP; format determines semantics. |
|
||||
| Persistent NameID | Long-lived opaque ID stable for principal at IdP. |
|
||||
| Transient NameID | Ephemeral ID for one session; privacy-preserving. |
|
||||
| Subject | SAML assertion subject element holding NameID. |
|
||||
| Attribute | Named property asserted about subject. |
|
||||
| EntityID | Unique identifier for IdP or SP in metadata. |
|
||||
| Assertion | Signed statement about authentication and attributes. |
|
||||
| SessionIndex | Handle for single logout correlation. |
|
||||
| Audience | Intended SP for assertion consumption. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **NameID is the primary correlation key** between IdP and SP for account
|
||||
linking.
|
||||
- **Format determines persistence and privacy**; persistent enables cross-
|
||||
session linking, transient prevents it.
|
||||
- **Principal means authenticated subject**, not a pre-provisioned local user.
|
||||
- **Attributes are asserted**, not authoritative directory records in the SP.
|
||||
- **Trust is pairwise** between IdP and SP via metadata exchange.
|
||||
- **Groups may appear as attributes**, not as first-class relationship tuples.
|
||||
- **Federation operates across organizational boundaries**; each side
|
||||
maintains its own namespace.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- SAML **NameID** maps to **Identifier** or **Scoped Identifier** depending
|
||||
on format (persistent vs. transient).
|
||||
- **Persistent NameID** supports **Synonymity Assertion** linking SP local
|
||||
Account to IdP identifier.
|
||||
- **Transient NameID** maps to session-scoped **Scoped Identifier** with no
|
||||
cross-session synonymity.
|
||||
- **Principal** in assertion maps to **Authenticated Subject** projection.
|
||||
- **AttributeStatement** attributes map to **Claim** objects.
|
||||
- **EntityID** maps to **Scope** identifier for IdP/SP.
|
||||
- **AudienceRestriction** maps to Scope boundary for assertion validity.
|
||||
- **Attribute-based group membership** maps to **Claim** (group attribute) or
|
||||
Membership hint, not canonical Group unless provisioned.
|
||||
- Supports S02 (multi-scope accounts), S13 (strong link via persistent NameID).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **Principal vs. Subject**: SAML uses both; principal is authenticated entity,
|
||||
subject is XML element.
|
||||
- **Principal vs. Authorization Principal**: SAML principal is auth subject,
|
||||
not Cedar principal.
|
||||
- **Persistent vs. Pairwise**: SAML persistent NameID is IdP-wide stable;
|
||||
OIDC pairwise is RP-specific.
|
||||
- **NameID vs. emailAddress format**: email as identifier conflates Identifier
|
||||
with contact attribute.
|
||||
- **Attribute vs. Claim**: SAML attribute is XML element; canon Claim is
|
||||
issuer statement — compatible but different syntax.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| SAML concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| NameID (persistent) | Identifier |
|
||||
| NameID (transient) | Scoped Identifier (session-bound) |
|
||||
| NameID (emailAddress) | Identifier (with attribute conflation risk) |
|
||||
| Principal | Authenticated Subject |
|
||||
| Subject element | Protocol binding for Authenticated Subject |
|
||||
| AttributeStatement attribute | Claim |
|
||||
| EntityID (IdP/SP) | Scope identifier |
|
||||
| Assertion | Credential / signed assertion |
|
||||
| Audience | Scope boundary |
|
||||
| SessionIndex | Session correlation reference (projection) |
|
||||
| SP local account mapping | Synonymity Assertion |
|
||||
|
||||
## Open Questions
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- Should persistent NameID map to strong Synonymity by default, or only after
|
||||
SP verification (S13)?
|
||||
- How should eduPerson / SCHAC attribute vocabularies map to Profile vs. Claim?
|
||||
- Does transient NameID session scope warrant a distinct Lifecycle State on the
|
||||
Scoped Identifier?
|
||||
- Should federation metadata trust map to **Trust Relationship** with
|
||||
certificate Evidence Source?
|
||||
|
||||
## References
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- SAML 2.0 Core — http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
|
||||
- SAML 2.0 Profiles — http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
|
||||
- SAML NameID Format URIs — http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf (§8.3)
|
||||
- REFEDS entity categories — https://refeds.org/category
|
||||
@@ -1,50 +1,125 @@
|
||||
# Shared Signals Caep Risc
|
||||
# Shared Signals, CAEP, and RISC
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Standard and profile. OpenID Shared Signals Framework 1.0, CAEP (Continuous
|
||||
Access Evaluation Profile), and RISC (Risk Incident Sharing and Coordination).
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Security event sharing, session lifecycle, account state propagation, and
|
||||
continuous access evaluation across federated systems.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
OpenID Shared Signals, CAEP, and RISC for security event exchange and lifecycle/risk signaling.
|
||||
OpenID Shared Signals, CAEP, and RISC suggest that canonical identity models
|
||||
should anticipate dynamic security and lifecycle events.
|
||||
|
||||
Federation is not static. Shared Signals define how issuers push account
|
||||
compromise, credential change, session revocation, and user profile update
|
||||
events to relying parties — requiring lifecycle-aware identity modeling.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **Shared Signals Framework (SSF)**: transport and envelope for delivering
|
||||
security events between transmitter and receiver.
|
||||
- **Transmitter**: entity (typically IdP) sending events about subjects.
|
||||
- **Receiver**: entity (typically RP) consuming events and updating local state.
|
||||
- **Subject in event**: identifies the affected party, often by `sub` and `iss`
|
||||
or equivalent.
|
||||
- **CAEP events**: session-revoked, token-claims-change, credential-change,
|
||||
assurance-level-change, and related continuous evaluation signals.
|
||||
- **RISC events**: account-credential-compromise, account-disabled,
|
||||
account-enabled, identifier-changed, and recovery-related events.
|
||||
- **SET (Security Event Token)**: JWT-format event payload.
|
||||
- **Stream configuration**: receiver registers endpoint; transmitter manages
|
||||
delivery and retry.
|
||||
- **Verification**: receivers validate SET signatures from transmitter.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Transmitter | Event source (usually OP/IdP). |
|
||||
| Receiver | Event consumer (usually RP). |
|
||||
| SET | Security Event Token (JWT). |
|
||||
| Subject (event) | Identifies affected user at transmitter. |
|
||||
| Session revoked | Active sessions should be terminated at receiver. |
|
||||
| Credential change | Password/key rotation; may require re-auth. |
|
||||
| Account disabled | Subject account suspended at transmitter. |
|
||||
| Identifier changed | Subject ID or attribute materially changed. |
|
||||
| Assurance level change | IAL/AAL/FAL or equivalent changed. |
|
||||
| Stream | Configured event delivery channel. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **Identity state changes over time** and RPs must react without polling.
|
||||
- **Subject in events maps to prior federation binding** (`iss`+`sub` or
|
||||
equivalent).
|
||||
- **Lifecycle events are issuer-authoritative** for issuer-managed accounts.
|
||||
- **Receivers maintain local session/account state** that must reconcile with
|
||||
events.
|
||||
- **Not all state changes imply synonymity changes**; identifier-changed may
|
||||
require rebinding.
|
||||
- **Events are evidence** for downstream state transitions.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- SSF events map to **Evidence Source** events triggering **Lifecycle State**
|
||||
transitions on Account, Session projection, or Synonymity Assertion.
|
||||
- **Account disabled/enabled** maps to Lifecycle State change on Account or
|
||||
Identity Record.
|
||||
- **Credential change** maps to Credential lifecycle event; may invalidate
|
||||
sessions.
|
||||
- **Session revoked** affects session projection, not canonical Account.
|
||||
- **Identifier changed** may require superseding **Identifier Binding** or
|
||||
Synonymity Assertion with new target.
|
||||
- **Assurance level change** maps to updated **Assurance Level** metadata.
|
||||
- Reinforces **P8** (preserve source/evidence) and invariant that lifecycle
|
||||
applies to relationships and assertions, not only accounts.
|
||||
- Supports S02 (multi-account lifecycle), S13 (link revocation), federation
|
||||
scenarios requiring continuous evaluation.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **Subject**: event subject is issuer identifier; not authorization subject.
|
||||
- **Account**: event "account disabled" means issuer-side record; RP may have
|
||||
separate local account.
|
||||
- **Session vs. Account**: session revocation ≠ account deletion.
|
||||
- **Identifier changed vs. Synonymity**: identifier migration is not automatic
|
||||
same-as merge.
|
||||
- **Continuous access vs. Authorization**: CAEP informs access evaluation but
|
||||
is not a policy engine.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| SSF/CAEP/RISC concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| SET event | Evidence Source (event) |
|
||||
| Transmitter | Issuer Scope |
|
||||
| Receiver | Relying party Scope |
|
||||
| Event subject | Identifier reference |
|
||||
| Account disabled/enabled | Lifecycle State transition |
|
||||
| Credential change | Credential Lifecycle State |
|
||||
| Session revoked | Session projection lifecycle |
|
||||
| Identifier changed | Identifier Binding supersession |
|
||||
| Assurance level change | Assurance Level update |
|
||||
| Token claims change | Claim set modification event |
|
||||
|
||||
## Open Questions
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- Should SET event types be enumerated in canon as standard Evidence Source
|
||||
categories?
|
||||
- How should identifier-changed events interact with existing Synonymity
|
||||
Assertions (supersede vs. revoke vs. chain)?
|
||||
- Should receivers model event processing state as Relationship between
|
||||
Receiver Scope and Transmitter Scope?
|
||||
- Are session projections worth a minimal canonical mention given SSF
|
||||
prevalence?
|
||||
|
||||
## References
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- OpenID Shared Signals Framework 1.0 — https://openid.net/specs/openid-sharedsignals-framework-1_0.html
|
||||
- OpenID CAEP 1.0 — https://openid.net/specs/openid-caep-1_0.html
|
||||
- OpenID RISC 1.0 — https://openid.net/specs/openid-risc-1_0.html
|
||||
- RFC 8417: Security Event Token (SET) — https://datatracker.ietf.org/doc/html/rfc8417
|
||||
Reference in New Issue
Block a user