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