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.

research/authentication-federation/nist-800-63-4.md

@@ -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

research/authentication-federation/oidc-core-subject-identifiers.md

@@ -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

research/authentication-federation/saml-nameid-federation.md

@@ -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

research/authentication-federation/shared-signals-caep-risc.md

@@ -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

research/authorization-relationships/cedar-principal-action-resource-context.md

@@ -2,49 +2,113 @@
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard and product reference. Cedar policy language (AWS Verified Permissions)
+with principal-action-resource-context evaluation model.
 
 ## Domain
 
-TODO: Classify the source domain.
+Fine-grained authorization, policy-based access control, and ABAC/RBAC
+hybrid evaluation.
 
 ## Why This Source Matters
 
-Cedar principal-action-resource-context model and policy terminology.
+Cedar's principal-action-resource-context distinction preserves orthogonality
+between identity, action, resource, and request context.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Principal**: entity requesting access; typed entity reference (`User::"alice"`,
+  `Role::"admin"`).
+- **Action**: operation being attempted (`Action::"view"`, `Action::"delete"`).
+- **Resource**: entity being accessed (`Document::"report"`).
+- **Context**: request-time record with additional attributes (IP, time,
+  delegated-by).
+- **Policy**: Cedar statement allowing or forbidding `(principal, action, resource)`
+  under conditions.
+- **Entity**: typed object in entity store with attributes and parents.
+- **Schema**: defines entity types, actions, and attribute shapes.
+- **Group / Role entity**: principal may be member of groups; roles as entities.
+- **Authorization request**: tuple of principal, action, resource, context
+  evaluated against policies.
+- **Conditional policies**: when-clauses over context and entity attributes.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Principal | Entity requesting access in authorization decision. |
+| Action | Verb/operation being authorized. |
+| Resource | Target entity of the action. |
+| Context | Ephemeral request attributes. |
+| Entity | Typed node in entity store with UID and attributes. |
+| Policy | Rule governing allow/deny. |
+| Schema | Type system for entities and actions. |
+| Role | Entity type principals can assume or belong to. |
+| Group | Entity type with membership edges. |
+| UID | Unique entity identifier string (`Type::"id"`). |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Authorization is a decision over four orthogonal dimensions** (PARTICIPANT,
+  ACTION, TARGET, CONTEXT).
+- **Principals are entity references**, not full identity records.
+- **Entity store is separate** from identity directory; may sync from IAM.
+- **Roles and groups are entities**, not free-floating strings.
+- **Context carries delegation and environmental facts** at decision time.
+- **Policies are declarative** and evaluated without imperative code.
+- **No social or legal relationship model** beyond entity parent/group links.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- Cedar **Principal** maps to **Authorization Principal** projection.
+- **Resource** maps to **Authorization Resource** projection.
+- **Action** maps to **Authorization Action** projection.
+- **Context** maps to request **Context** projection (may carry Delegation
+  evidence).
+- **Entity** in store may represent Account, Group, Role, or Organization
+  projection — not canonical Actor directly.
+- Parent/group entity links parallel **Membership** in authz layer.
+- Context `delegatedBy` or custom attributes support S11 (AI agent delegation).
+- Strong evidence for **P6** and **P2** (principal ≠ actor ≠ account).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Principal vs. Actor**: Cedar principal is decision participant; actor is
+  conceptual entity.
+- **Principal vs. Subject**: OIDC subject is identifier; Cedar principal is
+  typed entity UID.
+- **Role**: Cedar Role entity vs. IAM role vs. social role.
+- **Group**: Cedar group entity vs. LDAP group vs. community.
+- **Entity**: Cedar entity vs. canon Entity family (actor layer).
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| Cedar concept | Candidate canonical concept |
+| --- | --- |
+| Principal | Authorization Principal |
+| Resource | Authorization Resource |
+| Action | Authorization Action |
+| Context | Request context projection |
+| Entity (User) | Authorization Principal (Account projection) |
+| Entity (Group) | Group (authz projection) |
+| Entity (Role) | Role (authorization projection) |
+| Policy | Authorization Policy (downstream artifact) |
+| Schema | Authorization schema (downstream) |
+| parent relation | Membership/inheritance (authz projection) |
+| Context.delegatedBy | Delegation Relationship (context reference) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should canon define a minimal Context projection schema for delegation and
+  assurance attributes?
+- How should Cedar User entities map to Account vs. Service Account vs.
+  Artificial Agent?
+- Are Cedar Role entities always authorization projections, or can they mirror
+  canonical Role relationships?
+- Should entity UID format be standardized in downstream recommendations?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- Cedar policy language — https://www.cedarpolicy.com/
+- Cedar schema format — https://www.cedarpolicy.com/policies/syntax-schema.html
+- AWS Verified Permissions — https://docs.aws.amazon.com/verifiedpermissions/

research/authorization-relationships/cerbos-abac-derived-roles.md

@@ -1,50 +1,114 @@
-# Cerbos Abac Derived Roles
+# Cerbos ABAC Derived Roles
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Product documentation and open-source implementation reference for Cerbos
+policy decision point with derived roles and attribute-based conditions.
 
 ## Domain
 
-TODO: Classify the source domain.
+Policy-based authorization, attribute-driven role derivation, and resource-centric
+access control.
 
 ## Why This Source Matters
 
-Cerbos ABAC/RBAC policy concepts, derived roles, resources, principals, and conditions.
+Cerbos combines resource policies, principal attributes, and derived roles —
+a pattern common in SaaS where permissions depend on both identity attributes
+and resource ownership context.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Principal**: subject of authorization request with `id` and `roles` plus
+  optional attributes.
+- **Resource**: target with `kind`, `id`, and attributes (owner, department,
+  classification).
+- **Action**: operation requested on resource.
+- **Policy**: YAML/JSON rules binding roles and conditions to allow/deny/effect.
+- **Derived roles**: dynamically computed roles from principal + resource
+  attributes (e.g., `owner` when `principal.id == resource.attr.owner`).
+- **Static roles**: assigned roles on principal at request time.
+- **Condition**: CEL expression over principal, resource, and request metadata.
+- **Scope**: policy namespace for multi-tenant isolation (`scope` field).
+- **AuxData**: JWT claims or external data enriching principal at check time.
+- **Effect**: ALLOW, DENY, or conditional variants with rule ordering.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Principal | Requesting party with id, roles, attributes. |
+| Resource | Entity with kind, id, and attributes. |
+| Derived role | Role computed from attribute matching rules. |
+| Static role | Pre-assigned role on principal. |
+| Policy | Declarative allow/deny rules. |
+| Scope | Tenant or environment partition for policies. |
+| Condition | Boolean expression over request context. |
+| AuxData | Supplemental principal data (e.g., JWT). |
+| kind | Resource type discriminator. |
+| attr | Attribute bag on principal or resource. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Authorization is resource-centric** with policies attached to resource kinds.
+- **Roles can be derived at evaluation time** from attribute equality or
+  relationships encoded in attributes.
+- **Principal attributes may come from JWT** or external identity system.
+- **Ownership is often modeled as resource attribute**, not explicit relationship.
+- **Scope provides tenant isolation** for policy sets.
+- **No graph traversal** for permissions; derivation is attribute-based.
+- **Identity system supplies principal id and roles**; Cerbos does not store
+  identity records.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- Cerbos **Principal** maps to **Authorization Principal** projection.
+- **Resource** maps to **Authorization Resource** projection.
+- **Derived role** (e.g., owner) should trace to canonical **Ownership
+  Relationship** or **Membership** when possible, not only attribute equality.
+- Encoding `resource.attr.owner = principal.id` collapses relationship into
+  attribute — canon should prefer explicit Relationship with authz projection.
+- **Scope** maps to **Scope** / **Tenant** for policy partition.
+- **AuxData JWT claims** map to **Claim** inputs to authorization projection.
+- Supports S05 (admin roles), S10 (service principal attributes), but risks
+  hiding relationships in attributes (tension with **P5**).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Principal vs. User**: Cerbos principal id often equals user id from app DB.
+- **Owner**: derived role "owner" vs. Ownership Relationship vs. resource
+  attribute.
+- **Role**: derived role vs. static IAM role vs. canonical Role relationship.
+- **Scope vs. Tenant**: Cerbos scope is policy namespace; may not equal tenant.
+- **Attributes vs. Profile**: principal attributes overlap with profile fields.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| Cerbos concept | Candidate canonical concept |
+| --- | --- |
+| Principal | Authorization Principal |
+| Resource | Authorization Resource |
+| Action | Authorization Action |
+| Static role | Role (authorization projection) |
+| Derived role | Role derived from Relationship (preferred) or attribute rule |
+| Policy | Authorization Policy (downstream) |
+| Scope | Scope / Tenant (policy partition) |
+| Principal attributes | Profile/Claim inputs to projection |
+| Resource attributes | Resource metadata + Ownership hints |
+| AuxData (JWT) | Claim + Authenticated Subject context |
+| Condition | Request context projection |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should canon explicitly discourage encoding Ownership as resource attribute
+  without a backing Relationship?
+- How should derived roles from group membership sync with canonical Membership
+  edges?
+- Does Cerbos scope map 1:1 to Tenant, or also to Application Scope?
+- Should JWT AuxData be documented as standard Authenticated Subject →
+  Principal projection path?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- Cerbos documentation — https://docs.cerbos.dev/
+- Cerbos derived roles — https://docs.cerbos.dev/cerbos/latest/policies/derived_roles
+- Cerbos scopes — https://docs.cerbos.dev/cerbos/latest/policies/scope_policy

research/authorization-relationships/openfga-modeling.md

@@ -1,50 +1,111 @@
-# Openfga Modeling
+# OpenFGA Modeling
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Product documentation and open-source implementation reference for OpenFGA
+authorization modeling (Zanzibar-inspired).
 
 ## Domain
 
-TODO: Classify the source domain.
+Relationship-based access control modeling, authorization schema design, and
+multi-tenant permission systems.
 
 ## Why This Source Matters
 
