Distribute frozen federation corpus by concept destination

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b

infospace/assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md

@@ -0,0 +1,129 @@
+# NIST SP 800-63-4
+
+## Source Type
+
+Government guideline. NIST Special Publication 800-63-4, Digital Identity
+Guidelines (2025).
+
+## Domain
+
+Identity assurance, authentication assurance, federation assurance, and
+identity lifecycle.
+
+## Why This Source Matters
+
+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
+
+- **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
+
+| 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
+
+- **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
+
+- 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
+
+- **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
+
+| 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
+
+- 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
+
+- 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

infospace/assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md

@@ -0,0 +1,125 @@
+# 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

infospace/assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md

@@ -0,0 +1,128 @@
+# SAML NameID Federation
+
+## Source Type
+
+Standard. OASIS SAML 2.0 Core and Profiles for Web Browser SSO; NameID formats
+and federation metadata conventions.
+
+## Domain
+
+Enterprise federation, single sign-on, assertion semantics, and cross-domain
+identity correlation.
+
+## Why This Source Matters
+
+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
+
+- **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
+
+| 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
+
+- **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
+
+- 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
+
+- **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
+
+| 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
+
+- 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
+
+- 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

infospace/assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md

@@ -0,0 +1,125 @@
+# Shared Signals, CAEP, and RISC
+
+## Source Type
+
+Standard and profile. OpenID Shared Signals Framework 1.0, CAEP (Continuous
+Access Evaluation Profile), and RISC (Risk Incident Sharing and Coordination).
+
+## 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 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
+
+- **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
+
+| 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
+
+- **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
+
+- 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
+
+- **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
+
+| 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
+
+- 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
+
+- 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