diff --git a/DownstreamRecommendations.md b/DownstreamRecommendations.md index 71ff9e8..6133ee0 100644 --- a/DownstreamRecommendations.md +++ b/DownstreamRecommendations.md @@ -1,34 +1,101 @@ # Downstream Recommendations -Status: draft. This file captures implementation ideas derived from the canon -without moving implementation work into this repository. +Status: draft. Updated after IDENTITY-WP-0003 corpus backfill. Implementation +ideas derived from the canon; no implementation in this repository. ## Recommended Consumption Pattern Downstream repositories should consume identity-canon as a conceptual reference. -They should map their schemas, APIs, CLI commands, UI labels, and authorization -policies to canonical terms, but they should not depend on this repository as a -runtime package unless a later explicit package is extracted. +Map schemas, APIs, CLI commands, UI labels, and authorization policies to +canonical terms. Do not depend on this repository as a runtime package unless a +later explicit package is extracted. -## Near-Term Recommendations +## Schema Design -- When designing user-management schemas, separate Natural Person, Account, - Profile, Credential, and Principal fields. -- When designing tenant-aware systems, model Tenant as a scope and relate it to - Organization, Customer, Vendor, and Realm explicitly. -- When designing organization features, do not reuse Group or Role as a generic - replacement for Organization. -- When designing authorization adapters, treat Principal and relationship - tuples as projections from canonical actors, accounts, and relationships. -- When designing account-linking features, store Synonymity Assertions with - source, evidence, confidence, scope, lifecycle state, and privacy controls. -- When designing UI copy, use product-friendly labels but maintain internal - mappings to canonical concepts. +- Separate Natural Person, Account, Profile, Credential, and Principal in + user-management schemas. Corpus confirms SCIM/LDAP use "user" for records, + Keycloak/ZITADEL for accounts. +- Model Tenant as Scope; relate explicitly to Organization, Customer, Vendor, + and Realm. ZITADEL org-as-tenant and Keycloak realm-as-namespace are common + mapping patterns. +- Store Synonymity Assertions with relation type, strength, scope, evidence, + source system, lifecycle state, and privacy classification. Never default to + destructive merge for duplicate detection. +- Attach IAL/AAL/FAL (or equivalent) to bindings and federation relationships, + not as a single account trust field. +- Preserve source record IDs (SCIM id, LDAP DN, externalId, OIDC iss+sub) as + Identifiers with provenance. + +## Authorization Adapters + +- Project canonical Membership, Delegation, and Administration relationships + into Zanzibar/OpenFGA tuples rather than encoding social meaning in authz + graphs. +- Map Cedar Principal/Resource/Action/Context from Account and Relationship; + carry delegation in Context, not by overloading Principal identity. +- When using Cerbos derived roles, trace ownership/admin derived roles back to + canonical Ownership or Administration relationships where possible. +- Keep authz `user:` identifiers aligned with Account IDs or Authenticated + Subject bindings via explicit mapping table. + +## Federation Adapters + +- Treat OIDC iss+sub and SAML persistent NameID as strong Synonymity Assertion + candidates after RP verification policy. +- Treat pairwise OIDC sub as Scoped Identifier with privacy-limited assertion. +- Subscribe to SSF/CAEP/RISC events to drive Lifecycle State on accounts, + credentials, and identifier bindings. +- Separate OIDC authentication (Authenticated Subject) from VC claims + (Credential + Claim) per OpenID4VC patterns. + +## Provisioning Adapters + +- SCIM User → Identity Record; map Group → Group + Membership edges. +- LDAP inetOrgPerson → Identity Record; posixAccount → Account facet on same + or linked record. +- Do not promote SCIM `organization` string to Organization actor without + separate org entity. + +## Social and Profile Adapters + +- ActivityPub Actor → Actor + Profile on origin Scope; Follow → Following + Relationship only. +- FOAF OnlineAccount → Account with service Scope from accountServiceHomepage. +- Schema.org sameAs → weak Synonymity Assertion only; require review before + promotion to strong. + +## Privacy and Entity Resolution + +- Implement probabilistic matching as weak `probably_same_as` assertions in + `proposed` lifecycle state with review queue. +- Store GDPR pseudonymization re-identification keys in separately secured + scope with restricted access. +- Support assertion revocation and supersession (SSF identifier-changed, manual + unlink) without deleting source records. + +## UI Copy + +- Use product-friendly labels externally; maintain internal canonical mappings. +- Avoid showing "user" in schema or API names without a mapping note. ## Avoid For Now - Do not implement identity provider integrations in this repository. - Do not add database migrations or production APIs here. -- Do not treat this glossary as a finalized schema. -- Do not use `user` as a canonical table, API, or class name without a mapping - note that explains which canonical concept it represents. +- Do not treat the glossary as a finalized schema. +- Do not use MDM golden-record merge as default linking behavior. +- Do not collapse Realm, Tenant, and Organization into one table without + relationship modeling. + +## Suggested Adapter Inventory + +| Source family | Primary canonical mapping | Common projection | +| --- | --- | --- | +| SCIM / LDAP | Identity Record, Group, Membership | Account, Principal | +| Keycloak / ZITADEL | Account, Organization, Realm/Tenant | Role, OIDC Subject | +| OIDC / SAML | Authenticated Subject, Identifier | Account link assertion | +| Zanzibar / OpenFGA | Relationship Tuple | Membership, admin edges | +| Cedar / Cerbos | Principal, Resource, Action, Context | Role, derived ownership | +| ActivityPub / FOAF | Actor, Profile, Following | — | +| DID / VC | Identifier, Credential, Claim | Trust relationship | +| Entity resolution | Synonymity Assertion | — | \ No newline at end of file diff --git a/OpenQuestions.md b/OpenQuestions.md index 27a3b4b..d84fed9 100644 --- a/OpenQuestions.md +++ b/OpenQuestions.md @@ -1,35 +1,163 @@ # Open Questions -Status: draft. These questions are intentionally non-secret and -implementation-neutral. +Status: draft. Updated after IDENTITY-WP-0003 corpus backfill. Questions are +intentionally non-secret and implementation-neutral. Resolved items are noted +with corpus citations. ## Canon Questions -- Should Realm stay a Scope specialization, or does it need its own canonical - concept because of issuer and federation semantics? -- Should Customer Account become a canonical concept, or should customer - account records remain downstream commercial modeling? -- Should Team be modeled as a Group, Organization Unit, Community, or a - separate specialization? -- Should Legal Entity be a specialization of Organization or a relationship - between an Organization and a legal system? -- What fields are mandatory for every Relationship versus only for sensitive - relationships such as delegation, representation, and synonymity? +### Realm as Scope specialization + +**Status:** Tentatively resolved — keep Realm as Scope specialization. + +Keycloak source review (`research/identity-provisioning/keycloak-organizations.md`) +shows realm as hard identity/admin namespace, distinct from Organization B2B +overlay. Federation issuers (OIDC, SAML) also use issuer namespace semantics +compatible with Realm as Scope. + +**Remaining nuance:** SaaS products calling Keycloak realms "tenants" need +explicit Organization + Tenant + Realm mapping in downstream adapters. + +### Customer Account as canonical concept + +**Status:** Open — leaning toward Organization + Customer role. + +ZITADEL and Keycloak model customer-like boundaries as Organization with tenant +semantics, not a separate account type. No corpus source defines Customer +Account as distinct from Organization actor + Customer relationship role + +Tenant scope. + +**Decision needed:** Whether billing/commercial account records warrant a +downstream-only model or a canonical Customer Account specialization. + +### Team modeling + +**Status:** Open. + +Schema.org and collaboration products use team for org units or project groups. +Corpus supports Team as Group or Organization Unit specialization depending on +whether the team has independent governance. + +**Decision needed:** Default mapping rule when source does not distinguish team +from department. + +### Legal Entity modeling + +**Status:** Open — both patterns viable. + +Schema.org treats Organization without mandatory legal status. Scenario S15 +requires separation of Organization, Legal Entity, and Tenant. Corpus supports +Legal Entity as specialization when evidenced, or as relationship to legal +system. + +**Decision needed:** Prefer specialization vs. relationship as default pattern. + +### Mandatory Synonymity Assertion fields + +**Status:** Open. + +ResearchSeed and `synonymity-assertions.md` propose a field set. Corpus sources +agree on scope, evidence, strength, and lifecycle but differ on which fields +are universal vs. relationship-type-specific. + +**Decision needed:** Minimum required fields for all assertions vs. sensitive +relationships (delegation, representation, synonymity). ## Synonymity Questions -- Which confidence vocabulary should be used for weak matches? -- What is the minimum evidence model for strong account links? -- How should revocation or expiry of a synonymity assertion affect downstream - caches? -- How should privacy-limited links be represented so accidental broadening is - visible during review? +### Confidence vocabulary + +**Status:** Open — candidate bands defined. + +Entity-resolution source (`deterministic-vs-probabilistic-matching.md`) and +synonymity model propose weak/medium/strong/authoritative. Probabilistic +literature uses continuous scores. + +**Decision needed:** Standardize bands only, or also allow numeric score with +band mapping. + +### Minimum evidence for strong links + +**Status:** Partially resolved. + +Corpus identifies authoritative deterministic keys per source family: + +- OIDC `iss` + `sub` after RP verification +- SAML persistent NameID with SP policy +- Operator-verified account linking +- VC cryptographic proof with valid status + +Weak-only: probabilistic scores, schema.org sameAs, shared email without +verification. + +**Remaining:** Whether SCIM `externalId` alone is medium or weak strength. + +### Revocation and cache effects + +**Status:** Open (downstream-heavy). + +SSF/RISC events (`shared-signals-caep-risc.md`) define issuer-side lifecycle +events. Canon should model assertion revocation; cache invalidation is +downstream. + +### Privacy-limited link representation + +**Status:** Partially resolved. + +GDPR and OIDC pairwise sources support privacy classification on assertions +and separated re-identification keys. S14 scenario checks pass with +Persona + Scoped Identifier + privacy-limited Synonymity Assertion. + +**Remaining:** Standard `privacy_classification` enum vs. policy reference. ## Corpus Questions -- Which source notes should be backfilled first: SCIM and LDAP for record - semantics, OIDC and SAML for subject semantics, or OpenFGA and Cedar for - authorization projections? -- How much product-specific detail belongs in source notes versus downstream - recommendations? -- What citation format should the repo use once source notes are populated? +### Backfill priority + +**Status:** Resolved. + +IDENTITY-WP-0003 completed backfill in priority order: provisioning/federation +(9 notes), authorization/social (8 notes), verifiable claims/entity-resolution +(6 notes). Terminology and model artifacts refreshed from corpus. + +### Product-specific detail placement + +**Status:** Resolved. + +Source notes capture product vocabulary and mapping implications. Implementation +patterns and adapter recommendations belong in `DownstreamRecommendations.md`. + +### Citation format + +**Status:** Resolved for this pass. + +Source notes use: + +- RFC/spec URL in References section +- Product documentation URL where applicable +- Source note filename as internal cross-reference + +No separate bibliography file added. + +## New Questions From Corpus Review + +### Cerbos derived roles vs. explicit relationships + +Cerbos encodes ownership as derived roles from resource attributes. Should +canon actively discourage attribute-encoded ownership without backing Ownership +Relationship? + +### ActivityPub cross-server actor linking + +Should multiple ActivityPub actors for one Natural Person require explicit +Synonymity Assertion, or remain unlinked by default? + +### Assurance dimension storage + +Should IAL/AAL/FAL be stored as orthogonal fields on Account bindings, or as +metadata on Synonymity Assertion / Trust Relationship only? + +### Kratos Identity unified vs. split + +Should Kratos Identity map to unified Identity Record or split Account + Profile +in canonical adapters? \ No newline at end of file diff --git a/canon/CanonicalGlossary.md b/canon/CanonicalGlossary.md index 1d0ae01..cff13c5 100644 --- a/canon/CanonicalGlossary.md +++ b/canon/CanonicalGlossary.md @@ -1,7 +1,8 @@ # Canonical Glossary -Status: draft. These definitions are initial candidate canon terms. They are -intended to be challenged by source-note backfill and scenario testing. +Status: draft. Updated after IDENTITY-WP-0003 corpus backfill and scenario +review. Definitions remain candidate canon terms until human review promotes +them. ## Actor @@ -126,8 +127,10 @@ but it is not automatically identical to any of them. An issuer, security, or administrative namespace used by an identity system. -Candidate status: treat Realm as a Scope specialization unless source analysis -shows it needs a separate canonical role. +After Keycloak and federation source review, Realm remains a **Scope +specialization** for hard identity/admin boundaries (separate user namespaces, +credentials, clients, IdPs). It is not interchangeable with Tenant or +Organization. ## Organization @@ -228,8 +231,17 @@ another for claims, identifiers, credentials, or decisions. A scoped, evidenced assertion that two or more identifiers, records, accounts, profiles, or actors refer to the same target for a stated purpose. -Synonymity assertions may be weak, strong, verified, inferred, revoked, -privacy-limited, or source-specific. +Recommended relation types: `same_as`, `probably_same_as`, `linked_to`, +`represents`, `controls`, `acts_for`. + +Recommended strength bands: weak, medium, strong, authoritative. + +Synonymity assertions may be verified, inferred, revoked, privacy-limited, or +source-specific. They do not require destructive merging of source records. + +Common sources: OIDC iss+sub account binding, SAML persistent NameID mapping, +entity-resolution matches, operator verification, VC cryptographic proof, +schema.org sameAs (weak by default). ## Evidence Source @@ -244,6 +256,37 @@ assertion. Examples: proposed, active, suspended, revoked, expired, archived, deleted, superseded. +Security event streams (SSF/CAEP/RISC) and VC status mechanisms are common +Evidence Sources that trigger lifecycle transitions. + +## Assurance Level + +Confidence metadata about identity proofing, authentication, or federation +derived from sources such as NIST SP 800-63-4. + +Dimensions: + +- Identity Assurance Level (IAL): confidence that a subscriber is the claimed person. +- Authenticator Assurance Level (AAL): confidence in authentication mechanism. +- Federation Assurance Level (FAL): confidence in federation assertion protection. + +Assurance levels attach to bindings, credentials, and federation relationships; +they do not replace authorization decisions. + +## Relationship Tuple + +An authorization projection encoding a subject-relation-object fact in engines +such as Zanzibar, OpenFGA, or Ory Keto. + +Relationship tuples are not canonical identity roots. They project from actors, +accounts, memberships, and delegations into authorization domains. + +## Pseudonymous Identifier + +An identifier designed to limit cross-scope correlation, aligned with privacy +patterns such as OIDC pairwise subjects, tenant-local subjects, and GDPR +pseudonymization with separately stored re-identification keys. + ## Non-Canonical Convenience Term: User `User` may be used in prose when quoting or mapping external systems, but it diff --git a/canon/DesignPrinciples.md b/canon/DesignPrinciples.md index a34257b..b1c66cc 100644 --- a/canon/DesignPrinciples.md +++ b/canon/DesignPrinciples.md @@ -1,8 +1,9 @@ # Design Principles -Status: draft. These principles make the proposal's modeling stance explicit. -They are constraints for canonical vocabulary and conceptual model work, not -implementation requirements for downstream systems. +Status: draft. Refined after IDENTITY-WP-0003 corpus backfill. These principles +make the proposal's modeling stance explicit. They are constraints for canonical +vocabulary and conceptual model work, not implementation requirements for +downstream systems. ## P1. Use Actor As The Participation Root @@ -66,7 +67,23 @@ the canon should identify the underlying concept before adopting the label. Every canonical concept should survive concrete scenarios: enterprise directories, vendor/customer tenancy, families, communities, social graphs, service accounts, delegated agents, weak matches, strong links, and -pseudonymous profiles. +pseudonymous profiles. After corpus backfill, all fifteen scenarios in +`scenarios/ScenarioTests.md` have explicit representation paths in +`model/ConceptualModel.md`. + +## P12. Distinguish Assurance Dimensions + +Identity proofing, authentication, and federation assurance are separable +dimensions (NIST IAL, AAL, FAL). Do not collapse them into a single "trust +level" on an account. Record assurance metadata on bindings, credentials, and +federation relationships where sources provide it. + +## P13. Prefer Non-Destructive Linking + +Entity resolution, federation account linking, and semantic web equivalence +patterns should produce Synonymity Assertions, not silent record merges. +Probabilistic matches default to weak strength with review lifecycle. Deterministic +and verified matches may be strong but remain scoped and revocable. ## P11. Keep Implementation Recommendations Downstream diff --git a/model/ConceptualModel.md b/model/ConceptualModel.md index a186c4c..5c78ada 100644 --- a/model/ConceptualModel.md +++ b/model/ConceptualModel.md @@ -1,15 +1,14 @@ # Conceptual Model -Status: draft. This is the first narrative model extracted from the research -proposal. It is intentionally implementation-neutral and should be refined by -source-note backfill and scenario testing. +Status: draft. Refined after IDENTITY-WP-0003 corpus backfill and scenario +representation review. Implementation-neutral. ## Core Claim -Identity-canon should model identity-related systems as scoped actors, -records, identifiers, claims, credentials, relationships, and projections. The -model should keep social, legal, operational, authentication, and authorization -meanings visible instead of collapsing them into `user`, `group`, or `tenant`. +Identity-canon models identity-related systems as scoped actors, records, +identifiers, claims, credentials, relationships, and projections. Social, legal, +operational, authentication, and authorization meanings stay visible instead of +collapsing into `user`, `group`, or `tenant`. ## Entity Families @@ -58,7 +57,7 @@ meanings visible instead of collapsing them into `user`, `group`, or `tenant`. ## Relationship Classes -Relationships should be explicit model elements when they affect meaning, +Relationships are explicit model elements when they affect meaning, authorization, privacy, or lifecycle. Core relationship classes: @@ -90,26 +89,121 @@ Recommended relationship fields: ## Identity Linking Model -Identity linking should not merge records by default. It should create -Synonymity Assertions. +Identity linking does not merge records by default. It creates Synonymity +Assertions with relation types (`same_as`, `probably_same_as`, `linked_to`, +`represents`), strength bands, scope, evidence, and lifecycle state. -Weak synonymity examples: +Weak synonymity: probabilistic entity-resolution matches, schema.org sameAs, +shared attributes without verification. -- imported records match on name and email hash; -- two profiles share a phone number but lack explicit verification; -- an entity-resolution job proposes a duplicate. +Strong synonymity: deterministic keys (OIDC iss+sub, persistent SAML NameID), +operator-verified links, VC cryptographic proof. -Strong synonymity examples: +Privacy-limited synonymity: pairwise OIDC sub, pseudonymous persona links, +GDPR pseudonymization with separated re-identification key. -- account holder completes explicit account-linking flow; -- issuer signs a claim binding an identifier to a subject; -- operator verifies a link against authoritative evidence. +## Scenario Representation Paths -Privacy-limited synonymity examples: +Each scenario in `scenarios/ScenarioTests.md` maps to canonical elements as +follows. -- pairwise subject identifier bound only for one relying party; -- pseudonymous community profile linked only inside a restricted scope; -- legal identity reference stored separately from a public persona. +### S01 — Single Person With One Local Account + +`Natural Person` → operates → `Account` (in `Scope`) → has `Identifier`(s) → +presents `Profile` → optional `Membership Relationship` to `Group` → authz +projects `Account` to `Authorization Principal`. + +### S02 — Person With Multiple Accounts Across Scopes + +`Natural Person` → operates → multiple `Account` (one primary `Scope` each) → +optional `Synonymity Assertion` (`linked_to` or `same_as`, scoped) between +accounts → independent `Lifecycle State` per account. + +### S03 — Enterprise With Sub-Organizations + +`Organization` actors → structural child/parent relationships → `Identity +Record`/`Account` per directory source (LDAP/SCIM) → `Membership Relationship` +to org units → `Legal Entity` as specialization or relationship when evidenced. + +### S04 — Vendor Tenant Serving Customer Tenants + +`Organization`(vendor) + `Organization`(customer) → `Vendor`/`Customer` +relationship roles → separate `Tenant` scopes → `Trust Relationship` for +federation → `Administration Relationship` for delegated support. + +### S05 — Customer Organization With Delegated Administrators + +`Organization` → owns `Tenant` scope → administrator `Account`(s) → +`Delegation Relationship` + `Administration Relationship` → authz projection +via Cedar Principal or OpenFGA admin tuple. + +### S06 — Family With Guardian And Dependent Accounts + +`Family or Household` collective actor → `Natural Person` (guardian, dependent) +→ `Representation Relationship` (guardian→dependent) → child `Account` with +privacy constraints → optional NIST IAL-capped proofing metadata. + +### S07 — Spontaneous Interest Group + +`Community` or `Group` collective actor → `Membership Relationship` (informal) +→ optional `Administration Relationship` (moderator) → no `Tenant` or `Legal +Entity` required. + +### S08 — Community With Members, Moderators, And Followers + +`Community` actor → `Membership Relationship` (members) → `Administration +Relationship` (moderators) → `Following Relationship` (followers) → `Profile` +may differ from `Account`. + +### S09 — Social Media Follower Graph + +`Actor`/`Persona` → `Profile` in social `Scope` → directed `Following +Relationship` edges → no implied `Membership` or authz tuple. + +### S10 — Bot Or Service Account Acting For An Organization + +`Artificial Agent` → `Service Account` → `Organization` actor → +`Representation` or `Delegation Relationship` → `Credential` → authz tuple +(e.g., `org#delegate@service_account`). + +### S11 — AI Agent Acting Under Delegated Authority + +`Artificial Agent` → `Account` or `Service Account` → `Delegation +Relationship` from `Natural Person` or `Organization` → `Evidence Source` for +actions → Cedar `Context.delegatedBy` or contextual OpenFGA tuple. + +### S12 — Weak Identity Match From Imported Data + +Source `Identity Record`(s) → `Synonymity Assertion` (`probably_same_as`, weak, +scoped) → `Evidence Source` (import job, match score) → `Lifecycle State` +`proposed` until reviewed. + +### S13 — Strong Account Link After Explicit Verification + +`Account`(s) or `Identifier`(s) → `Synonymity Assertion` (`same_as`, strong) → +`Evidence Source` (verification event, VC proof, re-authentication) → +revocation/supersession path via `Lifecycle State`. + +### S14 — Pseudonymous Profile Linked Only Within Restricted Scope + +`Persona`/`Profile` → `Scoped Identifier` → `Synonymity Assertion` +(privacy-limited, restricted `Scope`) → separated re-identification +`Evidence Source` per GDPR pseudonymization pattern. + +### S15 — Organization Represented By Legal Entity And Operational Tenants + +`Organization` actor → `Legal Entity` relationship or specialization → one or +more `Tenant` scopes → `Representation Relationship` for authorized persons or +agents. + +## Scenario Gaps + +No scenario requires glossary or principle changes that the current model +cannot satisfy. Remaining ambiguities are documented in `OpenQuestions.md`: + +- mandatory Synonymity Assertion field set; +- Realm vs. Tenant promotion for Keycloak-heavy mappings; +- Customer Account as separate concept vs. Organization + Customer role. ## Invariants @@ -117,20 +211,24 @@ Privacy-limited synonymity examples: - An Account belongs to exactly one primary operational Scope, but can have relationships to other scopes. - A Profile presents an Actor, Account, or Persona within a Scope. -- A Principal is a projection for authorization and should not replace Actor or +- A Principal is a projection for authorization and must not replace Actor or Account in the canon. -- A Tenant can be related to an Organization or Customer, but should not be - treated as identical to either. -- A Group can carry Membership relationships, but Role assignment and - relationship semantics must stay explicit. -- A Synonymity Assertion can link records without destroying source identity or +- A Tenant can be related to an Organization or Customer, but is not identical + to either. +- A Group carries Membership relationships; Role assignment and relationship + semantics stay explicit. +- A Synonymity Assertion links records without destroying source identity or evidence. - Lifecycle state applies to relationships and assertions, not only accounts. +- Authorization tuples (Zanzibar/OpenFGA) and Cedar principals are projections + from canonical actors, accounts, and relationships — not alternate identity + roots. +- OIDC Subject and SAML Principal are Authenticated Subject projections, not + Natural Persons. ## External Mapping Rule -When mapping an external system, first identify which canonical layer the -source term belongs to: +When mapping an external system, identify the canonical layer first: 1. Actor layer: who or what participates? 2. Record layer: what operational record exists? @@ -142,3 +240,20 @@ source term belongs to: Only after that mapping should source-specific labels such as `user`, `group`, `organization`, `realm`, `tenant`, `subject`, or `principal` be adopted in a downstream artifact. + +## Source Grounding + +This revision is grounded in the backfilled research corpus (23 source notes). +Key cross-cutting findings: + +- Provisioning sources (SCIM, LDAP) model records and group membership, not + actors directly. +- Federation sources (OIDC, SAML, NIST, SSF) define subject identifiers, + assurance, and lifecycle events. +- Authorization sources (Zanzibar, OpenFGA, Cedar, Cerbos) are projection + layers over opaque identifiers. +- Social sources (ActivityPub, FOAF, Schema.org, WebID) separate person, actor, + account, and social edges. +- VC/DID sources add portable claims and decentralized identifiers. +- Entity-resolution and GDPR sources define synonymity strength and privacy + constraints. \ No newline at end of file diff --git a/research/authentication-federation/nist-800-63-4.md b/research/authentication-federation/nist-800-63-4.md index 1d10e3f..579d9a8 100644 --- a/research/authentication-federation/nist-800-63-4.md +++ b/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 \ No newline at end of file diff --git a/research/authentication-federation/oidc-core-subject-identifiers.md b/research/authentication-federation/oidc-core-subject-identifiers.md index e142cf4..8e64bb1 100644 --- a/research/authentication-federation/oidc-core-subject-identifiers.md +++ b/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 \ No newline at end of file diff --git a/research/authentication-federation/saml-nameid-federation.md b/research/authentication-federation/saml-nameid-federation.md index aaa4437..e731e8a 100644 --- a/research/authentication-federation/saml-nameid-federation.md +++ b/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 \ No newline at end of file diff --git a/research/authentication-federation/shared-signals-caep-risc.md b/research/authentication-federation/shared-signals-caep-risc.md index cc48311..6c177fc 100644 --- a/research/authentication-federation/shared-signals-caep-risc.md +++ b/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 \ No newline at end of file diff --git a/research/authorization-relationships/cedar-principal-action-resource-context.md b/research/authorization-relationships/cedar-principal-action-resource-context.md index 974af9e..5b3584c 100644 --- a/research/authorization-relationships/cedar-principal-action-resource-context.md +++ b/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/ \ No newline at end of file diff --git a/research/authorization-relationships/cerbos-abac-derived-roles.md b/research/authorization-relationships/cerbos-abac-derived-roles.md index 3bdb873..a577419 100644 --- a/research/authorization-relationships/cerbos-abac-derived-roles.md +++ b/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 \ No newline at end of file diff --git a/research/authorization-relationships/openfga-modeling.md b/research/authorization-relationships/openfga-modeling.md index 1db6682..f572249 100644 --- a/research/authorization-relationships/openfga-modeling.md +++ b/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 \ No newline at end of file diff --git a/research/authorization-relationships/zanzibar-rebac.md b/research/authorization-relationships/zanzibar-rebac.md index a32a1e6..9d52912 100644 --- a/research/authorization-relationships/zanzibar-rebac.md +++ b/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 \ No newline at end of file diff --git a/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md b/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md index e861ff7..386a915 100644 --- a/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md +++ b/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 \ No newline at end of file diff --git a/research/entity-resolution-privacy/gdpr-pseudonymization.md b/research/entity-resolution-privacy/gdpr-pseudonymization.md index 00e2bc4..2fe20f9 100644 --- a/research/entity-resolution-privacy/gdpr-pseudonymization.md +++ b/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 \ No newline at end of file diff --git a/research/entity-resolution-privacy/synonymity-assertions.md b/research/entity-resolution-privacy/synonymity-assertions.md index 602390c..5dc38d8 100644 --- a/research/entity-resolution-privacy/synonymity-assertions.md +++ b/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/ \ No newline at end of file diff --git a/research/identity-provisioning/keycloak-organizations.md b/research/identity-provisioning/keycloak-organizations.md index 81d40df..5925c23 100644 --- a/research/identity-provisioning/keycloak-organizations.md +++ b/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 \ No newline at end of file diff --git a/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md b/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md index 721e702..a946925 100644 --- a/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md +++ b/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 \ No newline at end of file diff --git a/research/identity-provisioning/ory-kratos-keto.md b/research/identity-provisioning/ory-kratos-keto.md index 3f5ff42..9e53b97 100644 --- a/research/identity-provisioning/ory-kratos-keto.md +++ b/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 \ No newline at end of file diff --git a/research/identity-provisioning/scim-rfc7643-rfc7644.md b/research/identity-provisioning/scim-rfc7643-rfc7644.md index e9aea0f..b3ba782 100644 --- a/research/identity-provisioning/scim-rfc7643-rfc7644.md +++ b/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/ \ No newline at end of file diff --git a/research/identity-provisioning/zitadel-organizations-projects.md b/research/identity-provisioning/zitadel-organizations-projects.md index 5744377..e8785b3 100644 --- a/research/identity-provisioning/zitadel-organizations-projects.md +++ b/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 \ No newline at end of file diff --git a/research/social-community-graphs/activitypub-actors-followers.md b/research/social-community-graphs/activitypub-actors-followers.md index ee23ca6..9a157ba 100644 --- a/research/social-community-graphs/activitypub-actors-followers.md +++ b/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 \ No newline at end of file diff --git a/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md b/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md index d008d9c..eaad8bc 100644 --- a/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md +++ b/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/ \ No newline at end of file diff --git a/research/social-community-graphs/schema-org-person-organization-membership.md b/research/social-community-graphs/schema-org-person-organization-membership.md index 63c2f3b..1c688eb 100644 --- a/research/social-community-graphs/schema-org-person-organization-membership.md +++ b/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 \ No newline at end of file diff --git a/research/social-community-graphs/webid-solid-profile.md b/research/social-community-graphs/webid-solid-profile.md index 61f0f6f..101413a 100644 --- a/research/social-community-graphs/webid-solid-profile.md +++ b/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 \ No newline at end of file diff --git a/research/verifiable-claims/did-core.md b/research/verifiable-claims/did-core.md index c650d70..33dc868 100644 --- a/research/verifiable-claims/did-core.md +++ b/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/ \ No newline at end of file diff --git a/research/verifiable-claims/openid4vc.md b/research/verifiable-claims/openid4vc.md index 93a4d40..1df947a 100644 --- a/research/verifiable-claims/openid4vc.md +++ b/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 \ No newline at end of file diff --git a/research/verifiable-claims/vc-data-model-2.md b/research/verifiable-claims/vc-data-model-2.md index 051bd35..4d7d6b1 100644 --- a/research/verifiable-claims/vc-data-model-2.md +++ b/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/ \ No newline at end of file diff --git a/scenarios/ScenarioTests.md b/scenarios/ScenarioTests.md index 00fd1a8..b8983c1 100644 --- a/scenarios/ScenarioTests.md +++ b/scenarios/ScenarioTests.md @@ -184,6 +184,10 @@ Checks: ## Current Result -The initial model can represent all fifteen scenarios at a narrative level. -The next research pass should backfill concrete mappings from source notes and -then revise the glossary where scenario checks reveal ambiguity. +After IDENTITY-WP-0003 corpus backfill, `model/ConceptualModel.md` documents +an explicit representation path for each scenario (S01–S15). All fifteen +scenarios remain representable without glossary or principle changes. + +Remaining ambiguities are tracked in `OpenQuestions.md` (Realm promotion, +Customer Account concept, mandatory Synonymity Assertion fields). These affect +refinement, not scenario satisfiability. diff --git a/terminology/TerminologyConflictMap.md b/terminology/TerminologyConflictMap.md index a23c70e..ae6e3c8 100644 --- a/terminology/TerminologyConflictMap.md +++ b/terminology/TerminologyConflictMap.md @@ -1,152 +1,210 @@ # Terminology Conflict Map -Status: draft. This map records high-risk terms whose meanings differ across -source families. It should be revised after each source-note backfill. +Status: draft. Revised after IDENTITY-WP-0003 corpus backfill. Each conflict +includes source-backed examples from populated research notes. ## Conflict: User Problem: `user` can mean a person, account, login credential holder, application profile, authorization subject, or product-facing actor. -Canonical stance: do not use `user` as a root concept. Require the writer to -choose among Natural Person, Account, Actor, Authenticated Subject, Principal, -Profile, or Persona. +Source evidence: + +- SCIM User = provisionable Identity Record (`scim-rfc7643-rfc7644.md`) +- Keycloak/ZITADEL User = Account with credentials (`keycloak-organizations.md`, + `zitadel-organizations-projects.md`) +- OpenFGA `user:` tuple prefix = Authorization Principal id (`openfga-modeling.md`) +- OIDC End-User = implied Natural Person, not modeled (`oidc-core-subject-identifiers.md`) + +Canonical stance: do not use `user` as a root concept. Current mapping rule: -- If the system stores login state, map to Account. -- If the system renders a public or local display surface, map to Profile. -- If the system evaluates access, map to Principal or Authenticated Subject. -- If the text means a human being, map to Natural Person. +- Provisioning record (SCIM/LDAP) → Identity Record +- Login-enabled product record → Account +- Public/local display → Profile +- Access evaluation → Principal or Authenticated Subject +- Human being → Natural Person ## Conflict: Identity Problem: `identity` can mean selfhood, a directory record, an issuer-bound subject, a set of claims, a DID, a credential, a profile, or an account. +Source evidence: + +- Kratos Identity = traits + credentials (`ory-kratos-keto.md`) +- OIDC developers conflate `sub` with "identity" (`oidc-core-subject-identifiers.md`) +- DID is identifier, not identity record (`did-core.md`) +- VC credentialSubject = claims about subject (`vc-data-model-2.md`) + Canonical stance: avoid bare `identity`. Prefer Identity Record, Identifier, Claim, Credential, Profile, Persona, or Synonymity Assertion. -Current mapping rule: - -- A persistent record about an actor maps to Identity Record. -- A value used to refer maps to Identifier. -- A statement made by an issuer maps to Claim. -- Proof material maps to Credential. - ## Conflict: Account Problem: account can mean login account, customer billing account, social -account, service account, or account profile. +media handle, service account, or FOAF online presence. -Canonical stance: Account is an operational access record in a scope. Billing -or customer accounts need explicit relationship and commercial-role modeling. +Source evidence: -Current mapping rule: +- FOAF OnlineAccount is service presence, explicitly not Person (`foaf-agent-person-group-onlineaccount.md`) +- LDAP posixAccount is attribute bundle on person entry (`ldap-rfc4519-inetorgperson-rfc2798.md`) +- ActivityPub `acct:` URI suggests account but actor is richer (`activitypub-actors-followers.md`) +- ZITADEL machine user = Service Account (`zitadel-organizations-projects.md`) -- Login-capable operational record maps to Account. -- Non-human login-capable record maps to Service Account. -- Commercial customer record maps to Customer relationship or Customer Account - only if a later source analysis justifies the separate concept. +Canonical stance: Account is operational access record in a scope. ## Conflict: Subject, Principal, Actor -Problem: protocols, authorization engines, and application models use these -terms differently. OIDC and SAML focus on subject identifiers; Cedar and IAM -often decide over principals; social and conceptual models talk about actors. +Problem: protocols, authorization engines, and social models overload these terms. + +Source evidence: + +- OIDC Subject = issuer-scoped identifier (`oidc-core-subject-identifiers.md`) +- SAML Principal = authenticated subject in assertion (`saml-nameid-federation.md`) +- Cedar Principal = typed entity in authorization request (`cedar-principal-action-resource-context.md`) +- Zanzibar/OpenFGA Subject = opaque authz participant (`zanzibar-rebac.md`) +- ActivityPub Actor = server-hosted social entity (`activitypub-actors-followers.md`) +- FOAF Agent = actionable entity, includes Person (`foaf-agent-person-group-onlineaccount.md`) +- GDPR Data Subject = natural person (`gdpr-pseudonymization.md`) Canonical stance: -- Actor is the conceptual participant. -- Authenticated Subject is the issuer/protocol view after identification. -- Authorization Principal is the decision-engine projection. - -The same natural person or account may appear as all three in different -contexts, but the concepts should not be merged. +- Actor = conceptual participant +- Authenticated Subject = issuer/protocol view +- Authorization Principal = decision-engine projection ## Conflict: Tenant, Realm, Organization, Customer -Problem: multi-tenant products often use tenant, organization, realm, customer, -workspace, project, and account as partial synonyms. Some are isolation -boundaries, some are legal or commercial actors, and some are administrative -containers. +Problem: multi-tenant products collapse isolation boundaries and commercial actors. + +Source evidence: + +- Keycloak Realm = hard namespace; Organization = B2B overlay (`keycloak-organizations.md`) +- ZITADEL Organization = customer boundary + org actor (`zitadel-organizations-projects.md`) +- SCIM has no tenant; org is string attribute (`scim-rfc7643-rfc7644.md`) +- Schema.org Organization = collective actor (`schema-org-person-organization-membership.md`) Canonical stance: -- Tenant is an administrative or isolation scope. -- Realm is an issuer or administrative namespace unless source analysis proves - stronger tenant semantics. -- Organization is a collective actor or organizational structure. -- Customer is a commercial relationship role. +- Tenant = administrative/isolation scope +- Realm = issuer/admin namespace (Scope specialization) +- Organization = collective actor +- Customer = commercial relationship role -Model the relationships among these concepts instead of choosing one term to -stand for all of them. +Model relationships among them; do not synonymize. ## Conflict: Group, Role, Team, Community -Problem: IAM systems often use groups for role assignment, collaboration tools -use teams for work coordination, and social platforms use groups or communities -for participation. +Problem: IAM groups, collaboration teams, social communities, and authz member +relations use overlapping labels. + +Source evidence: + +- LDAP/SCIM Group = entry with member references (`ldap`, `scim` notes) +- ActivityPub Group actor = collective social actor (`activitypub-actors-followers.md`) +- Zanzibar `group#member@user` = authz tuple (`zanzibar-rebac.md`) +- Cerbos derived role from group attribute (`cerbos-abac-derived-roles.md`) +- Schema.org Organization subtypes include SportsTeam (`schema-org` note) Canonical stance: -- Group is a named collection or collective actor with membership. -- Role is a capability bundle or relationship label. -- Team is a domain-specific group or organization unit. -- Community is a participation-oriented collective actor. - -Avoid modeling all four as generic `group`. +- Group = named collection with membership +- Role = capability bundle or relationship label +- Team = collaboration group or org unit +- Community = participation-oriented collective actor ## Conflict: Member, Follower, Affiliate -Problem: membership, following, affiliation, employment, subscription, and -moderation relationships are often hidden behind `member`. +Problem: membership, following, affiliation, and authz member relations hide +distinct semantics behind `member`. -Canonical stance: relationship type matters. Represent each relationship with -source, target, scope, role or relation kind, evidence, lifecycle state, and -authorization implications if any. +Source evidence: + +- ActivityPub Follow ≠ membership (`activitypub-actors-followers.md`) +- Schema.org affiliation looser than memberOf (`schema-org-person-organization-membership.md`) +- OpenFGA organization#member = authz projection (`openfga-modeling.md`) +- FOAF member = group membership; knows = acquaintance (`foaf` note) + +Canonical stance: use typed relationships with scope and evidence. ## Conflict: Profile And Persona -Problem: profiles are sometimes account records, public pages, social -identities, or collections of claims. Personas are sometimes aliases, -pseudonyms, or UX-specific presentations. +Problem: profiles are account records, RDF documents, public pages, or VC subjects. + +Source evidence: + +- WebID profile document = RDF at URI (`webid-solid-profile.md`) +- Kratos traits often called profile informally (`ory-kratos-keto.md`) +- ActivityPub actor profile = public actor representation +- Persona for pairwise/pseudonymous scoped presentation (OIDC, GDPR notes) Canonical stance: -- Profile is a presentation or attribute surface in a scope. -- Persona is a deliberate contextual presentation of an actor, often separate - from other presentations for privacy or role clarity. +- Profile = presentation surface in scope +- Persona = deliberate contextual presentation with privacy boundaries ## Conflict: Identifier, Credential, Claim -Problem: identifiers, credentials, and claims are often conflated because all -can appear in tokens, profiles, or identity documents. +Problem: tokens and documents bundle all three. -Canonical stance: +Source evidence: -- Identifier refers. -- Credential proves or supports. -- Claim states. +- OIDC ID Token contains sub (identifier) and claims (`oidc-core-subject-identifiers.md`) +- VC = signed claims with proof (`vc-data-model-2.md`) +- DID verification method = cryptographic credential (`did-core.md`) +- SAML AttributeStatement = claims; NameID = identifier (`saml-nameid-federation.md`) -A token may contain all three, but the conceptual model should keep them apart. +Canonical stance: identifier refers; credential proves; claim states. ## Conflict: Synonymity, Linking, Matching, Merge -Problem: identity systems often collapse weak matches, verified account links, -same-as claims, and destructive record merges into a single identity-linking -feature. +Problem: systems collapse probabilistic matches, verified links, and destructive +merges into one feature. -Canonical stance: synonymity is an assertion. It has source, target, scope, -confidence, evidence, method, lifecycle state, and privacy constraints. It does -not require destructive merging. +Source evidence: + +- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`) +- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes) +- Schema.org sameAs = weak web equivalence (`schema-org` note) +- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`) +- MDM golden record merge = downstream anti-pattern (`deterministic` note) + +Canonical stance: synonymity is scoped, evidenced, revocable assertion. + +## Conflict: Credential (Auth) vs. Verifiable Credential + +Problem: "credential" means password, OIDC token, or W3C VC. + +Source evidence: + +- NIST authenticator/credential (`nist-800-63-4.md`) +- VC Data Model verifiable credential (`vc-data-model-2.md`) +- OpenID4VC bridges OAuth credential terminology with VCs (`openid4vc.md`) + +Canonical stance: use Credential with context. VC maps to Credential containing +Claims; login secrets map to Credential (authentication factor). + +## Conflict: Issuer + +Problem: issuer means OIDC OP, VC issuer, SAML IdP, or CSP. + +Source evidence: + +- OIDC iss claim defines subject namespace (`oidc-core-subject-identifiers.md`) +- VC issuer signs credential (`vc-data-model-2.md`) +- NIST CSP performs proofing (`nist-800-63-4.md`) + +Canonical stance: Issuer = Scope authority + Trust Relationship; specify protocol +role when mapping. ## Review Queue -- Validate each conflict against populated source notes. -- Add concrete examples and counterexamples once source summaries include - citations. -- Decide whether Customer Account deserves a canonical concept or stays a - downstream commercial model. -- Decide whether Realm should remain a Scope specialization or become a - separate canonical concept. +- [ ] Decide Customer Account canonical concept — ZITADEL org-as-customer suggests + Organization + Tenant link, not separate Customer Account entity. +- [ ] Decide Realm specialization — Keycloak evidence supports Realm as Scope + specialization; promote in glossary if scenario review confirms. +- [ ] Split authz `member` relation from social Membership in downstream adapters. +- [ ] Classify schema.org sameAs default strength — corpus says weak only. +- [ ] Standardize assurance dimensions — NIST IAL/AAL/FAL as orthogonal metadata. \ No newline at end of file diff --git a/terminology/TerminologyInventory.md b/terminology/TerminologyInventory.md index ed7152f..af2c34c 100644 --- a/terminology/TerminologyInventory.md +++ b/terminology/TerminologyInventory.md @@ -1,9 +1,8 @@ # Terminology Inventory -Status: draft. This inventory is seeded from `ResearchProposal.md`, -`INTENT.md`, and the current research corpus index. Mappings are candidate -canonical mappings until the individual source notes have been backfilled with -real source summaries. +Status: draft. Updated after IDENTITY-WP-0003 corpus backfill. Mappings remain +candidate until reviewed against `canon/CanonicalGlossary.md` and scenario +tests. ## Use @@ -15,58 +14,103 @@ has incompatible meanings across source families. | Term | Candidate canonical concept | Source families | Notes | | --- | --- | --- | --- | -| actor | Actor | authorization, social graphs, proposal | Participation root for anything that can act or be acted for. | -| natural person | Natural Person | identity assurance, social graphs | Human being; never identical to an account or profile. | -| user | Convenience label only | SCIM, products, applications | Overloaded; map to Account, Actor, Subject, or Profile by context. | -| account | Account | SCIM, LDAP, IAM products | Operational record that enables access in a scope. | -| identity | Identity Record or Identity Claim | IAM, federation, DID, VC | Avoid as root noun; clarify whether record, claim, identifier, or social identity is meant. | -| identifier | Identifier | OIDC, SAML, DID, directories | A value or reference used to distinguish something in a scope. | -| credential | Credential | authentication, VC, DID | Evidence or secret material used to prove control, entitlement, or claim. | -| subject | Authenticated Subject | OIDC, SAML, authorization | Security-protocol view of an actor/account after identification by an issuer. | -| principal | Authorization Principal | Cedar, IAM, authorization | Entity considered by an authorization decision. | -| profile | Profile | social graphs, IAM, applications | Presentation or attribute surface for an actor/account in a scope. | -| persona | Persona | social/community systems | Deliberate contextual presentation of an actor, often with limited linkage. | -| agent | Artificial Agent | IAM, agentic systems | Non-human actor, including bot, service account, or AI agent. | -| bot | Artificial Agent | applications, social graphs | Automated actor; may act through an account and under delegation. | -| service account | Service Account | IAM, operations | Account intended for software or workload access rather than human login. | -| organization | Organization | SCIM, LDAP, Keycloak, ZITADEL | Collective actor or structure; do not collapse with tenant, legal entity, or customer. | -| legal entity | Legal Entity | business, compliance | Organization recognized under a legal system. | -| customer | Customer | SaaS, vendor/customer models | Commercial relationship role, not automatically a tenant or organization. | -| vendor | Vendor | SaaS, multi-vendor systems | Provider role in a commercial or operational relationship. | -| tenant | Tenant | SaaS, IAM products | Administrative or isolation scope; may be owned by or assigned to an organization. | -| realm | Realm | Keycloak, federation | Issuer or administrative namespace; candidate mapping is Scope or Tenant depending on use. | -| scope | Scope | OIDC, authorization, proposal | Boundary in which identifiers, policies, relationships, or meanings hold. | -| namespace | Scope | directories, DID, products | Naming boundary; treat as a kind of scope unless stronger semantics exist. | -| community | Community | social graphs, platforms | Collective actor defined by social participation rather than legal or customer status. | -| family | Family or Household | family account models | Relationship network with guardian/dependent semantics and privacy sensitivity. | -| household | Family or Household | family account models | Co-residence or account-management unit; may not equal legal family. | -| group | Group | LDAP, SCIM, social graphs, authz | Container or collective label; must not absorb relationship semantics. | -| team | Group or Organization Unit | SaaS, collaboration systems | Usually a collaboration group; sometimes an org sub-unit. | -| role | Role | RBAC, IAM products | Named capability set or relationship label; keep separate from group membership. | -| member | Membership Relationship | SCIM, groups, communities | Relationship from actor to collective actor or scope. | -| affiliation | Affiliation Relationship | enterprise, social | Looser association than membership; may be external or evidenced. | -| follower | Following Relationship | ActivityPub, social graphs | Directed social relationship, not a membership or authorization grant by default. | -| owner | Ownership Relationship | SaaS, authz | Control or responsibility relationship; needs scope and target. | -| administrator | Administration Relationship | IAM, SaaS | Delegated management authority in a scope. | -| delegation | Delegation Relationship | IAM, authz, agentic systems | Actor grants another actor authority to act in a bounded way. | -| representation | Representation Relationship | legal, org, agent systems | Actor acts on behalf of another actor or organization. | -| trust | Trust Relationship | federation, DID, authz | Reliance relationship; must record source, scope, and purpose. | -| claim | Claim | VC, OIDC, DID | Statement made by an issuer about a subject, actor, or relationship. | -| evidence | Evidence Source | entity resolution, assurance | Material supporting a claim or synonymity assertion. | -| assurance | Assurance Level | NIST, federation | Confidence about identity proofing, authentication, or binding. | -| identifier binding | Identifier Binding | federation, entity resolution | Assertion that an identifier refers to a target within a scope. | -| synonymity | Synonymity Assertion | entity resolution, proposal | Assertion that two records or identifiers refer to the same target under stated conditions. | -| weak match | Weak Synonymity Assertion | entity resolution | Probabilistic or low-confidence link; never a destructive merge. | -| strong link | Strong Synonymity Assertion | account linking, identity proofing | Verified or authoritative link; still scoped and evidenced. | -| pseudonym | Pseudonymous Identifier | privacy, OIDC, DID | Identifier designed to limit cross-scope correlation. | -| pairwise subject | Scoped Identifier | OIDC | Subject identifier scoped to relying party or sector; map to Identifier plus Scope. | -| relationship tuple | Relationship Assertion | Zanzibar, OpenFGA | Authorization-oriented representation of actor-object-relation facts. | -| policy | Authorization Projection | Cedar, IAM, authz | Rule artifact; not part of the canonical identity object model except as mapping. | -| lifecycle state | Lifecycle State | SCIM, IAM, directories | Activation, suspension, deletion, revocation, or archival state of a record or relationship. | +| actor | Actor | ActivityPub, FOAF, Cedar, proposal | Participation root. ActivityPub actor is server-hosted; FOAF Agent includes persons. | +| natural person | Natural Person | FOAF, Schema.org, NIST, GDPR | Human being; FOAF Person and Schema.org Person align strongly. | +| user | Convenience label only | SCIM, LDAP, Keycloak, ZITADEL, apps | Overloaded. Map by context: SCIM/LDAP User → Identity Record; Keycloak/ZITADEL User → Account. | +| account | Account | SCIM, LDAP posixAccount, FOAF OnlineAccount, Keycloak | Operational access record in a scope. FOAF separates account from person explicitly. | +| identity | Identity Record or Claim | Kratos, OIDC, DID, VC, apps | Kratos Identity = traits + credentials. Avoid bare `identity` as root noun. | +| identifier | Identifier | OIDC sub, SAML NameID, LDAP DN, DID, WebID | Value referring within or across scopes. See Scoped Identifier when correlation is limited. | +| scoped identifier | Scoped Identifier | OIDC pairwise, SAML transient, pseudonyms | Meaning limited to RP, sector, tenant, or session. | +| credential | Credential | NIST, Kratos, OIDC token, VC, DID keys | Proof material. Distinguish VC (claim container) from password/WebAuthn. | +| subject | Authenticated Subject | OIDC, SAML, SSF events | Protocol/security view after issuer identification. Not Actor or Principal. | +| principal | Authorization Principal | Cedar, Cerbos, Zanzibar, OpenFGA | Decision-engine participant. OpenFGA `user:` prefix is not a human user. | +| end-user | Natural Person (inferred) | OIDC | OIDC names the human implicitly; does not model as entity. | +| profile | Profile | FOAF, WebID/Solid, SCIM attrs, ActivityPub | Presentation or attribute surface. Solid profile is user-controlled data. | +| persona | Persona | proposal, privacy patterns | Contextual presentation; pairwise/pseudonymous profiles map here. | +| agent | Actor or Artificial Agent | FOAF, ActivityPub, WebID | FOAF Agent includes humans; ActivityPub Service = Artificial Agent. | +| bot | Artificial Agent | ActivityPub Service, apps | Automated actor; may use Service Account. | +| service account | Service Account | Keycloak, ZITADEL machine user, Kratos | Non-human login or API identity. ZITADEL machine user, Kratos service patterns. | +| machine user | Service Account | ZITADEL | Product term for non-human org identity. | +| organization | Organization | Schema.org, Keycloak Orgs, ZITADEL, SCIM ext | Collective actor. SCIM `organization` attribute is not an Organization actor. | +| legal entity | Legal Entity | business, compliance | Organization recognized under law; separate from tenant. | +| customer | Customer | SaaS, vendor models | Commercial relationship role. ZITADEL org often plays customer tenant role. | +| vendor | Vendor | SaaS, multi-vendor | Provider role in commercial relationship. | +| tenant | Tenant | ZITADEL org, SaaS, Keycloak (informal) | Administrative/isolation scope. Keycloak realm sometimes called tenant. | +| realm | Realm | Keycloak | Hard identity/admin namespace. Candidate Scope specialization. | +| scope | Scope | OIDC, Cerbos, OpenFGA store, proposal | Boundary for meaning, policy, or correlation. | +| namespace | Scope | LDAP dc, Keto/OpenFGA, DID method | Naming or authorization partition. | +| instance | Scope | ZITADEL | Deployment-level boundary above organizations. | +| project | Application Scope | ZITADEL | Application/product container within org. | +| community | Community | ActivityPub Group, proposal | Participation-oriented collective. ActivityPub Group may be Community or Group. | +| family | Family or Household | proposal, GDPR-sensitive | Guardian/dependent semantics; privacy-sensitive. | +| household | Family or Household | family accounts | Co-residence unit; may differ from legal family. | +| group | Group | LDAP, SCIM, FOAF, ActivityPub, Cedar | Named collection. LDAP/SCIM group ≠ social community without context. | +| team | Group or Organization Unit | Schema.org, collaboration | Collaboration unit; may be org sub-unit. | +| role | Role | Keycloak, ZITADEL, Cedar, Cerbos, Schema.org OrganizationRole | Capability bundle or relationship label. Cerbos derived role may hide Ownership. | +| grant | Role assignment | ZITADEL | Project role assignment; map to Delegation-like relationship. | +| member | Membership Relationship | SCIM, LDAP, FOAF, Schema.org, Zanzibar | Relationship edge, not a noun for the participant. | +| affiliation | Affiliation Relationship | Schema.org, FOAF knows | Looser than membership. FOAF knows is weak social affiliation. | +| follower | Following Relationship | ActivityPub | Directed social subscription; not membership or authz. | +| follow | Following Relationship | ActivityPub | Activity establishing follower edge. | +| owner | Ownership Relationship | Zanzibar, Cerbos derived | Control/responsibility. Cerbos may encode as attribute not relationship. | +| administrator | Administration Relationship | IAM, ZITADEL grants | Delegated management in scope. | +| delegation | Delegation Relationship | Cedar context, agents | Bounded authority grant. Cedar context may carry delegatedBy. | +| representation | Representation Relationship | SCIM manager, DID controller | Acting on behalf of another. DID controller may differ from subject. | +| trust | Trust Relationship | federation, VC, DID | Reliance on issuer/verifier; federation metadata trust. | +| claim | Claim | OIDC, SAML attributes, VC | Statement by issuer. SAML AttributeStatement → Claim. | +| evidence | Evidence Source | NIST proofing, entity resolution, SSF | Supports claims and synonymity. SSF SET = event Evidence Source. | +| assurance | Assurance Level | NIST IAL/AAL/FAL | Orthogonal identity, authentication, federation confidence. | +| identifier binding | Identifier Binding | OIDC iss+sub, WebID-OIDC, SAML | Assertion that identifier refers to target in scope. | +| synonymity | Synonymity Assertion | entity resolution, OIDC linking, schema.org sameAs | Scoped evidenced equivalence. sameAs is weak by default. | +| weak match | Weak Synonymity Assertion | probabilistic matching | Probabilistic link; never destructive merge. | +| strong link | Strong Synonymity Assertion | deterministic match, verified linking | Authoritative or verified; still scoped. | +| same_as | Synonymity Assertion (strong) | synonymity model | High-confidence equivalence relation type. | +| probably_same_as | Synonymity Assertion (weak) | probabilistic matching | Probabilistic equivalence relation type. | +| linked_to | Synonymity Assertion (operational) | account linking | Convenience link without semantic sameness claim. | +| pseudonym | Pseudonymous Identifier | GDPR, OIDC pairwise | Limits cross-scope correlation. | +| pairwise subject | Scoped Identifier | OIDC | RP-specific sub preventing global correlation. | +| relationship tuple | Relationship Tuple | Zanzibar, OpenFGA, Keto | Authz projection: subject#relation@object. | +| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. | +| lifecycle state | Lifecycle State | SCIM active, SSF/RISC events, VC status | Applies to records, credentials, relationships, assertions. | +| subscriber | Account / Identity Record | NIST | Enrolled party at CSP; not synonymous with Natural Person until IAL binding. | +| issuer | Scope + Trust Relationship | OIDC iss, VC issuer, SAML IdP | Namespace authority for identifiers and claims. | +| relying party | Scope | OIDC RP, SAML SP, NIST | Consumer of assertions; RP-local account binding. | +| nameid | Identifier | SAML | Format attribute determines persistence and privacy semantics. | +| distinguished name | Identifier | LDAP | Compound locator in directory namespace. | +| externalid | Identifier | SCIM | Client-supplied cross-system correlation key. | +| traits | Profile attributes | Kratos | Schema-validated identity attributes. | +| verification method | Credential | DID Core | Cryptographic key in DID document. | +| verifiable credential | Credential + Claim | VC Data Model | Signed claim set; distinct from login credential. | +| holder | Actor (custody role) | VC, OpenID4VC | Party possessing VC; may differ from subject. | +| verifier | Scope (evaluation role) | VC, OpenID4VC | Validates presentations. | +| did | Identifier | DID Core | Decentralized identifier with method-specific resolution. | +| webid | Identifier | WebID/Solid | HTTP URI identifying agent with dereferenceable profile. | +| data subject | Natural Person | GDPR | Identifiable natural person for privacy regulation. | +| pseudonymization | Processing pattern | GDPR | Technique; maps to Scoped Identifier + separated re-id key. | +| controller | Organization (legal role) | GDPR | Downstream legal role; not canonical identity root. | +| tuple (authz) | Relationship Tuple | Zanzibar | Authorization fact, not social relationship. | +| userset | Authorization Principal (indirect) | Zanzibar, OpenFGA | Subject referenced via relation chain. | +| derived role | Role (computed) | Cerbos | Role from attributes; should trace to Relationship when possible. | +| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. | +| sameas | Weak Synonymity Assertion | Schema.org | Informal web equivalence; not strong link without evidence. | +| organizationrole | Role + Membership | Schema.org | Temporal role with start/end dates. | +| assurance level change | Assurance Level update | SSF/CAEP | Event affecting IAL/AAL/FAL metadata. | -## Backfill Needs +## Source Note Citations -- Add source-specific definitions from each file in `research/*/*.md`. -- Split terms that hide multiple meanings after source review. -- Add citation pointers once source notes contain stable references. -- Move mature canonical definitions to `canon/CanonicalGlossary.md`. +Terms above are grounded in backfilled notes under: + +- `research/identity-provisioning/` (5 notes) +- `research/authentication-federation/` (4 notes) +- `research/authorization-relationships/` (4 notes) +- `research/social-community-graphs/` (4 notes) +- `research/verifiable-claims/` (3 notes) +- `research/entity-resolution-privacy/` (3 notes) + +## Remaining Backfill Needs + +- Split `group` into authorization group vs. social collective where sources + disagree (OpenFGA member vs. ActivityPub follower). +- Add product-version qualifiers when Keycloak/ZITADEL models evolve. +- Promote stable mappings to `canon/CanonicalGlossary.md` after scenario + review. \ No newline at end of file diff --git a/workplans/IDENTITY-WP-0003-corpus-backfill-model-refinement.md b/workplans/IDENTITY-WP-0003-corpus-backfill-model-refinement.md index 76bfcd5..fa2f468 100644 --- a/workplans/IDENTITY-WP-0003-corpus-backfill-model-refinement.md +++ b/workplans/IDENTITY-WP-0003-corpus-backfill-model-refinement.md @@ -4,11 +4,11 @@ type: workplan title: "Research corpus backfill and model refinement" domain: canon repo: identity-canon -status: ready +status: finished owner: codex topic_slug: canon created: "2026-06-19" -updated: "2026-06-19" +updated: "2026-06-21" state_hub_workstream_id: "af85e0a3-ccb8-4cfd-8859-d0794769e3e2" --- @@ -28,7 +28,7 @@ sources. ```task id: IDENTITY-WP-0003-T01 -status: todo +status: done priority: high state_hub_task_id: "fb88b28d-da4d-4f78-90d7-30e1ef49d6b6" ``` @@ -43,7 +43,7 @@ canonical mappings, and open questions. Use the structure defined in ```task id: IDENTITY-WP-0003-T02 -status: todo +status: done priority: high state_hub_task_id: "bc684b78-6af4-4988-927c-67520d81bdb1" ``` @@ -57,7 +57,7 @@ collapsing them into a single overloaded term. ```task id: IDENTITY-WP-0003-T03 -status: todo +status: done priority: medium state_hub_task_id: "d73ac6a7-2744-40b2-984c-4c86ef7493cf" ``` @@ -71,7 +71,7 @@ relationship modeling. ```task id: IDENTITY-WP-0003-T04 -status: todo +status: done priority: high state_hub_task_id: "dc1ca5f0-b511-499c-aa47-76f88d2a20a6" ``` @@ -85,7 +85,7 @@ reviewed against `canon/CanonicalGlossary.md`. ```task id: IDENTITY-WP-0003-T05 -status: todo +status: done priority: high state_hub_task_id: "989b1e68-dceb-4877-87f3-c7c93ddf076d" ``` @@ -99,7 +99,7 @@ changes. ```task id: IDENTITY-WP-0003-T06 -status: todo +status: done priority: medium state_hub_task_id: "5e05f41d-07d1-4566-b2ec-deda56c3727a" ```