-OpenFGA authorization models, relationship tuples, users, objects, and relations.
+OpenFGA provides a concrete, documented modeling language for Zanzibar-style
+relationship tuples with authorization models, stores, and checks.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Authorization model**: declarative schema of types, relations, and
+  permission definitions.
+- **Type definition**: object type with relations and optional `define` rules.
+- **Relation**: named edge on a type; may allow direct assignment or computed
+  rules.
+- **Define / rewrite rules**: union (`+`), intersection, exclusion, and
+  inheritance (`from relation`).
+- **Tuple**: `user:type#relation@object:type` stored fact.
+- **Userset**: indirect reference such as `user:anne#member@group:engineering`.
+- **Store**: isolated tuple set with its own model.
+- **Check / ListObjects / ListUsers**: query APIs.
+- **Contextual tuples**: ephemeral tuples supplied at check time.
+- **Conditions**: CEL-based contextual rules on relations (newer versions).
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| User (in tuple) | Subject identifier in `user:` namespace. |
+| Object | Entity in `object:` namespace with type. |
+| Relation | Named permission edge on a type. |
+| Type | Schema class for objects (document, folder, organization). |
+| Model | Collection of type definitions. |
+| Store | Isolated authorization dataset. |
+| define | Computed relation rule. |
+| from | Inheritance from related object's relation. |
+| contextual tuple | Runtime-only tuple for conditional checks. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Model-first design**: relations are declared in schema before tuples are written.
+- **User and object IDs are opaque strings**; no embedded identity semantics.
+- **Organization/tenant patterns** are modeled as types (e.g., `organization`,
+  `tenant`) with `member`, `admin` relations.
+- **Inheritance chains** (folder contains document) are common modeling pattern.
+- **Store isolation** provides multi-tenant authorization separation.
+- **Identity management is external**; OpenFGA consumes identifiers.
+- **Permissions are computed**, not stored as standalone grants.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- OpenFGA aligns with Zanzibar mappings; adds explicit **authorization model**
+  as schema artifact (downstream, not canonical).
+- Type definitions like `organization#member` parallel **Organization** +
+  **Membership Relationship** but in authz projection.
+- **Store** maps to **Authorization Domain** Scope or tenant-scoped authz partition.
+- `user:` prefix in tuples maps to **Authorization Principal** identifier.
+- Contextual tuples support request-time **Delegation** context without
+  persisting relationship.
+- Model examples for parent-child org hierarchies support S03, S04, S05.
+- Reinforces **P6**: tuples are projections from actors/relationships.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **User**: OpenFGA `user:` is tuple subject prefix, not human or account.
+- **Organization type**: authz type ≠ Organization collective actor unless
+  explicitly linked.
+- **Member relation**: authz member ≠ community member without model alignment.
+- **Store vs. Tenant**: store is authz isolation; tenant is broader scope.
+- **Permission vs. Relation**: permissions are computed from relations; products
+  often say "permission" for relation name.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| OpenFGA concept | Candidate canonical concept |
+| --- | --- |
+| Tuple | Relationship Tuple (authorization projection) |
+| user: (subject) | Authorization Principal |
+| object: (entity) | Authorization Resource |
+| Relation | Relationship type (authz-implied) |
+| Type definition | Authorization schema (downstream) |
+| Store | Authorization Domain Scope |
+| define/from rules | Authorization derivation (non-canonical) |
+| organization#member | Membership Relationship (projection) |
+| organization#admin | Administration Relationship (projection) |
+| contextual tuple | Delegation context (ephemeral) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should canon document standard OpenFGA type patterns (org/team/resource) as
+  downstream recommendations only?
+- How should principal identifiers be aligned with Account IDs vs. Authenticated
+  Subject `sub` values?
+- Do conditional (CEL) relations require canonical Context as a first-class
+  projection?
+- Should one Store always map 1:1 to a Tenant Scope?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- OpenFGA documentation — https://openfga.dev/docs
+- OpenFGA modeling guide — https://openfga.dev/docs/modeling
+- OpenFGA configuration language — https://openfga.dev/docs/configuration-language

research/authorization-relationships/zanzibar-rebac.md

@@ -1,50 +1,111 @@
-# Zanzibar Rebac
+# Google Zanzibar ReBAC
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Architecture pattern and research paper. Google Zanzibar (2019) defines
+relationship-based access control at global scale.
 
 ## Domain
 
-TODO: Classify the source domain.
+Relationship-based authorization, permission inheritance, and large-scale
+access control graphs.
 
 ## Why This Source Matters
 
-Google Zanzibar-style relationship-based authorization concepts.
+Zanzibar/OpenFGA-style relationship tuples are especially close to what
+identity-canon needs for memberships, ownership, representation, delegation,
+and tenant administration.
+
+Zanzibar is the reference architecture for storing authorization facts as
+subject-relation-object tuples with computed permission expansion.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Relation tuple**: `object#relation@subject` or `object#relation@subject#subject_relation`.
+- **Object**: typed entity with namespace and ID (e.g., `document:readme`).
+- **Subject**: user, group, or object acting through a relation.
+- **Relation**: named edge type on an object type (owner, editor, viewer, member).
+- **Userset rewrite**: computed relations via union, intersection, exclusion,
+  and arrow operators (e.g., parent->owner).
+- **Namespace configuration**: schema defining object types, relations, and
+  rewrite rules.
+- **Check API**: evaluate whether subject has relation to object.
+- **Expand API**: enumerate subjects with relation to object.
+- **zookie**: consistency token for read-after-write semantics.
+- **Group as subject**: usersets allow group-like indirection in tuples.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Tuple | Stored authorization fact. |
+| Object | Resource or entity being authorized. |
+| Subject | Actor or userset granted a relation. |
+| Relation | Named permission edge on object type. |
+| Userset | Indirect subject reference via relation chain. |
+| Namespace | Schema for object types and relations. |
+| Check | Boolean permission query. |
+| Expand | Enumerate authorized subjects. |
+| owner / editor / viewer | Common relation names (deployment-specific). |
+| parent relation | Hierarchical inheritance via rewrite rules. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Authorization facts are relationships**, not role assignments on users alone.
+- **Subjects and objects are typed strings**, not rich identity records.
+- **Inheritance is computed** from tuple graph via rewrite rules.
+- **Identity provisioning is external**; Zanzibar stores authorization state only.
+- **Groups are modeled as objects** with member relations, not as separate IAM groups.
+- **Consistency matters** for distributed reads (zookie tokens).
+- **No canonical person model**; subject IDs are opaque.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- Zanzibar **tuple** maps to **Relationship Tuple** (authorization projection).
+- **Object** maps to **Authorization Resource** projection.
+- **Subject** maps to **Authorization Principal** projection.
+- **Relation** maps to typed **Relationship** with authorization implication.
+- **Namespace** maps to **Authorization Domain** Scope.
+- **Userset rewrite** is authorization engine logic, not canonical identity.
+- Membership tuples (`group:eng#member@user:alice`) parallel **Membership
+  Relationship** but live in authz layer.
+- Supports S05 (admin delegation), S08 (moderator relations), S10 (service
+  account acting for org via tuple).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Subject**: Zanzibar subject is authz participant; OIDC subject is identifier.
+- **Object**: Zanzibar object is authz resource; grammar object ≠ domain object.
+- **Relation vs. Relationship**: Zanzibar relation is permission edge; canon
+  Relationship is broader (social, legal, operational).
+- **Member**: Zanzibar member relation on group object ≠ social membership.
+- **User**: Zanzibar user ID is opaque; no person/account distinction.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| Zanzibar concept | Candidate canonical concept |
+| --- | --- |
+| Relation tuple | Relationship Tuple (authorization projection) |
+| Object | Authorization Resource |
+| Subject | Authorization Principal |
+| Relation name | Relationship type (authz-implied) |
+| Namespace config | Authorization Domain Scope |
+| Group object + member | Group + Membership (authz projection) |
+| Userset rewrite | Authorization engine derivation (non-canonical) |
+| zookie | Consistency metadata (operational) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should canonical Membership Relationship be shared between identity and
+  authz layers, or always projected into tuples?
+- How should representation/delegation map to Zanzibar relations vs. identity-layer
+  Representation Relationship?
+- Should object namespace prefixes map to Scope identifiers?
+- When does a social Following relationship warrant an authz tuple vs. remain
+  identity-only?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- Google Zanzibar paper — https://research.google/pubs/pub48190/
+- Zanzibar ACL language (related) — referenced in paper §2
+- OpenFGA (Zanzibar-inspired OSS) — https://openfga.dev/docs

research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md

@@ -1,50 +1,109 @@
-# Deterministic Vs Probabilistic Matching
+# Deterministic vs Probabilistic Matching
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Academic and industry practice. Entity resolution, record linkage, and
+duplicate detection literature plus operational MDM patterns.
 
 ## Domain
 
-TODO: Classify the source domain.
+Entity resolution, record linkage, duplicate detection, and account matching
+confidence.
 
 ## Why This Source Matters
 
-Deterministic and probabilistic matching patterns for entity resolution and identity linking.
+Entity resolution literature distinguishes deterministic keys from probabilistic
+matching — the foundation for weak vs. strong synonymity modeling.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Deterministic matching**: records match when agreed key fields are equal
+  (exact email, government ID, OIDC `iss`+`sub`).
+- **Probabilistic matching**: match score from weighted field similarity
+  (Fellegi-Sunter, Jaro-Winkler, ML classifiers).
+- **Record linkage**: identifying records across datasets referring to same
+  entity.
+- **Blocking**: reduce comparison space by bucketing on partial keys.
+- **Match threshold**: score above which records are linked or flagged.
+- **False positive / false negative tradeoff**: precision vs. recall in linking.
+- **Golden record / survivor**: MDM pattern selecting canonical merged record.
+- **Non-destructive link**: associate records without merge (preferred in modern MDM).
+- **Human review queue**: ambiguous matches escalated for operator decision.
+- **Master data management (MDM)**: operational discipline around entity resolution.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Deterministic match | Equality on predefined key fields. |
+| Probabilistic match | Scored similarity above threshold. |
+| Record linkage | Cross-dataset entity correspondence. |
+| Blocking key | Partial key for candidate pair generation. |
+| Match score | Confidence metric for probable same entity. |
+| Duplicate | Records hypothesized to refer to same entity. |
+| Merge | Combine records into one (destructive). |
+| Link | Associate records preserving sources (non-destructive). |
+| Survivor record | Chosen primary after merge. |
+| Quarantine | Hold ambiguous matches for review. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Same entity is hypothesis until verified** in probabilistic approaches.
+- **Deterministic rules are domain-specific** (no universal golden key).
+- **Merge destroys provenance** unless carefully audited — increasingly avoided.
+- **Confidence is continuous or banded** (weak/medium/strong).
+- **Source system identity must be preserved** for compliance and undo.
+- **Human review is part of high-assurance linking.**
+- **Privacy regulations constrain** which fields can be matched.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- Deterministic match maps to **strong Synonymity Assertion** when keys are
+  authoritative (S13).
+- Probabilistic match maps to **weak Synonymity Assertion** with confidence
+  score and method (S12).
+- **Link without merge** is the canonical preferred pattern (**P7**).
+- **Match score** maps to confidence/strength on Synonymity Assertion.
+- **Blocking/method** maps to Evidence Source metadata.
+- **Quarantine** maps to Lifecycle State `proposed` on assertion.
+- **Golden record** is downstream MDM pattern; canon should not require merge.
+- **Human review** maps to Evidence Source (operator decision).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Duplicate vs. Synonymity**: duplicates imply merge; synonymity allows coexistence.
+- **Match vs. Link**: industry uses interchangeably; canon distinguishes strength.
+- **Entity vs. Actor**: resolution literature says entity; canon prefers Actor target.
+- **Identity vs. Record**: matching is between records, not persons directly.
+- **Deterministic vs. Strong**: deterministic can still be wrong if key is shared
+  (shared email).
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| Entity resolution concept | Candidate canonical concept |
+| --- | --- |
+| Deterministic match | Strong Synonymity Assertion |
+| Probabilistic match | Weak Synonymity Assertion |
+| Match score | Confidence / strength metadata |
+| Link (non-destructive) | Synonymity Assertion |
+| Merge | Downstream anti-pattern (avoid) |
+| Blocking key | Evidence Source method |
+| Review queue | Lifecycle State `proposed` |
+| Source record ID | Identifier |
+| Golden record | Downstream projection only |
+| False positive handling | Revocation / supersession of assertion |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- What confidence bands (weak/medium/strong) should canon standardize?
+- Which deterministic keys are authoritative per source family (OIDC iss+sub,
+  persistent SAML NameID, verified email)?
+- Should probabilistic matchers be required to store feature-level Evidence Source?
+- How should shared-attribute false positives (family email) be classified?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- Fellegi-Sunter model (1969) — foundational probabilistic record linkage
+- Christen, "Data Matching" (2012) — entity resolution textbook
+- NIST SP 800-63A evidence requirements — https://pages.nist.gov/800-63-4/sp800-63A.html
+- MDM Institute duplicate management practices — industry reference

research/entity-resolution-privacy/gdpr-pseudonymization.md

@@ -1,50 +1,114 @@
-# Gdpr Pseudonymization
+# GDPR Pseudonymization and Privacy
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Regulatory guidance. EU GDPR (Regulation 2016/679) Article 4(5) and Recital 26;
+EDPB guidance on identifiability, anonymization, and data subject rights.
 
 ## Domain
 
-TODO: Classify the source domain.
+Privacy regulation, pseudonymization, identifiability, data minimization, and
+lawful basis for identity processing.
 
 ## Why This Source Matters
 
-GDPR-relevant pseudonymization, anonymization, data minimization, and identity linkage considerations.
+GDPR pseudonymization and identifiability concepts affect how canonical models
+should represent privacy-limited links, scoped identifiers, and correlation risk.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Personal data**: information relating to identified or identifiable natural
+  person.
+- **Identifiable person**: can be identified directly or indirectly by reasonable
+  means.
+- **Pseudonymization (Art. 4(5))**: processing personal data so it cannot be
+  attributed to a subject without additional information kept separately.
+- **Anonymization**: irreversible de-identification; data no longer personal.
+- **Data subject**: identified or identifiable natural person.
+- **Controller / Processor**: roles responsible for processing personal data.
+- **Purpose limitation**: data used for specified, explicit, legitimate purposes.
+- **Data minimization**: adequate, relevant, limited to necessary.
+- **Right of access / erasure**: data subject rights affecting linked records.
+- **Additional information**: key held separately to re-identify pseudonymous data.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Personal data | Data about identifiable natural person. |
+| Pseudonymization | Reversible de-identification with separate key. |
+| Anonymization | Irreversible; no longer personal data (if effective). |
+| Data subject | Natural person the data relates to. |
+| Identifiable | Reasonably linkable to person. |
+| Additional information | Re-identification key stored separately. |
+| Controller | Determines purposes and means of processing. |
+| Processing | Any operation on personal data. |
+| Erasure | Delete personal data (right to be forgotten). |
+| Profiling | Automated evaluation of personal aspects. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Pseudonymization is not anonymization**; data may remain personal.
+- **Separate storage of additional information** is required for pseudonymization.
+- **Scope and access control on keys** determine correlation risk.
+- **Linking pseudonymous records across purposes** may increase identifiability.
+- **Legal basis and purpose** govern whether linking is permissible.
+- **Erasure requests** may require breaking links or deleting assertions.
+- **Regulatory role (controller)** is organizational, not purely technical.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- **Pseudonymous Identifier** and **Scoped Identifier** map to pseudonymization
+  techniques (pairwise sub, hashed email, internal IDs).
+- **Privacy-limited Synonymity Assertion** must record privacy classification
+  and scope (S14).
+- **Additional information** (re-identification key) maps to separately secured
+  **Evidence Source** or **Credential** with strict Scope access.
+- **Data subject** maps to **Natural Person** with privacy rights overlay
+  (downstream policy, not canon legal advice).
+- **Erasure** maps to Lifecycle State transitions: revoke assertions, sever
+  bindings, archive with legal exceptions noted downstream.
+- Pairwise OIDC, tenant-local subjects, and restricted persona links are
+  technical pseudonymization patterns aligned with GDPR concepts.
+- Reinforces visibility of privacy constraints on relationships (**P8**, S14 checks).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Pseudonym vs. Pseudonymization**: pseudonym is identifier; pseudonymization
+  is processing technique.
+- **Anonymous vs. Pseudonymous**: often conflated in product marketing.
+- **Identity vs. Personal data**: not all identifiers are personal data in all
+  contexts.
+- **Deletion vs. Revocation**: erasure may require more than assertion revocation.
+- **Subject**: GDPR data subject vs. OIDC/SAML subject.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| GDPR concept | Candidate canonical concept |
+| --- | --- |
+| Data subject | Natural Person (privacy overlay) |
+| Pseudonymization | Processing pattern on Identifier / Profile |
+| Pseudonymous identifier | Scoped Identifier / Pseudonymous Identifier |
+| Additional information | Separately secured Evidence Source / key |
+| Purpose limitation | Scope + policy metadata on processing |
+| Cross-system link | Synonymity Assertion (privacy classification required) |
+| Erasure request | Lifecycle State + assertion revocation |
+| Identifiability risk | Privacy classification on links |
+| Controller | Organization actor (downstream legal role) |
+| Anonymized dataset | Out of scope for personal identity linking |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should canon include a standard `privacy_classification` enum for assertions?
+- How should erasure of one account affect Synonymity Assertions touching other
+  accounts (S02)?
+- Does pseudonymization key storage warrant a canonical secured Scope type?
+- Should identifiability review be documented as operator workflow in downstream
+  recommendations only?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- GDPR Article 4(5) pseudonymization — https://gdpr-info.eu/art-4-gdpr/
+- GDPR Recital 26 on identifiability — https://gdpr-info.eu/recitals-novo/26/
+- EDPB Guidelines on identifiability (various) — https://edpb.europa.eu/
+- ISO/IEC 20889 privacy enhancing data de-identification terminology

research/entity-resolution-privacy/synonymity-assertions.md

@@ -2,49 +2,105 @@
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Concept synthesis from identity-canon ResearchSeed, entity resolution practice,
+federation account linking, and semantic web `sameAs` patterns.
 
 ## Domain
 
-TODO: Classify the source domain.
+Identity linking, scoped equivalence, account linking, and non-destructive record
+association.
 
 ## Why This Source Matters
 
-Weak, strong, scoped, operational, legal, and privacy-preserving synonymity assertions.
+Synonymity assertions are the identity-canon-native model for linking records
+without merge — synthesizing federation binding, entity resolution, and
+semantic equivalence patterns.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Synonymity assertion**: scoped, evidenced claim that two or more identifiers,
+  records, or actors refer to the same target for a stated purpose.
+- **Relation type**: `same_as`, `probably_same_as`, `linked_to`, `represents`,
+  `controls`, `acts_for` (from ResearchSeed).
+- **Strength**: weak, medium, strong, authoritative bands.
+- **Scope**: namespace, tenant, relying party, or purpose boundary limiting
+  assertion validity.
+- **Evidence**: verification event, issuer signature, operator review, import
+  job output.
+- **Source system**: system that created or maintains the assertion.
+- **Lifecycle**: proposed, active, revoked, expired, superseded.
+- **Privacy classification**: controls visibility and correlation risk.
+- **Non-merge invariant**: linked records retain independent identity and provenance.
+- **Supersession chain**: new assertion replaces old when identifiers change.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Synonymity | Sameness or equivalence under conditions. |
+| Assertion | Explicit modeled statement, not implicit merge. |
+| same_as | High-confidence equivalence. |
+| probably_same_as | Probabilistic equivalence. |
+| linked_to | Operational convenience link. |
+| represents | One record represents another (controller, profile). |
+| Scope | Boundary limiting assertion meaning. |
+| Strength | Confidence band. |
+| Revocation | Assertion no longer valid. |
+| Supersession | New assertion replaces prior. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Equivalence is contextual**, not universal.
+- **Multiple assertions can coexist** for different scopes and purposes.
+- **Conflicting assertions possible**; require review workflow.
+- **Downstream systems consume assertions** according to their assurance needs.
+- **Privacy-limited assertions** must not leak across scopes (S14).
+- **Federation bindings are synonymity assertions** (`iss`+`sub` → local account).
+- **sameAs on web is weak by default** unless corroborated.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- Synonymity Assertion is a **first-class Relationship** class in canon.
+- Recommended fields align with ResearchSeed and ConceptualModel invariants.
+- OIDC RP binding, SAML persistent NameID mapping, SCIM `externalId`
+  correlation, and entity-resolution matches all project into Synonymity
+  Assertions with appropriate strength.
+- Supports all linking scenarios: S12 (weak), S13 (strong), S14 (privacy-limited).
+- **P7** is the governing principle; merge is downstream exception only.
+- Revocation from RISC/SSF events should update assertion Lifecycle State.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Link vs. Merge**: products say "linked accounts" after merge.
+- **sameAs vs. same_as**: semantic web informal vs. canon typed relation.
+- **Account linking vs. Identity linking**: may target accounts or identifiers.
+- **Alias vs. Synonymity**: alias is presentation; synonymity is assertion.
+- **Duplicate resolution vs. Synonymity**: MDM duplicate implies survivor selection.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| Practice / source pattern | Candidate canonical concept |
+| --- | --- |
+| OIDC iss+sub → local user | Strong Synonymity Assertion (scoped) |
+| SAML persistent NameID map | Strong Synonymity Assertion |
+| Probabilistic duplicate score | Weak Synonymity Assertion (`probably_same_as`) |
+| Operator-verified link | Strong Synonymity Assertion (authoritative) |
+| Pairwise sub RP binding | Privacy-limited Synonymity Assertion |
+| SCIM externalId correlation | Identifier Binding / medium Synonymity |
+| schema.org sameAs | Weak Synonymity Assertion (caution) |
+| DID equivalentId | Method-dependent Synonymity |
+| VC subject DID binding | Strong Synonymity Assertion with cryptographic evidence |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should `linked_to` remain distinct from `same_as` for operational vs. semantic links?
+- What minimum field set is mandatory for all Synonymity Assertions (see OpenQuestions)?
+- How should conflicting assertions be represented (priority, review state)?
+- Should privacy classification be enum or policy reference?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- identity-canon ResearchSeed.md — synonymity assertion fields
+- identity-canon ConceptualModel.md — identity linking model
+- OIDC account linking practice — https://openid.net/specs/openid-connect-core-1_0.html
+- W3C VC subject identification — https://www.w3.org/TR/vc-data-model-2.0/

research/identity-provisioning/keycloak-organizations.md

@@ -2,49 +2,137 @@
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Product documentation and implementation reference for Keycloak 26+ organization
+features and core realm/user/group/role model.
 
 ## Domain
 
-TODO: Classify the source domain.
+Multi-tenant IAM, B2B/B2B2C organization management, and OIDC/SAML federation.
 
 ## Why This Source Matters
 
-Keycloak organizations, realms, groups, roles, clients, and B2B/B2B2C organization management terminology.
+Keycloak organizations, realms, groups, roles, clients, and B2B/B2B2C
+organization management terminology.
+
+Keycloak is a widely deployed open-source IAM product. Its newer Organizations
+feature adds first-class B2B org semantics on top of the classic realm model,
+making it a live vocabulary source for tenant/org/customer overlap.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Realm**: top-level administrative and security namespace; owns users,
+  clients, identity providers, roles, groups, and authentication flows.
+- **User**: realm-local account with credentials, attributes, group/role
+  mappings, and federation links.
+- **Organization** (26+): B2B entity with members, domains, identity providers,
+  and invited users; supports multi-org membership per user.
+- **Organization member**: user linked to an organization with membership
+  metadata (roles within the org context).
+- **Group**: realm-level hierarchical collection for user grouping and role
+  mapping.
+- **Role**: realm role or client role; assigned directly, via group, or via
+  composite roles.
+- **Client**: OIDC/SAML application registered in a realm; may represent a
+  tenant application or service.
+- **Identity Provider (IdP)**: federated authentication source brokering
+  external identities into realm users.
+- **User federation**: LDAP/AD/Kerberos bridge supplying or syncing users.
+- **Attribute**: key-value metadata on users, clients, or organizations.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Realm | Hard identity/admin boundary; separate user namespace per realm. |
+| User | Realm-local login account with credentials and profile attributes. |
+| Organization | B2B org actor within a realm; has domains, members, and IdP config. |
+| Member | User belonging to an organization. |
+| Group | Realm hierarchy node; users inherit roles through group membership. |
+| Role | Named permission bundle at realm or client scope. |
+| Client | Application or service consuming tokens from the realm. |
+| Identity Provider | External auth source; may assert identities into realm users. |
+| Domain (org) | Email domain associated with an organization for discovery/broker routing. |
+| Federated identity | Link between realm user and external IdP identity. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Realm is the primary isolation boundary** for users, credentials, and
+  admin policy.
+- **User means account** in product vocabulary; one realm user per login
+  identity within that realm.
+- **Organization is a B2B overlay** within a realm, not a replacement for
+  realm or tenant infrastructure boundaries.
+- **Groups carry authorization semantics** through role mapping, not just
+  social grouping.
+- **Roles are permission bundles**, assignable directly or transitively via
+  groups and composites.
+- **Federation links** connect external IdP identities to local users via
+  brokered login.
+- **Multi-org membership** is supported: one user can belong to multiple
+  organizations in the same realm.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- Keycloak **Realm** maps to **Realm** (Scope specialization) with hard
+  namespace boundaries.
+- Keycloak **User** maps to **Account** in a realm Scope; not **Natural
+  Person**.
+- Keycloak **Organization** maps to **Organization** collective actor with
+  **Membership Relationship** to member Accounts.
+- **Group** maps to **Group** with Membership edges; role inheritance is
+  authorization projection.
+- **Role** maps to **Role** (authorization projection), not membership.
+- **Client** maps to application **Scope** or registered resource in
+  authorization domain.
+- **Federated identity** link maps to **Synonymity Assertion** or
+  **Identifier Binding** between external IdP identifier and local Account.
+- **Domain** on organization is an **Identifier** used for discovery routing.
+- Supports scenarios S03 (enterprise orgs), S04 (vendor/customer B2B), S05
+  (delegated admins via roles/groups).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Realm vs. Tenant**: Keycloak realm is both issuer namespace and admin
+  partition; products often call this "tenant."
+- **User vs. Member**: org member is still a realm User; membership is a
+  relationship overlay.
+- **Organization vs. Group**: both exist; org has B2B semantics (domains, IdP),
+  group is generic hierarchy.
+- **Role vs. Membership**: group membership implies role inheritance;
+  conflates relationship types.
+- **Client vs. Tenant**: clients are applications, not customer isolation
+  boundaries.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| Keycloak concept | Candidate canonical concept |
+| --- | --- |
+| Realm | Realm (Scope) |
+| User | Account |
+| Organization | Organization |
+| Organization membership | Membership Relationship |
+| Group | Group |
+| Group membership | Membership Relationship |
+| Role (realm/client) | Role (authorization projection) |
+| Client | Application Scope / registered client |
+| Identity Provider | Trust Relationship + external issuer Scope |
+| Federated identity link | Synonymity Assertion / Identifier Binding |
+| User attribute | Profile attribute or Claim |
+| Organization domain | Identifier (email domain) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should Keycloak Realm remain a **Realm** specialization or absorb **Tenant**
+  semantics when used as SaaS isolation?
+- How should multi-org user membership be modeled when the same Account holds
+  Membership edges to multiple Organizations?
+- Does Keycloak Organization domain verification warrant a **Claim** or
+  **Evidence Source** in canon?
+- Should composite roles be modeled as Role aggregation or as derived
+  authorization projection only?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- Keycloak Organizations documentation — https://www.keycloak.org/docs/latest/server_admin/#_organizations
+- Keycloak Server Administration Guide — https://www.keycloak.org/docs/latest/server_admin/
+- Keycloak Realm concepts — https://www.keycloak.org/docs/latest/server_admin/#_create-realm

research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md

@@ -1,50 +1,130 @@
-# Ldap Rfc4519 Inetorgperson Rfc2798
+# LDAP RFC 4519 and inetOrgPerson RFC 2798
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard. RFC 4519 defines LDAP attribute types and object classes; RFC 2798
+defines the `inetOrgPerson` auxiliary object class for Internet person entries.
 
 ## Domain
 
-TODO: Classify the source domain.
+Directory services, enterprise identity records, and hierarchical naming.
 
 ## Why This Source Matters
 
-LDAP directory schema, RFC 4519 attribute/object class vocabulary, and inetOrgPerson RFC 2798.
+LDAP directory schema, RFC 4519 attribute/object class vocabulary, and
+inetOrgPerson RFC 2798.
+
+LDAP remains the structural backbone of many enterprise directories. Its
+distinguished names, organizational units, and groupOfNames semantics
+precede and often underpin SCIM and IAM product models.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Directory Information Tree (DIT)**: hierarchical namespace of entries
+  identified by Distinguished Names (DNs).
+- **Entry**: a collection of attribute type/value pairs with one structural
+  object class and optional auxiliary object classes.
+- **Distinguished Name (DN)**: unique identifier within a directory; composed
+  of Relative Distinguished Names (RDNs) such as `cn`, `ou`, `dc`.
+- **inetOrgPerson**: auxiliary object class for person entries with `cn`,
+  `sn`, `mail`, `uid`, `employeeNumber`, and related attributes.
+- **organizationalUnit (ou)**: container for organizational structure.
+- **groupOfNames / groupOfUniqueNames**: group entries with `member` or
+  `uniqueMember` attributes referencing member DNs.
+- **posixAccount / posixGroup**: UNIX-oriented account and group semantics
+  with `uid`, `gid`, `homeDirectory`, and `memberUid`.
+- **Attribute syntax and matching rules**: typed attributes (DirectoryString,
+  IA5String, JPEG) with defined comparison semantics.
+- **Referrals and aliases**: indirection for distributed or aliased entries.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| person / inetOrgPerson | Directory entry representing a human; attributes, not a login session. |
+| uid | User identifier string; often login name in POSIX contexts. |
+| cn (commonName) | Display or legal name component of DN. |
+| mail | Email address attribute; may be multi-valued. |
+| employeeNumber | Workforce identifier assigned by employer. |
+| ou (organizationalUnit) | Structural container in the DIT; department or division. |
+| dc (domainComponent) | DNS-domain component in DN; defines directory partition. |
+| member / uniqueMember | DN reference from a group entry to a member entry. |
+| groupOfNames | Group requiring at least one member; membership by DN reference. |
+| account (posixAccount) | UNIX account attributes bound to a person entry. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Identity is entry-centric**: a person is a directory entry located in a
+  hierarchical tree, not a free-floating actor.
+- **Naming implies structure**: DN path encodes organizational placement
+  (`ou=Engineering,ou=People,dc=example,dc=com`).
+- **Groups are entries**, not relationships; membership is an attribute on the
+  group entry pointing to member DNs.
+- **Person and account can co-reside** on one entry (inetOrgPerson +
+  posixAccount auxiliary class).
+- **Uniqueness** is per-directory-partition; `uid` or DN must be unique within
+  scope.
+- **No standard org-entity object class** for corporations; org structure is
+  implied by `ou` containers.
+- **Authorization** is external; groups are conventionally mapped to permission
+  sets by consuming applications.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- LDAP **inetOrgPerson entry** maps to **Identity Record** with optional
+  **Account** when posixAccount or login-binding attributes are present.
+- **DN** and **uid** are **Identifiers** within the directory **Scope**
+  (namespace).
+- **organizationalUnit** maps to a structural container, candidate
+  **Organization Unit** or scope partition — not automatically an
+  **Organization** actor.
+- **groupOfNames** maps to **Group** with **Membership Relationship** via
+  member DN references.
+- DN hierarchy suggests **Affiliation** or structural relationships but LDAP
+  does not type them explicitly.
+- LDAP reinforces that **Identifier** (DN) carries locational semantics
+  beyond bare value identity.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Account**: posixAccount is attribute bundle on a person entry; conflicts
+  with IAM Account as a distinct operational record.
+- **User**: directory "user" means entry or uid; conflicts with application
+  session user.
+- **Organization**: `ou` is a container, not a legal or commercial org actor.
+- **Group**: LDAP group is an entry with member attributes; conflicts with
+  SCIM Group resource and social community.
+- **Person**: inetOrgPerson is a schema label, not a legal natural-person
+  assertion.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| LDAP concept | Candidate canonical concept |
+| --- | --- |
+| inetOrgPerson entry | Identity Record |
+| posixAccount attributes | Account (co-located on same entry) |
+| DN | Identifier (locator + namespace) |
+| uid, mail, employeeNumber | Identifier |
+| organizationalUnit (ou) | Scope partition or org-unit container |
+| groupOfNames entry | Group |
+| member / uniqueMember | Membership Relationship |
+| dc partition | Scope / Namespace |
+| attribute values | Profile attributes or Claims on Identity Record |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should DN be modeled as a compound Identifier (locator + value) or split
+  into Namespace Scope plus local Identifier?
+- How should multi-valued `mail` attributes interact with synonymity assertions
+  when matching across systems?
+- Does `ou` hierarchy warrant a canonical **Organizational Structure**
+  relationship type, or remain a naming convention?
+- When inetOrgPerson and posixAccount coexist, is one Identity Record with
+  Account facet sufficient?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- RFC 4519: LDAP Attribute Types and Object Classes — https://datatracker.ietf.org/doc/html/rfc4519
+- RFC 2798: Definition of the inetOrgPerson Object Class — https://datatracker.ietf.org/doc/html/rfc2798
+- RFC 4511: LDAP Protocol — https://datatracker.ietf.org/doc/html/rfc4511
+- RFC 2307: POSIX account/group schema — https://datatracker.ietf.org/doc/html/rfc2307

research/identity-provisioning/ory-kratos-keto.md

@@ -1,50 +1,138 @@
-# Ory Kratos Keto
+# Ory Kratos and Keto
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Product documentation and open-source implementation reference for Ory Kratos
+(identity management) and Ory Keto (relationship-based authorization).
 
 ## Domain
 
-TODO: Classify the source domain.
+Cloud-native identity management, self-service flows, and ReBAC authorization
+separation.
 
 ## Why This Source Matters
 
-Ory Kratos identity/user management and Ory Keto relationship-based authorization separation.
+Ory Kratos identity/user management and Ory Keto relationship-based
+authorization separation.
+
+Ory explicitly separates identity management (Kratos) from authorization
+(Keto). This architectural split is a strong reference for identity-canon's
+P6 principle (authorization projections separate from identity model).
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Identity (Kratos)**: core identity record with traits (schema-defined
+  attributes), credentials, verifiable addresses, and recovery settings.
+- **Traits**: JSON attributes on an identity (email, name, etc.) governed by
+  identity schema.
+- **Credential**: password, OIDC link, TOTP, WebAuthn, or lookup secret
+  attached to an identity.
+- **Identity schema**: JSON Schema defining allowed traits and validation.
+- **Session**: authenticated session bound to an identity after credential
+  verification.
+- **Recovery / Verification flow**: self-service processes for account
+  recovery and address verification.
+- **Relation tuple (Keto)**: `namespace:object#relation@subject` assertion
+  for ReBAC checks.
+- **Namespace (Keto)**: typed object class in the authorization model with
+  defined relations and permissions.
+- **Subject (Keto)**: entity in a relation tuple; may reference a Kratos
+  identity or arbitrary identifier.
+- **Permission check**: evaluate whether a subject has a relation to an
+  object in a namespace.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Identity | Kratos record with traits and credentials; not authorization entity. |
+| Traits | Schema-validated attributes on an identity. |
+| Credential | Authentication factor bound to identity. |
+| Session | Active authenticated state for an identity. |
+| Schema | JSON Schema defining identity trait structure per use case. |
+| Relation tuple | Subject-relation-object fact in Keto. |
+| Namespace | Authorization object type with relation definitions. |
+| Subject | Authorization participant in a tuple. |
+| Object | Resource or entity being authorized in a tuple. |
+| Relation | Named edge type between subject and object. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Identity and authorization are separate services** with distinct storage
+  and APIs.
+- **Identity means traits + credentials**, not permissions.
+- **Traits are schema-driven**, allowing multiple identity schemas per
+  deployment (consumer vs. admin personas).
+- **Sessions are ephemeral** authentication state, not identity records.
+- **Authorization uses Zanzibar-style tuples** in Keto, not Kratos groups or
+  roles.
+- **Subjects in Keto may not map 1:1** to Kratos identities; integration is
+  application-level.
+- **No first-class organization or tenant** in Kratos core; multi-tenancy is
+  application concern.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- Kratos **Identity** maps to **Identity Record** with **Profile** (traits)
+  and **Credential** attachments.
+- Kratos does not use "account" explicitly; Identity is closer to Account +
+  Profile combined.
+- **Session** is ephemeral auth state, not a canonical entity; maps to
+  downstream session projection.
+- **Identity schema** maps to schema governance for Profile/Identity Record
+  attributes in a Scope.
+- Keto **relation tuple** maps to **Relationship Tuple** (authorization
+  projection) or typed **Relationship** with authz implication.
+- Keto **namespace** maps to **Authorization Domain** Scope.
+- Keto **subject** maps to **Authorization Principal** projection.
+- Strong evidence for **P6**: identity store and authorization graph are
+  orthogonal.
+- Supports S01 (single local identity), S10 (service identity via traits +
+  credentials), S11 (agent via separate Keto tuples).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Identity**: Kratos Identity is a record with credentials; conflicts with
+  bare "identity" meaning personhood or issuer subject.
+- **Subject**: Keto subject is authorization participant; OIDC subject is
+  issuer identifier; different layers.
+- **Traits vs. Profile**: traits are stored attributes; profile is
+  presentation — often conflated in Kratos.
+- **Namespace**: Keto namespace is authorization object type; DNS/LDAP
+  namespace is naming scope.
+- **No user term**: Kratos avoids "user" in API, but docs sometimes use it
+  informally.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| Ory concept | Candidate canonical concept |
+| --- | --- |
+| Kratos Identity | Identity Record + Account facet |
+| Traits | Profile attributes |
+| Credential | Credential |
+| Session | Ephemeral auth projection (non-canonical) |
+| Identity schema | Profile/record schema in Scope |
+| Keto relation tuple | Relationship Tuple (authorization projection) |
+| Keto namespace | Authorization Domain Scope |
+| Keto subject | Authorization Principal |
+| Keto object | Authorization Resource |
+| Keto relation | Relationship type (authz) |
+| Verification flow | Evidence Source event |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should Kratos Identity be split into Account + Profile in canon, or kept
+  as unified Identity Record?
+- How should Keto subjects that reference non-Kratos identifiers (e.g.,
+  `group:engineering#member`) map to canonical Group + Membership?
+- Does Kratos multi-schema support (consumer vs. admin) map to Persona or
+  separate Identity Records?
+- Should session be documented as a projection type in canon or remain
+  explicitly out of scope?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- Ory Kratos documentation — https://www.ory.sh/docs/kratos/
+- Ory Keto documentation — https://www.ory.sh/docs/keto/
+- Ory Kratos identity model — https://www.ory.sh/docs/kratos/manage-user-identities/identity-schema
+- Ory Keto relation tuples — https://www.ory.sh/docs/keto/concepts/relation-tuples

research/identity-provisioning/scim-rfc7643-rfc7644.md

@@ -1,50 +1,133 @@
-# Scim Rfc7643 Rfc7644
+# SCIM RFC 7643 and RFC 7644
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard. RFC 7643 defines the SCIM 2.0 core schema; RFC 7644 defines the
+SCIM 2.0 protocol for provisioning.
 
 ## Domain
 
-TODO: Classify the source domain.
+Identity provisioning and directory synchronization.
 
 ## Why This Source Matters
 
 SCIM 2.0: RFC 7643 schema and RFC 7644 protocol.
 
+SCIM is the dominant platform-neutral provisioning baseline. It defines
+resource types, attribute schemas, and CRUD/search operations for users and
+groups without prescribing authentication or authorization semantics.
+
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Resource**: a provisionable object with a `schemas` array, `id`, `meta`,
+  and typed attributes.
+- **User resource**: a person-oriented identity record with `userName`,
+  `name`, `emails`, `phoneNumbers`, `addresses`, `groups`, `roles`, and
+  `active` lifecycle state.
+- **Group resource**: a named collection with `displayName`, `members`, and
+  optional `type` (direct or indirect membership).
+- **Enterprise User extension** (RFC 7643 §4.3): adds `employeeNumber`,
+  `costCenter`, `organization`, `division`, `department`, and `manager` for
+  workforce semantics.
+- **Service Provider Config**: exposes supported features, authentication
+  schemes, and bulk limits.
+- **Meta block**: `resourceType`, `created`, `lastModified`, `version`,
+  `location` — lifecycle and versioning metadata on every resource.
+- **Operations**: Create, Read, Update, Delete, Search (POST /Users/.search),
+  and Bulk (RFC 7644 §3.7).
+- **PatchOp**: partial updates via `add`, `remove`, `replace` on paths.
+- **ExternalId**: cross-system correlation identifier supplied by the client.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| User | A provisionable identity record; not necessarily a login account in the consuming system. |
+| Group | A named collection of members; may represent authorization, organizational, or mailing-list grouping. |
+| userName | Unique identifier within the service provider's namespace; often used as login handle. |
+| externalId | Client-supplied correlation key for linking to an upstream system of record. |
+| active | Boolean lifecycle flag; inactive users retain the record but should lose access. |
+| member | Reference (`value`, `display`, `$ref`) to a User or Group in a Group's membership list. |
+| organization (extension) | Free-text employer or org name on a user; not a structured org resource. |
+| manager | Reference to another User who manages this user. |
+| roles | Application-specific role strings on the User resource; not RBAC policy. |
+| Service Provider | The system receiving provisioned resources. |
+| Client | The system sending provisioning requests. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- A **User** is the primary provisionable identity record; there is no separate
+  Account or Person resource type in core SCIM.
+- **Groups** absorb membership semantics; there is no first-class relationship
+  tuple beyond group membership references.
+- **Organization structure** is flattened into user attributes (department,
+  division, organization) rather than modeled as org entities.
+- **Lifecycle** is binary (`active` true/false) with soft-disable semantics;
+  deletion is a separate operation.
+- **Uniqueness** is scoped to the service provider; `userName` must be unique
+  within the SP namespace.
+- **Authorization** is out of scope; `roles` and group membership are hints
+  that downstream systems may map to policies.
+- **Multi-tenancy** is not defined; tenant isolation is an implementation
+  concern of the service provider.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- SCIM **User** maps to **Identity Record** (and often **Account** when the
+  SP uses it for login), not to **Natural Person**.
+- SCIM **Group** maps to **Group** collective actor with **Membership
+  Relationship** edges to member records.
+- `userName` and `externalId` are **Identifiers** within the SP **Scope**.
+- `active` maps to **Lifecycle State** on the Identity Record.
+- Enterprise extension `manager` suggests a **Representation** or reporting
+  relationship, but SCIM does not type it beyond a User reference.
+- `organization`, `department`, `division` are attribute-level hints, not
+  **Organization** actors; canon should not treat them as structured org graphs.
+- SCIM reinforces **P2** (person ≠ account) and **P5** (membership explicit)
+  but lacks actor-layer primitives.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **User**: SCIM User is a record, not a human being. Conflicts with
+  application "user" meaning login session holder.
+- **Group**: SCIM Group may mean LDAP security group, mailing list, or org
+  unit depending on deployment; conflicts with social **Community**.
+- **Role**: SCIM `roles` are opaque strings; conflicts with Cedar/OpenFGA
+  relationship-based roles and IAM permission bundles.
+- **Organization**: SCIM extension `organization` is a string attribute;
+  conflicts with **Organization** collective actor in IAM products.
+- **Active**: boolean disable vs. full lifecycle states (suspended, archived)
+  used in enterprise directories.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| SCIM concept | Candidate canonical concept |
+| --- | --- |
+| User resource | Identity Record (+ Account when login-enabled) |
+| Group resource | Group |
+| member reference | Membership Relationship |
+| userName | Identifier |
+| externalId | Identifier (cross-system correlation) |
+| active | Lifecycle State |
+| manager (extension) | Representation Relationship (weakly typed) |
+| organization/department/division | Affiliation hints; not Organization actors |
+| roles (extension) | Role labels; authorization projection input |
+| meta.created/lastModified | Evidence timestamps for record provenance |
+| Service Provider namespace | Scope |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should SCIM `externalId` be modeled as a dedicated **Identifier Binding**
+  or a generic Identifier with source metadata?
+- How should indirect group membership (`type: indirect`) map to canon
+  membership vs. inherited authorization projection?
+- Does the Enterprise User `manager` reference warrant a canonical
+  **Reporting Relationship** distinct from Representation?
+- Should a SCIM-only deployment without login map User exclusively to
+  Identity Record, skipping Account?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- RFC 7643: SCIM 2.0 Core Schema — https://datatracker.ietf.org/doc/html/rfc7643
+- RFC 7644: SCIM 2.0 Protocol — https://datatracker.ietf.org/doc/html/rfc7644
+- IETF SCIM working group overview — https://datatracker.ietf.org/wg/scim/about/

research/identity-provisioning/zitadel-organizations-projects.md

@@ -1,50 +1,130 @@
-# Zitadel Organizations Projects
+# ZITADEL Organizations and Projects
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Product documentation and implementation reference for ZITADEL's multi-instance
+organization, project, and grant model.
 
 ## Domain
 
-TODO: Classify the source domain.
+Cloud-native IAM, multi-tenancy, B2B SaaS identity, and fine-grained
+authorization grants.
 
 ## Why This Source Matters
 
 ZITADEL organizations, projects, roles, grants, and multi-tenancy concepts.
 
+ZITADEL is designed for multi-tenant SaaS from the ground up. Its org →
+project → grant hierarchy provides a live product vocabulary for separating
+customer organizations, application projects, and role grants.
+
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Instance**: ZITADEL deployment; top-level operational boundary.
+- **Organization**: primary tenant/customer entity; owns users, projects,
+  policies, and branding.
+- **Project**: application or service scope within an organization; owns roles,
+  applications, and grants.
+- **Application**: OIDC/SAML/API client registered under a project.
+- **User**: human identity within an organization with authentication methods
+  and profile.
+- **Machine user / service user**: non-human identity for API access.
+- **Grant**: assignment of project roles to a user or organization (including
+  cross-org grants for B2B).
+- **Role**: project-scoped permission label granted via grants.
+- **Organization domain**: verified domain for org discovery and policy.
+- **User grant vs. org grant**: direct user-to-project role vs. org-wide
+  project access.
+- **Actions / Flows**: customizable authentication and provisioning pipelines.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Organization | Customer or business entity; primary multi-tenant partition. |
+| Project | Application or product scope within an org. |
+| Grant | Role assignment linking user or org to a project. |
+| Role | Named capability within a project. |
+| User | Human identity record within an organization. |
+| Machine user | Service identity for programmatic access. |
+| Application | Registered client (OIDC/SAML/API) under a project. |
+| Instance | ZITADEL deployment boundary. |
+| Org grant | Organization-level access to a project's roles. |
+| Domain verification | Proof that an org controls an email domain. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Organization is the primary customer/tenant boundary** for users and
+  admin delegation.
+- **Project separates applications** within an org; roles are project-scoped.
+- **Grants are the authorization assignment mechanism**, not group membership.
+- **Users belong to exactly one organization** (per current product model);
+  cross-org access is via grants to shared projects.
+- **Machine users are first-class** identities distinct from human users.
+- **B2B** is modeled by granting one organization's project roles to another
+  organization's users or to the org itself.
+- **Branding and login policy** are org-scoped configuration.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- ZITADEL **Organization** maps to **Organization** actor and/or **Tenant**
+  Scope depending on deployment (often both: org as actor, org as tenant
+  boundary).
+- **Project** maps to **Application Scope** or child **Scope** under tenant.
+- **User** maps to **Account** (human); **Machine user** maps to **Service
+  Account**.
+- **Grant** maps to **Role** assignment via **Delegation** or Membership-like
+  relationship with authorization implication.
+- **Role** maps to **Role** (authorization projection).
+- **Application** maps to registered client within Application Scope.
+- **Domain verification** maps to **Claim** or **Evidence Source** for org
+  domain ownership.
+- Product vocabulary strongly supports S04 (vendor/customer) and S05
+  (delegated admin via grants).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Organization vs. Tenant**: ZITADEL uses "organization" for what SaaS
+  products often call "tenant."
+- **Grant vs. Membership**: grants assign roles; no generic group concept at
+  project level.
+- **User vs. Account**: product says "user" but means org-local identity
+  record with credentials.
+- **Project vs. Application**: project is container; application is client;
+  both compete with "tenant" in other products.
+- **Role vs. Grant**: role is definition; grant is assignment; IAM products
+  often collapse these.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| ZITADEL concept | Candidate canonical concept |
+| --- | --- |
+| Instance | Scope (deployment boundary) |
+| Organization | Organization + Tenant Scope |
+| Project | Application Scope |
+| User | Account |
+| Machine user | Service Account |
+| Application | Registered client / Application Scope |
+| Role | Role (authorization projection) |
+| Grant | Role assignment relationship (Delegation-like) |
+| Org grant | Membership or Delegation at org level |
+| Domain verification | Claim + Evidence Source |
+| User profile | Profile |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- When ZITADEL Organization serves as both commercial actor and isolation
+  boundary, should canon use one node with dual typing or separate Organization
+  + Tenant linked by Ownership?
+- How should cross-org project grants map: **Delegation**, **Trust**, or a
+  vendor-specific **Grant Relationship**?
+- Does single-org-per-user constraint affect canon modeling of multi-org
+  persons (S02)?
+- Should Machine user always map to Service Account, or sometimes to
+  Artificial Agent?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- ZITADEL documentation — https://zitadel.com/docs
+- ZITADEL Organizations — https://zitadel.com/docs/guides/manage/console/organizations
+- ZITADEL Projects and roles — https://zitadel.com/docs/guides/manage/console/projects

research/social-community-graphs/activitypub-actors-followers.md

@@ -1,50 +1,114 @@
-# Activitypub Actors Followers
+# ActivityPub Actors and Followers
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard. W3C ActivityPub (REC) with Activity Streams 2.0 vocabulary for
+federated social actors, inboxes, and follower relationships.
 
 ## Domain
 
-TODO: Classify the source domain.
+Federated social graphs, actor identity, following/followers, and server-side
+account representation.
 
 ## Why This Source Matters
 
-ActivityPub actors, inboxes, outboxes, followers, following, federation, and social identities.
+ActivityPub treats users as server-side actors with inboxes and outboxes. A
+person may have several actors across servers, mapping well to contextual
+identities and personas.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Actor**: Activity Streams object (Person, Service, Group, Organization,
+  Application) with `inbox`, `outbox`, `followers`, `following`, `liked`.
+- **Person actor**: human-associated actor on a federated server.
+- **Service / Application actor**: automated or app-mediated actor.
+- **Group actor**: collective actor with shared inbox/outbox.
+- **Follow activity**: actor A sends Follow to actor B; B may Accept or Reject.
+- **Followers / Following collections**: reverse-indexed social graph edges.
+- **preferredUsername**: handle local to the origin server.
+- **Actor ID (URL)**: globally unique actor URI, typically HTTPS profile URL.
+- **SharedInbox**: delivery optimization for addressing multiple actors.
+- **Public / followers-only addressing**: audience scoping for activities.
+- **WebFinger**: discovery of actor profile from `acct:user@domain`.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Actor | Server-hosted social entity with inbox/outbox; not necessarily one human. |
+| Person | Actor type for human-associated accounts. |
+| Follow | Directed activity establishing follower relationship. |
+| Follower | Actor who follows another actor. |
+| preferredUsername | Local handle on origin server. |
+| Actor ID | HTTPS URI identifying actor globally. |
+| Inbox / Outbox | Message endpoints for receiving/sending activities. |
+| Group (actor type) | Collective actor in ActivityPub sense. |
+| Service | Non-human automated actor type. |
+| acct: URI | Account identifier for WebFinger discovery. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Actor is the primary social identity unit**, hosted on an origin server.
+- **One human may operate multiple actors** across servers (implicit, not
+  standardized as same-person link).
+- **Following is a social subscription**, not membership or authorization.
+- **Actor ID is globally unique** within the fediverse namespace.
+- **Server is authority** for actor existence and deletion.
+- **Groups and Organizations are actor types**, not separate provisioning models.
+- **No standardized account linking** across actors for same natural person.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- ActivityPub **Actor** maps to **Actor** (Person → Natural Person association
+  via Account/Profile on origin server).
+- **Person actor** implies **Natural Person** operator but actor ≠ person.
+- **Service/Application actor** maps to **Artificial Agent**.
+- **Group actor** maps to **Community** or **Group** collective actor.
+- **Follow** maps to **Following Relationship** (directed, social).
+- **preferredUsername** + domain maps to **Identifier** in server **Scope**.
+- **Actor ID (URL)** maps to global **Identifier**.
+- Multi-server actors per person support S02, S09, S14 without mandatory
+  synonymity.
+- **followers-only** audience maps to Scope/audience boundary on Profile.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Actor vs. User**: ActivityPub actor is server entity; apps say user.
+- **Person vs. Natural Person**: Person is actor type, not verified human.
+- **Group**: ActivityPub Group actor vs. LDAP/SCIM group vs. IAM group.
+- **Follow vs. Member**: following ≠ community membership unless separately defined.
+- **Account vs. Actor**: `acct:` suggests account, but actor is richer object.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| ActivityPub concept | Candidate canonical concept |
+| --- | --- |
+| Actor (Person) | Actor + Profile + Account (on origin server) |
+| Actor (Service) | Artificial Agent + Service Account |
+| Actor (Group) | Community or Group collective actor |
+| Actor (Organization) | Organization collective actor |
+| Follow activity | Following Relationship |
+| Followers/Following collections | Relationship indexes |
+| preferredUsername | Identifier (local handle) |
+| Actor ID (URL) | Identifier (global) |
+| acct: URI | Identifier |
+| Origin server domain | Scope |
+| Inbox/Outbox | Operational endpoints (downstream) |
+| WebFinger | Discovery protocol (downstream) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should cross-server actors for one Natural Person require explicit Synonymity
+  Assertion, or remain unlinked by default?
+- Does ActivityPub Organization actor type map to Organization or Community
+  depending on moderation model?
+- How should moved-to / moved-from actor migration (if used) map to Identifier
+  Binding supersession?
+- Should followers-only audience be a Profile visibility Scope or separate
+  Relationship attribute?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- W3C ActivityPub — https://www.w3.org/TR/activitypub/
+- Activity Streams 2.0 — https://www.w3.org/TR/activitystreams-core/
+- WebFinger (RFC 7033) — https://datatracker.ietf.org/doc/html/rfc7033

research/social-community-graphs/foaf-agent-person-group-onlineaccount.md

@@ -1,50 +1,113 @@
-# Foaf Agent Person Group Onlineaccount
+# FOAF Agent Person Group OnlineAccount
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Semantic vocabulary. FOAF (Friend of a Friend) RDF vocabulary for persons,
+agents, groups, and online accounts.
 
 ## Domain
 
-TODO: Classify the source domain.
+Semantic web social identity, person/agent distinction, and account
+representation.
 
 ## Why This Source Matters
 
-FOAF Agent, Person, Organization, Group, OnlineAccount, and social relationship vocabulary.
+FOAF distinguishes persons, agents, organizations, groups, accounts, and
+membership-like properties — an early explicit separation of actor, account,
+and online presence.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **foaf:Person**: a person (human); may have name, homepage, depiction.
+- **foaf:Agent**: anything that can do things; superclass of Person, Organization,
+  Group.
+- **foaf:Organization**: collective agent with members and name.
+- **foaf:Group**: collective agent with `member` property linking to agents.
+- **foaf:OnlineAccount**: account on a service; links via `accountServiceHomepage`
+  and `accountName`.
+- **foaf:OnlineChatAccount / OnlineGamingAccount**: specialized account types.
+- **foaf:member**: agent belongs to group (inverse of Group membership).
+- **foaf:knows**: social acquaintance link between agents (not authorization).
+- **foaf:mbox / mbox_sha1sum**: email or hashed email identifiers.
+- **foaf:openid**: OpenID identifier for agent.
+- **foaf:Document / Image**: non-agent resources.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Person | Human being in FOAF sense. |
+| Agent | Anything capable of action; includes persons and collectives. |
+| Organization | Named collective agent. |
+| Group | Collective agent with explicit members. |
+| OnlineAccount | Presence on a service with account name. |
+| member | Membership link from group to agent. |
+| knows | Social network acquaintance between agents. |
+| accountName | Handle on a service. |
+| accountServiceHomepage | Service URL defining account namespace. |
+| mbox | Email identifier (often `mailto:` URI). |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Agent is the root actionable type**; Person is a specialization.
+- **Person is explicitly human**, separate from accounts.
+- **OnlineAccount is not the person**; it is an account on a service linked
+  to an agent.
+- **Groups and Organizations are agents** with member properties.
+- **Social knows is weak affiliation**, not trust or authorization.
+- **Identifiers (mbox, openid) are properties**, not first-class scoped objects.
+- **RDF graph allows multiple incomplete assertions** about same agents.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- FOAF **Person** maps closely to **Natural Person**.
+- FOAF **Agent** maps to **Actor**.
+- FOAF **Organization** / **Group** map to **Organization** / **Group**
+  collective actors.
+- FOAF **OnlineAccount** maps to **Account** with service **Scope** defined
+  by `accountServiceHomepage`.
+- **accountName** maps to **Identifier**.
+- **member** maps to **Membership Relationship**.
+- **knows** maps to **Affiliation Relationship** (social, weak).
+- FOAF is strong evidence for **P1** (actor root) and **P2** (person ≠ account).
+- Supports S01, S08, S09 with explicit person/account split.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Agent vs. Artificial Agent**: FOAF Agent includes humans; canon Artificial
+  Agent is non-human only.
+- **Group vs. Community**: FOAF Group is generic collective; community implies
+  participation norms.
+- **OnlineAccount vs. Profile**: FOAF account is service presence; profile is
+  broader presentation surface.
+- **knows vs. Following**: knows is bidirectional acquaintance; ActivityPub
+  Follow is directed.
+- **mbox vs. Identifier**: mbox is contact + identifier; conflation risk.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| FOAF concept | Candidate canonical concept |
+| --- | --- |
+| Person | Natural Person |
+| Agent | Actor |
+| Organization | Organization |
+| Group | Group |
+| OnlineAccount | Account |
+| accountName | Identifier |
+| accountServiceHomepage | Scope (service namespace) |
+| member | Membership Relationship |
+| knows | Affiliation Relationship |
+| mbox / openid | Identifier |
+| depiction / name | Profile attributes |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should FOAF OnlineAccount always imply Account, or sometimes Profile only?
+- How should `mbox_sha1sum` map for privacy-preserving synonymity (weak match)?
+- Does FOAF Group map to Group only, or also Community when informal?
+- Should knows remain Affiliation, or split into Following vs. acquaintance?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- FOAF vocabulary specification — http://xmlns.com/foaf/spec/
+- FOAF 0.99 RDF schema — http://xmlns.com/foaf/0.1/

research/social-community-graphs/schema-org-person-organization-membership.md

@@ -1,50 +1,112 @@
-# Schema Org Person Organization Membership
+# Schema.org Person Organization Membership
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Semantic vocabulary. Schema.org types and properties for Person, Organization,
+membership, and role-like affiliations.
 
 ## Domain
 
-TODO: Classify the source domain.
+Structured data about people and organizations, SEO/social graphs, and
+membership representation on the web.
 
 ## Why This Source Matters
 
-Schema.org Person, Organization, memberOf, affiliation, and public entity metadata.
+Schema.org distinguishes persons, organizations, membership, employee roles,
+and affiliation properties — widely used for web-scale person/org modeling.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Person**: living human; properties include `name`, `email`, `identifier`,
+  `sameAs`, `affiliation`, `worksFor`, `memberOf`.
+- **Organization**: business, club, or other collective; `member`, `employee`,
+  `department`, `subOrganization`, `parentOrganization`.
+- **OrganizationRole**: intermediate type linking person to organization with
+  `roleName`, `startDate`, `endDate`.
+- **member / memberOf**: reciprocal membership between Person and Organization.
+- **employee / worksFor**: employment relationship properties.
+- **affiliation**: organization a person is affiliated with (looser than member).
+- **sameAs**: URL of related entity — often used for weak equivalence/synonymity.
+- **identifier**: PropertyValue or Text for external IDs.
+- **SportsTeam / PerformingGroup**: specialized Organization subtypes.
+- **ProgramMembership**: membership in a program with tier/benefits.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Person | Human being in structured data. |
+| Organization | Collective entity (company, club, NGO). |
+| memberOf | Person belongs to Organization. |
+| member | Organization has Person as member. |
+| employee | Person employed by Organization. |
+| worksFor | Inverse employment link. |
+| affiliation | Looser org association for Person. |
+| sameAs | Related/equivalent resource URL (weak linking). |
+| OrganizationRole | Named role with temporal bounds. |
+| subOrganization | Org hierarchy child. |
+| identifier | External ID for entity. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Person means human** in schema.org intent.
+- **Membership and employment are properties**, not reified relationship objects
+  (except OrganizationRole).
+- **sameAs is informal equivalence** between web resources, not verified identity.
+- **Organizations can nest** via subOrganization/parentOrganization.
+- **Roles can be typed** via OrganizationRole with dates.
+- **No authentication or authorization** semantics.
+- **Properties are multi-valued**; one person can have many memberships.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- Schema.org **Person** maps to **Natural Person**.
+- **Organization** maps to **Organization** collective actor.
+- **memberOf / member** map to **Membership Relationship**.
+- **employee / worksFor** map to **Affiliation Relationship** or employment
+  specialization of Membership.
+- **affiliation** maps to **Affiliation Relationship** (looser).
+- **OrganizationRole** maps to **Role** relationship with temporal bounds.
+- **subOrganization** maps to structural relationship between Organization
+  actors (child/parent).
+- **sameAs** maps to **weak Synonymity Assertion** between web resources —
+  high conflation risk if treated as strong link.
+- **identifier** maps to **Identifier** PropertyValue.
+- Supports S03 (sub-orgs), S07 (informal groups as Organization subtypes), S08.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Person vs. Profile**: schema.org Person is often used for public profile page.
+- **member vs. employee**: overlapping employment semantics; not always distinct.
+- **sameAs vs. Synonymity**: sameAs is SEO linking, not identity proofing.
+- **Organization vs. Community**: SportsTeam/PerformingGroup blur social vs. org.
+- **Role vs. OrganizationRole**: roleName may be job title or permission label.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| Schema.org concept | Candidate canonical concept |
+| --- | --- |
+| Person | Natural Person |
+| Organization | Organization |
+| memberOf / member | Membership Relationship |
+| employee / worksFor | Affiliation or employment Membership |
+| affiliation | Affiliation Relationship |
+| OrganizationRole | Role + Membership with temporal bounds |
+| subOrganization | Organization hierarchy Relationship |
+| sameAs | Weak Synonymity Assertion (caution) |
+| identifier | Identifier |
+| ProgramMembership | Membership Relationship (program scope) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should sameAs ever promote beyond weak Synonymity without additional evidence?
+- Does OrganizationRole warrant a canonical temporal Relationship subtype?
+- How should ProgramMembership map vs. Community membership?
+- Should subOrganization be a distinct Relationship type or Organization attribute?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- Schema.org Person — https://schema.org/Person
+- Schema.org Organization — https://schema.org/Organization
+- Schema.org OrganizationRole — https://schema.org/OrganizationRole
+- Schema.org sameAs — https://schema.org/sameAs

research/social-community-graphs/webid-solid-profile.md

@@ -1,50 +1,108 @@
-# Webid Solid Profile
+# WebID and Solid Profile
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard and ecosystem specification. WebID (W3C CG) for decentralized
+identifiers; Solid Protocol for user-controlled data pods and profiles.
 
 ## Domain
 
-TODO: Classify the source domain.
+Decentralized identity-style profile discovery, user-controlled storage, and
+WebID-based identification.
 
 ## Why This Source Matters
 
-WebID and Solid profile concepts for decentralized/social identity and profile discovery.
+WebID/Solid support user-controlled profiles and decentralized identity-style
+profile discovery, relevant to persona, identifier, and data-sovereignty
+semantics.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **WebID**: HTTP(S) URI identifying an agent; dereferencing yields profile
+  document (RDF).
+- **WebID profile document**: RDF description of agent with type, name,
+  certificates, and links.
+- **Solid Pod**: user-controlled personal data store with access control.
+- **Solid Profile**: extended profile in pod with extended attributes and
+  preferences.
+- **WebID-OIDC**: bridge binding OIDC authentication to WebID URI.
+- **Agent type in profile**: self-described person or organization.
+- **ACL (WAC / ACP)**: resource-level access control on pod resources.
+- **Type Index**: registry of resource types in a pod.
+- **Identity provider linkage**: OIDC issuer associated with WebID.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| WebID | HTTP URI identifying an agent; profile at same URL. |
+| Profile document | RDF at WebID URI describing the agent. |
+| Pod | User-controlled storage space. |
+| Solid Profile | Profile data stored in pod. |
+| Agent | Entity described by WebID (person or org). |
+| WebID-OIDC | OIDC flow producing ID token with WebID claim. |
+| ACL | Access control on pod resources. |
+| Type Index | Discovery of pod resource categories. |
+| issuer | OIDC provider linked to WebID authentication. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Identifier (WebID URI) is primary**; profile is dereferenceable description.
+- **User controls data placement** in pod, not only profile attributes.
+- **Agent self-describes** type (person/org) in RDF profile.
+- **Authentication can bind OIDC subject to WebID** via WebID-OIDC.
+- **Access control is resource-centric** on pod, separate from identity record.
+- **No central directory**; discovery via URI dereferencing.
+- **Multiple profiles/pods per person** possible across providers.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- **WebID URI** maps to **Identifier** (globally dereferenceable).
+- **Profile document** maps to **Profile** with RDF attributes.
+- **Pod** maps to user-controlled **Scope** for data storage.
+- **Agent in profile** maps to **Actor** (Natural Person or Organization).
+- **WebID-OIDC binding** maps to **Synonymity Assertion** / **Identifier
+  Binding** between OIDC `sub`+`iss` and WebID URI.
+- **ACL** maps to authorization projection on resources in pod Scope.
+- Supports S14 (pseudonymous/scoped identity), S02 (multiple profiles), user
+  sovereignty goals from ResearchSeed.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **WebID vs. DID**: both decentralized identifiers; different ecosystems and
+  resolution models.
+- **Profile vs. Account**: Solid profile is data surface; may not include
+  login credentials on same system.
+- **Agent vs. Actor**: WebID agent is self-described entity; canon Actor is
+  broader participation root.
+- **Identity vs. WebID**: developers equate WebID with whole identity.
+- **ACL vs. Authorization Principal**: pod ACL uses WebID URIs as agents.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| WebID/Solid concept | Candidate canonical concept |
+| --- | --- |
+| WebID URI | Identifier |
+| Profile document | Profile |
+| Solid Pod | Scope (user-controlled data) |
+| Agent (in RDF) | Actor |
+| WebID-OIDC binding | Identifier Binding / Synonymity Assertion |
+| OIDC iss + sub | Scoped Identifier |
+| ACL agent | Authorization Principal (WebID URI) |
+| Type Index | Profile/discovery metadata |
+| Pod resource | Resource (downstream) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should WebID URI be a distinct Identifier subtype vs. generic HTTP URI?
+- How should WebID-OIDC binding strength compare to OIDC pairwise sub (S14)?
+- Does pod Scope warrant a canonical "Data Scope" specialization?
+- Should Solid ACL remain purely authorization projection, or inform
+  Relationship types for resource sharing?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- Solid Protocol — https://solidproject.org/TR/protocol
+- WebID 1.0 (community spec) — https://www.w3.org/2005/Incubator/webid/wiki/Identity_Providers
+- WebID-OIDC — https://solid.github.io/webid-oidc-spec/
+- Solid Access Control (ACP) — https://solidproject.org/TR/acl-spec

research/verifiable-claims/did-core.md

@@ -1,50 +1,109 @@
-# Did Core
+# W3C DID Core
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard. W3C Decentralized Identifiers (DIDs) v1.0 Core.
 
 ## Domain
 
-TODO: Classify the source domain.
+Decentralized identifiers, verifiable identity subjects, DID documents, and
+verification methods.
 
 ## Why This Source Matters
 
-W3C DID Core: decentralized identifiers, DID subjects, DID controllers, verification methods, and services.
+DIDs provide externally controlled identifiers with cryptographic verification
+methods, relevant to portable identity, issuer independence, and synonymity
+across systems.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **DID**: globally unique URI following `did:method:identifier` syntax.
+- **DID subject**: entity identified by a DID; may be person, org, or thing.
+- **DID controller**: entity authorized to change DID document (may differ from
+  subject).
+- **DID document**: JSON-LD document resolved from DID; contains verification
+  methods, services, and controllers.
+- **Verification method**: cryptographic key or proof mechanism for authentication
+  or signing.
+- **Service endpoint**: machine-readable service URL in DID document.
+- **DID method**: specific ledger or resolution rules (`did:web`, `did:key`,
+  `did:ion`, etc.).
+- **Resolution**: process of retrieving DID document from DID URL.
+- **Also-known-as / equivalentId**: related identifier properties (method-specific).
+- **Delegation**: controller grants another party control via verification
+  relationship.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| DID | Decentralized identifier string. |
+| DID subject | Entity the DID names. |
+| DID controller | Party that can update DID document. |
+| DID document | Resolved metadata about DID. |
+| Verification method | Key/material for prove/control. |
+| Service | Endpoint declaration in document. |
+| DID method | Resolution and registry rules. |
+| Resolve | Fetch DID document. |
+| Controller | Authority over DID lifecycle. |
+| Subject (DID) | Identified party; not necessarily controller. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Identifier is primary**; subject is named by DID, not stored in central directory.
+- **Control is cryptographic** via verification methods and controllers.
+- **Subject and controller may diverge** (custodial wallets, organizational DIDs).
+- **DID document is mutable** under controller authority.
+- **Methods vary in persistence, privacy, and registry model.**
+- **No built-in person/account distinction**; semantics are method and usage dependent.
+- **Relationships to other DIDs** may appear as services or custom properties.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- **DID** maps to **Identifier** (decentralized, resolvable).
+- **DID subject** maps to **Actor** or target of **Claim** depending on usage.
+- **DID controller** maps to **Representation** or **Ownership** relationship
+  over identifier control.
+- **Verification method** maps to **Credential** (cryptographic).
+- **DID document** maps to **Profile** / metadata record for Identifier.
+- **Service endpoint** maps to operational binding (downstream).
+- DID-based strong binding supports S13 (verified link), S14 (pseudonymous
+  scoped identity when using pairwise/privacy-preserving methods).
+- Reinforces **P8** (evidence via cryptographic verification).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Subject**: DID subject vs. OIDC sub vs. authorization subject.
+- **Controller vs. Owner**: controller is key/document authority; owner is
+  broader relationship.
+- **Identity vs. DID**: DID is identifier, not identity record.
+- **Credential vs. Verification method**: verification method is key material;
+  VC is claim artifact.
+- **Resolve vs. Lookup**: resolution is method-specific; not uniform directory.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| DID Core concept | Candidate canonical concept |
+| --- | --- |
+| DID | Identifier |
+| DID subject | Actor (context-dependent) |
+| DID controller | Representation or Ownership Relationship |
+| DID document | Profile / Identifier metadata record |
+| Verification method | Credential |
+| Service endpoint | Operational binding (downstream) |
+| DID method namespace | Scope (method-specific) |
+| Resolution result | Evidence Source |
+| equivalentId / alsoKnownAs | Synonymity Assertion (method-dependent) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should DID be a distinct Identifier subtype with method and resolution metadata?
+- How should subject/controller split map for organizational vs. personal DIDs?
+- Does equivalentId warrant weak or strong Synonymity by default?
+- How do DID methods with pairwise features (e.g., did:ion pairwise) map to
+  Scoped Identifier?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- W3C DID Core v1.0 — https://www.w3.org/TR/did-core/
+- DID Specification Registries — https://www.w3.org/TR/did-spec-registries/

research/verifiable-claims/openid4vc.md

@@ -1,50 +1,106 @@
-# Openid4Vc
+# OpenID for Verifiable Credentials (OpenID4VC)
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard suite. OpenID4VCI (issuance), OpenID4VP (presentation), and related
+OAuth 2.0 profiles for verifiable credentials.
 
 ## Domain
 
-TODO: Classify the source domain.
+VC issuance and presentation protocols, wallet-holder flows, and federation of
+verifiable credential ecosystems.
 
 ## Why This Source Matters
 
-OpenID for Verifiable Credentials concepts and identity/federation implications.
+OpenID4VC bridges OAuth/OIDC infrastructure with W3C Verifiable Credentials,
+connecting federation protocols to portable claim semantics.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **OpenID4VCI**: issuer-to-holder credential issuance using OAuth 2.0 access
+  tokens and credential offers.
+- **OpenID4VP**: holder-to-verifier presentation using authorization requests
+  and VP tokens.
+- **Credential Issuer**: OIDC/OAuth entity issuing VCs.
+- **Wallet / Holder**: stores credentials and responds to presentation requests.
+- **Verifier**: requests and validates presentations.
+- **Credential Offer**: deeplink/URI initiating issuance to wallet.
+- **Proof of possession**: holder proves control of key bound to credential.
+- **Authorization Request (VP)**: verifier specifies required credential types.
+- **SD-JWT VC**: selective disclosure JWT credential format (parallel track).
+- **mDL / ISO 18013-5**: mobile document format integrated in some profiles.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Credential Issuer | OAuth/OIDC party issuing VCs. |
+| Wallet | Holder software storing VCs. |
+| Verifier | Party requesting VP from wallet. |
+| Credential offer | Issuance initiation artifact. |
+| Authorization request | Presentation request to wallet. |
+| VP token | Presentation response token. |
+| c_nonce | Issuance proof challenge. |
+| format | VC encoding (jwt_vc, ldp_vc, sd-jwt). |
+| credential_definition | Type/filter for requested credential. |
+| presentation_definition | Verifier's input requirements. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Issuance is OAuth-mediated** between issuer, wallet, and optional broker.
+- **Presentation is verifier-driven** with explicit requested claim types.
+- **Holder wallet is trust boundary** for credential storage and selective disclosure.
+- **OIDC identity may bootstrap wallet** or issuer trust.
+- **Multiple credential formats** coexist (JWT, JSON-LD, SD-JWT).
+- **Revocation/status checked at verification** time.
+- **Pairwise issuance** possible for privacy-preserving credentials.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- OpenID4VCI issuance flow maps to **Credential** creation with **Claim**,
+  **Issuer** Scope, and **Evidence Source** (issuance event).
+- OpenID4VP presentation maps to verifier **Trust Relationship** evaluating
+  **Credential** + **Claim** subset.
+- **Wallet** maps to holder **Actor** + storage **Scope** (custody boundary).
+- OIDC authentication preceding issuance maps to **Authenticated Subject** →
+  **Account** → VC **Subject** binding via **Identifier Binding**.
+- Selective disclosure supports S14 (privacy-limited claims).
+- Bridges federation (OIDC) and VC layers for S13 strong links.
+- Reinforces projection pattern: OIDC for auth, VC for claims.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Issuer**: OIDC issuer vs. VC issuer — often same entity, different roles.
+- **Subject**: OIDC sub in token vs. VC credentialSubject.
+- **Credential**: OAuth credential vs. Verifiable Credential.
+- **Verifier vs. RP**: overlapping roles with added VP verification.
+- **Wallet vs. Account**: wallet is credential store, not always login account.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| OpenID4VC concept | Candidate canonical concept |
+| --- | --- |
+| Credential Issuer | Issuer Scope + Trust Relationship |
+| Wallet / Holder | Actor (custody) + Scope |
+| Verifier | Verifier / RP Scope |
+| Issued VC | Credential + Claim |
+| Credential offer | Evidence Source (issuance initiation) |
+| Presentation | Credential presentation (operational) |
+| OIDC auth prior to issuance | Authenticated Subject → Identifier Binding |
+| presentation_definition | Verifier policy (downstream) |
+| SD-JWT selective disclosure | Privacy-limited Claim exposure |
+| Status check | Lifecycle State verification |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should wallet custody be a canonical Scope specialization (Holder Scope)?
+- How should OIDC sub to VC subject binding strength be classified (weak vs.
+  strong Synonymity)?
+- Does OpenID4VP verifier policy belong in canon or strictly downstream?
+- Should SD-JWT credentials map to Credential subtype with disclosure metadata?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- OpenID4VCI — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
+- OpenID4VP — https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
+- OpenID4VCI SD-JWT profile — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-sd-jwt-vc

research/verifiable-claims/vc-data-model-2.md

@@ -1,50 +1,110 @@
-# Vc Data Model 2
+# W3C Verifiable Credentials Data Model 2.0
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard. W3C Verifiable Credentials Data Model 2.0 (WD/CR as applicable).
 
 ## Domain
 
-TODO: Classify the source domain.
+Verifiable claims, issuers, holders, verifiers, credential lifecycle, and
+portable identity assertions.
 
 ## Why This Source Matters
 
-W3C Verifiable Credentials Data Model 2.0: issuer, holder, subject, verifier, claims, presentations.
+Verifiable Credentials formalize issuer-holder-verifier semantics for portable,
+cryptographically verifiable claims about subjects — central to evidence-based
+identity modeling.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Verifiable Credential (VC)**: tamper-evident credential making claims about
+  a subject, signed by issuer.
+- **Verifiable Presentation (VP)**: bundle of VCs (and proofs) presented by holder
+  to verifier.
+- **Issuer**: entity that asserts claims and signs VC.
+- **Holder**: entity possessing VC (may or may not be subject).
+- **Verifier**: entity checking VC/VP validity.
+- **Subject**: entity claims are about (`credentialSubject`).
+- **Claim**: individual statement within credentialSubject.
+- **Proof**: cryptographic proof of integrity and issuer authenticity.
+- **Credential schema**: type and structure definition for VC.
+- **Status**: revocation/suspension via StatusList2021 or similar.
+- **ValidFrom / ValidUntil**: temporal validity window.
+- **Evidence**: supporting documents referenced in VC (DID, attachments).
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| Verifiable Credential | Signed claim set about subject. |
+| Presentation | Holder-submitted package for verification. |
+| Issuer | Signing authority for claims. |
+| Holder | Party storing/presenting VC. |
+| Verifier | Party validating VC/VP. |
+| Subject | Entity described by credentialSubject. |
+| credentialSubject | Claim object about subject. |
+| Proof | Cryptographic verification data. |
+| StatusList | Revocation/suspension mechanism. |
+| type | VC semantic type(s). |
+| validFrom / validUntil | Temporal bounds. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Claims are assertions, not ground truth** until verified by verifier policy.
+- **Issuer authority is explicit** and cryptographically attributable.
+- **Holder may differ from subject** (custodial credentials).
+- **Revocation is first-class** via status mechanisms.
+- **Temporal validity matters** for employment, membership, age claims.
+- **Selective disclosure** may hide parts of credentialSubject (privacy).
+- **Subject may be identified by DID, URI, or other identifier.**
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- **VC** maps to **Credential** containing **Claim** set.
+- **credentialSubject** claims map to individual **Claim** objects about
+  **Actor**, **Membership**, or attributes.
+- **Issuer** maps to issuer **Scope** + **Trust Relationship**.
+- **Holder** maps to **Actor** or **Account** holding credential.
+- **Verifier** maps to relying party evaluating Trust + Evidence.
+- **Subject** maps to **Actor** or Identifier target.
+- **Status/revocation** maps to **Lifecycle State** on Credential/Claim.
+- **validFrom/validUntil** map to relationship/assertion temporal bounds.
+- Supports S13 (strong verified link), S03 (org membership claims), S06
+  (guardian credentials if issued).
+- Reinforces **P7** and **P8**: claims are evidenced assertions.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Credential vs. Credential (auth)**: VC vs. password/OIDC token.
+- **Subject**: VC subject vs. OIDC sub.
+- **Claim vs. Attribute**: VC claim vs. directory/LDAP attribute.
+- **Holder vs. Account**: holder is possession role, not login account.
+- **Verifier vs. RP**: overlapping but VC adds cryptographic verification step.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| VC Data Model concept | Candidate canonical concept |
+| --- | --- |
+| Verifiable Credential | Credential |
+| credentialSubject claim | Claim |
+| Issuer | Issuer Scope + Trust Relationship |
+| Holder | Actor / Account (possession role) |
+| Verifier | Relying party / verifier Scope |
+| Subject | Actor or Identifier target |
+| Proof | Evidence Source (cryptographic) |
+| StatusList entry | Lifecycle State (revoked/suspended) |
+| validFrom / validUntil | Temporal bounds on Claim |
+| Presentation | Credential bundle (operational) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should canon treat VC as Credential subtype or parallel Claim container?
+- How should membership VCs map to Membership Relationship vs. Claim only?
+- Does selective disclosure require Persona or Scoped Identifier linkage?
+- Should issuer DID vs. issuer URL be standardized Identifier forms?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- W3C VC Data Model 2.0 — https://www.w3.org/TR/vc-data-model-2.0/
+- VC Data Model 1.1 (widely deployed) — https://www.w3.org/TR/vc-data-model/
+- Status List 2021 — https://www.w3.org/TR/vc-status-list-2021/