From 8a1482098b1843f64af157af4997d571d57f4546 Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 4 Jun 2026 12:12:07 +0200 Subject: [PATCH] Seeded research project with INTENT.md, ResearchProposal.md and initial work. --- INTENT.md | 168 +++++ ResearchProposal.md | 678 ++++++++++++++++++ research/CorpusIndex.md | 66 ++ research/README.md | 10 + research/ResearchSeed.md | 549 ++++++++++++++ .../nist-800-63-4.md | 50 ++ .../oidc-core-subject-identifiers.md | 50 ++ .../saml-nameid-federation.md | 50 ++ .../shared-signals-caep-risc.md | 50 ++ ...cedar-principal-action-resource-context.md | 50 ++ .../cerbos-abac-derived-roles.md | 50 ++ .../openfga-modeling.md | 50 ++ .../zanzibar-rebac.md | 50 ++ ...deterministic-vs-probabilistic-matching.md | 50 ++ .../gdpr-pseudonymization.md | 50 ++ .../synonymity-assertions.md | 50 ++ .../keycloak-organizations.md | 50 ++ .../ldap-rfc4519-inetorgperson-rfc2798.md | 50 ++ .../identity-provisioning/ory-kratos-keto.md | 50 ++ .../scim-rfc7643-rfc7644.md | 50 ++ .../zitadel-organizations-projects.md | 50 ++ .../activitypub-actors-followers.md | 50 ++ .../foaf-agent-person-group-onlineaccount.md | 50 ++ ...hema-org-person-organization-membership.md | 50 ++ .../webid-solid-profile.md | 50 ++ research/verifiable-claims/did-core.md | 50 ++ research/verifiable-claims/openid4vc.md | 50 ++ research/verifiable-claims/vc-data-model-2.md | 50 ++ 28 files changed, 2621 insertions(+) create mode 100644 INTENT.md create mode 100644 ResearchProposal.md create mode 100644 research/CorpusIndex.md create mode 100644 research/README.md create mode 100644 research/ResearchSeed.md create mode 100644 research/authentication-federation/nist-800-63-4.md create mode 100644 research/authentication-federation/oidc-core-subject-identifiers.md create mode 100644 research/authentication-federation/saml-nameid-federation.md create mode 100644 research/authentication-federation/shared-signals-caep-risc.md create mode 100644 research/authorization-relationships/cedar-principal-action-resource-context.md create mode 100644 research/authorization-relationships/cerbos-abac-derived-roles.md create mode 100644 research/authorization-relationships/openfga-modeling.md create mode 100644 research/authorization-relationships/zanzibar-rebac.md create mode 100644 research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md create mode 100644 research/entity-resolution-privacy/gdpr-pseudonymization.md create mode 100644 research/entity-resolution-privacy/synonymity-assertions.md create mode 100644 research/identity-provisioning/keycloak-organizations.md create mode 100644 research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md create mode 100644 research/identity-provisioning/ory-kratos-keto.md create mode 100644 research/identity-provisioning/scim-rfc7643-rfc7644.md create mode 100644 research/identity-provisioning/zitadel-organizations-projects.md create mode 100644 research/social-community-graphs/activitypub-actors-followers.md create mode 100644 research/social-community-graphs/foaf-agent-person-group-onlineaccount.md create mode 100644 research/social-community-graphs/schema-org-person-organization-membership.md create mode 100644 research/social-community-graphs/webid-solid-profile.md create mode 100644 research/verifiable-claims/did-core.md create mode 100644 research/verifiable-claims/openid4vc.md create mode 100644 research/verifiable-claims/vc-data-model-2.md diff --git a/INTENT.md b/INTENT.md new file mode 100644 index 0000000..0166c2a --- /dev/null +++ b/INTENT.md @@ -0,0 +1,168 @@ +# INTENT.md + +## Purpose + +`identity-canon` exists to research, clarify, and define a canonical terminology and conceptual data model for identity, user, organization, community, and relationship management across multi-tenant, multi-vendor, multi-community systems. + +The project is intentionally focused on the **research and terminology layer**. It does not implement user management, identity provisioning, authentication, authorization, or UI workflows directly. Instead, it provides the conceptual foundation that later implementation projects can rely on. + +## Core Intent + +The core intent is to develop a clear, orthogonal vocabulary and canonical model for describing: + +* natural persons, users, accounts, identities, personas, and profiles +* organizations, enterprises, sub-organizations, vendors, tenants, customers, and legal entities +* communities, families, households, teams, spontaneous groups, and social graphs +* actors, agents, bots, service accounts, and delegated representatives +* memberships, affiliations, followers, ownership, representation, delegation, and trust relationships +* weak and strong synonymity between identities, accounts, identifiers, and real-world actors +* the distinction between social, legal, operational, and authorization-relevant relationships + +The project should help avoid the common collapse of overloaded terms such as `user`, `group`, `role`, `tenant`, `organization`, `account`, and `identity`. + +## Strategic Role + +`identity-canon` is a reference project for future identity-related systems and implementation repositories. + +It should provide: + +1. a researched corpus of relevant standards, concepts, and terminology; +2. a canonical vocabulary suitable for humans and agents; +3. a conceptual model for user, organization, community, and identity management; +4. a basis for later schemas, APIs, CLI tools, UI workflows, and adapter implementations; +5. a shared language for connecting IAM, social graph, enterprise directory, community, family, and authorization concepts. + +The repository should serve as a stable conceptual anchor before implementation-specific decisions are made. + +## Intended Users + +The primary users of this repository are: + +* system architects designing multi-tenant identity and user-management systems; +* developers implementing user, organization, tenant, and community management components; +* security and IAM engineers integrating systems such as Keycloak, Keycape, LLDAP, Authelia, privacyIDEA, OpenBao, SCIM, OIDC, SAML, LDAP, OpenFGA, Cedar, or related tools; +* product designers creating CLI and UI workflows for managing users, organizations, communities, and relationships; +* AI agents that need a precise terminology reference when generating schemas, documentation, workflows, or implementation plans. + +## Scope + +`identity-canon` covers research, terminology, and conceptual modeling. + +In scope: + +* literature and standards research; +* terminology analysis; +* canonical concept definitions; +* comparison of overlapping terms across IAM, directory services, social graphs, enterprise systems, and authorization models; +* conceptual diagrams and model descriptions; +* model constraints and design principles; +* synonymity and entity-resolution concepts; +* scope, tenant, organization, community, family, and group distinctions; +* relationship semantics such as membership, affiliation, representation, delegation, following, ownership, and trust; +* recommendations for future implementation repositories. + +Out of scope: + +* implementation code; +* production APIs; +* database migrations; +* UI components; +* CLI commands; +* adapter implementations; +* direct integration with Keycloak, LDAP, SCIM, OIDC, SAML, OpenFGA, or other systems; +* operational identity lifecycle tooling. + +Implementation repositories may later consume the results of `identity-canon`, but this repository remains implementation-neutral. + +## Design Principles + +### 1. Do not start with “user” + +The term `user` is overloaded. The canonical model should avoid using `user` as the root concept. Instead, it should distinguish actors, natural persons, accounts, identities, profiles, personas, credentials, and principals. + +### 2. Separate social, legal, operational, and authorization semantics + +An organization may be a legal entity, a tenant, a community, a billing customer, an employer, a vendor, or an authorization scope — but these meanings must not be collapsed into one concept. + +### 3. Model relationships explicitly + +Membership, affiliation, following, ownership, representation, delegation, administration, and trust should be modeled as distinct relationship types, not hidden inside groups or roles. + +### 4. Treat synonymity as an assertion, not a destructive merge + +Weak and strong synonymity should be represented as scoped, evidenced assertions between identifiers, accounts, identities, or actors. Identity linking should preserve source, confidence, scope, evidence, and revocation state. + +### 5. Keep concepts orthogonal + +The model should minimize conceptual overlap. If two terms are similar, the repository should explain the distinction or deliberately collapse them with clear justification. + +### 6. Remain implementation-neutral + +The canonical model should be compatible with common IAM, directory, social graph, and authorization systems, but should not mirror any single product’s terminology too closely. + +## Research Areas + +The repository should collect and analyze knowledge from at least the following areas: + +* SCIM, LDAP, and directory schemas; +* OpenID Connect, SAML, WebAuthn, and federation models; +* NIST digital identity guidelines and identity assurance terminology; +* Keycloak, ZITADEL, Ory, Authelia, LLDAP, and related IAM systems; +* ActivityPub, FOAF, WebID, Solid, and social graph models; +* Google Zanzibar, OpenFGA, Cedar, Cerbos, and relationship-based authorization; +* W3C DID and Verifiable Credentials; +* entity resolution, identity matching, and synonymity; +* GDPR-relevant concepts such as pseudonymization, data minimization, and identity linkage. + +## Expected Outputs + +The repository should eventually contain: + +* a curated research corpus; +* a glossary of canonical identity-management terms; +* a terminology conflict map; +* a conceptual entity and relationship model; +* synonymity and identity-linking model notes; +* comparison notes against major standards and tools; +* model design principles; +* candidate schema sketches; +* recommendations for downstream implementation projects. + +## Downstream Relationship + +`identity-canon` may later inform projects such as: + +* `user-engine` — operational user and account management; +* `user-accounts` — user-facing account and preference UI; +* `user-manager` — administrative user-management UI; +* `identity-connect` — adapters to IAM and directory systems; +* `actor-graph` — relationship and synonymity graph engine; +* `access-control` or related authorization projects; +* tenant, organization, community, and family management tooling. + +These projects should treat `identity-canon` as a conceptual reference, not as an implementation dependency unless a later explicit schema package is extracted. + +## Non-Goals + +`identity-canon` is not intended to become: + +* a replacement for Keycloak, LDAP, SCIM, OIDC, SAML, or OpenFGA; +* a complete authorization policy language; +* a production identity provider; +* a database product; +* a UI framework; +* a CLI implementation; +* a social network implementation. + +Its value lies in making the terminology and conceptual structure clear enough that such systems can later be designed and integrated coherently. + +## Guiding Question + +The guiding question of `identity-canon` is: + +> What is the smallest clear set of orthogonal concepts needed to model persons, accounts, identities, organizations, tenants, communities, families, agents, and their relationships across enterprise IAM, social systems, and multi-tenant platforms? + +## Status + +This repository begins as a research and terminology project. Its early work should prioritize clarity, comparison, and conceptual grounding over premature schema or implementation design. + diff --git a/ResearchProposal.md b/ResearchProposal.md new file mode 100644 index 0000000..f3631d0 --- /dev/null +++ b/ResearchProposal.md @@ -0,0 +1,678 @@ +# ResearchProposal.md + +# Research Proposal: identity-canon + +## 1. Purpose + +`identity-canon` is a research and terminology project focused on developing a canonical conceptual model for identity, user, organization, community, tenant, and relationship management in complex multi-tenant systems. + +The purpose of this research is to distill a coherent, orthogonal vocabulary and conceptual data model from overlapping domains such as identity and access management, enterprise directories, social graph systems, community platforms, family and household account models, decentralized identity, entity resolution, and relationship-based authorization. + +The resulting work should provide a stable conceptual foundation for later implementation projects, including CLI tools, UI components, identity adapters, user-management engines, organization-management systems, and relationship graph services. + +This repository is intentionally not an implementation project. It does not build a user-management system, identity provider, authorization engine, CLI, or UI. Its role is to clarify the conceptual ground before such systems are built. + +## 2. Background + +Modern identity and user-management systems often reuse the same terms with different meanings. Words such as `user`, `account`, `identity`, `organization`, `group`, `role`, `tenant`, `profile`, `principal`, and `member` are commonly overloaded. + +In classic enterprise IAM, a `user` may mean an account in a directory. In social platforms, a user may mean a public profile, handle, or actor. In authorization systems, the relevant concept may be a principal or subject. In multi-tenant SaaS systems, an organization may be a customer, tenant, billing unit, legal entity, administrative boundary, or application-specific workspace. In communities and social graphs, groups, followers, moderators, families, and spontaneous interest groups introduce relationship patterns that do not fit cleanly into traditional enterprise directory models. + +At the same time, modern systems increasingly need to support: + +* multiple tenants; +* multiple vendors; +* multiple customer organizations; +* organizations with sub-organizations; +* communities and social graphs; +* family and household entities; +* individual users; +* bots, service accounts, and AI agents; +* delegated administration; +* cross-system identity linking; +* weak and strong synonymity between identity records; +* privacy-preserving pseudonymous identities; +* relationship-based authorization. + +The research challenge is to develop a conceptual model that is broad enough to represent these cases, but precise enough to avoid conceptual collapse. + +## 3. Research Goal + +The primary goal is to answer the following guiding question: + +> What is the smallest clear set of orthogonal concepts needed to model persons, accounts, identities, organizations, tenants, communities, families, agents, and their relationships across enterprise IAM, social systems, and multi-tenant platforms? + +The research should produce a canonical vocabulary and conceptual model that can serve as a reference for future identity-related systems. + +## 4. Research Objectives + +The research has the following objectives: + +1. Identify and compare relevant terminology from major identity, directory, federation, authorization, social graph, and decentralized identity systems. + +2. Document where common terms overlap, conflict, or imply different modeling assumptions. + +3. Define a clear canonical vocabulary for the identity-canon project. + +4. Distinguish social, legal, operational, authentication, and authorization meanings of identity-related concepts. + +5. Develop a conceptual entity and relationship model that can represent natural persons, accounts, organizations, tenants, communities, families, service accounts, bots, agents, and spontaneous groups. + +6. Define a model for weak and strong synonymity between entities, identities, accounts, identifiers, and profiles. + +7. Identify how the conceptual model can map to practical systems such as SCIM, LDAP, OIDC, SAML, Keycloak, LLDAP, Authelia, privacyIDEA, OpenBao, OpenFGA, Cedar, ActivityPub, FOAF, DID, and Verifiable Credentials. + +8. Provide recommendations for downstream implementation repositories without prematurely binding the research model to any specific tool or product. + +## 5. Scope + +## 5.1 In Scope + +The research covers: + +* terminology research; +* standards analysis; +* conceptual modeling; +* canonical vocabulary design; +* terminology conflict mapping; +* identity and account modeling; +* organization, tenant, community, family, and group modeling; +* actor and agent modeling; +* membership and relationship semantics; +* delegation and representation semantics; +* synonymity and identity-resolution concepts; +* source and evidence modeling; +* privacy and pseudonymity considerations; +* conceptual mapping to existing standards and tools; +* recommendations for downstream implementation work. + +## 5.2 Out of Scope + +The research does not cover: + +* implementation code; +* database migrations; +* production APIs; +* CLI implementation; +* UI implementation; +* identity-provider implementation; +* authorization-policy implementation; +* direct integration with Keycloak, LDAP, SCIM, OIDC, SAML, OpenFGA, or other systems; +* operational runbooks; +* production security hardening; +* final product UX design. + +Implementation-specific work may be derived from the research later, but remains outside this repository unless explicitly extracted into a separate implementation project. + +## 6. Research Domains + +The research should cover at least the following domains. + +## 6.1 Identity Provisioning and Directory Models + +Relevant topics include: + +* SCIM users, groups, schemas, and provisioning flows; +* LDAP object classes and attributes; +* inetOrgPerson; +* organizational units; +* group membership models; +* enterprise directory assumptions; +* provisioning and deprovisioning lifecycle semantics. + +Key questions: + +* What does each system mean by `user`, `group`, `organization`, and `member`? +* Which concepts are identity concepts, and which are directory organization concepts? +* How do provisioning models differ from authentication and authorization models? + +## 6.2 Authentication and Federation + +Relevant topics include: + +* OpenID Connect; +* SAML; +* WebAuthn; +* passkeys; +* federated identity; +* subject identifiers; +* pairwise and public identifiers; +* identity provider and relying party relationships; +* authentication assurance. + +Key questions: + +* What is the difference between an actor, an identity, an account, a subject, and a principal? +* How should externally issued identifiers be represented? +* How should pairwise or pseudonymous identifiers be modeled? +* How should assurance levels and authentication evidence be represented? + +## 6.3 Multi-Tenant IAM Systems + +Relevant topics include: + +* Keycloak realms, organizations, groups, roles, and clients; +* Keycape as a lightweight Keycloak-compatible concept; +* LLDAP and Authelia; +* privacyIDEA; +* ZITADEL organizations and projects; +* Ory Kratos and Keto; +* tenant administration; +* delegated user management. + +Key questions: + +* What is a tenant? +* How is a tenant different from an organization, realm, customer, or scope? +* How should vendor and customer relationships be modeled? +* How should one actor participate in multiple tenants or organizations? + +## 6.4 Authorization and Relationship-Based Access Control + +Relevant topics include: + +* Google Zanzibar; +* OpenFGA; +* relationship tuples; +* ReBAC; +* RBAC; +* ABAC; +* Cedar; +* Cerbos; +* principal-action-resource-context models; +* delegated administration. + +Key questions: + +* Which relationships belong in the identity model? +* Which relationships belong only in the authorization model? +* How can canonical identity relationships support later authorization decisions without becoming an authorization engine? +* How should roles be distinguished from permissions, capabilities, memberships, and relationship labels? + +## 6.5 Social Graph and Community Models + +Relevant topics include: + +* ActivityPub actors; +* followers and following relationships; +* communities; +* moderation roles; +* social profiles; +* handles; +* public and private personas; +* FOAF; +* WebID; +* Solid profiles; +* Schema.org person and organization concepts. + +Key questions: + +* How can social graph relationships coexist with enterprise IAM relationships? +* How should followers differ from members? +* How should communities differ from organizations? +* How should public personas differ from accounts and real-world persons? + +## 6.6 Family, Household, and Small Group Models + +Relevant topics include: + +* family accounts; +* household membership; +* guardianship; +* dependent accounts; +* shared resources; +* informal group administration; +* temporary and spontaneous groups. + +Key questions: + +* How should families and households be represented without forcing them into enterprise organization models? +* How should guardianship, representation, and delegated control be modeled? +* How should informal groups differ from formal organizations and tenants? + +## 6.7 Decentralized Identity and Verifiable Claims + +Relevant topics include: + +* Decentralized Identifiers; +* DID documents; +* Verifiable Credentials; +* issuers, holders, subjects, and verifiers; +* credential evidence; +* portable claims; +* externally controlled identifiers. + +Key questions: + +* How should externally issued claims be represented? +* How can credentials support relationship and membership assertions? +* How should the model distinguish a claim from a verified fact? +* How can decentralized identity concepts inform a canonical model without forcing the system to become a decentralized identity platform? + +## 6.8 Entity Resolution, Synonymity, and Privacy + +Relevant topics include: + +* deterministic matching; +* probabilistic matching; +* entity resolution; +* record linkage; +* weak identity links; +* strong identity links; +* pseudonymization; +* anonymization; +* GDPR-sensitive identity linkage; +* source, evidence, confidence, and revocation. + +Key questions: + +* When can two accounts, identities, or identifiers be treated as the same actor? +* How should uncertainty be represented? +* What is the difference between operational linking and real-world identity equivalence? +* How should identity links be scoped? +* How should privacy-preserving identity linkage be modeled? + +## 7. Initial Conceptual Hypothesis + +The initial hypothesis is that the canonical model can be built around a small number of orthogonal primitives: + +* `Entity` — anything that can be referred to as a modeled thing; +* `Actor` — an entity capable of action or delegated action; +* `Identity` — a claim-bearing representation of an actor in a context; +* `Account` — a system-local operational identity used for access, profile, preferences, or credentials; +* `Identifier` — a value that refers to an entity, identity, account, or actor; +* `Scope` — a bounded context in which identifiers, relationships, policies, and claims have meaning; +* `Relationship` — a typed edge between modeled entities; +* `Evidence` — the basis on which a claim, relationship, or synonymity assertion is trusted; +* `Credential` — proof material or authentication material associated with an identity, account, or actor; +* `Claim` — a statement made by a source about an entity, relationship, or attribute. + +From these primitives, more familiar concepts can be derived or specialized: + +* `User` as an account or identity used by a natural person in a given scope; +* `Tenant` as an operational scope with isolation and delegated administration; +* `Organization` as a structured collective actor; +* `Community` as a participatory collective actor; +* `Family` or `Household` as a kinship or domestic collective actor; +* `Group` as either a collective actor, membership set, or authorization convenience, depending on context; +* `Role` as a named relationship or policy pattern within a scope; +* `Principal` as an actor or account considered for an authorization decision. + +This hypothesis should be challenged and refined through the research process. + +## 8. Research Method + +The research should proceed through iterative corpus analysis and model refinement. + +## 8.1 Corpus Collection + +Collect relevant standards, specifications, product documentation, architecture references, academic concepts, and practical examples. + +Each source should be summarized with: + +* source name; +* source type; +* domain; +* key concepts; +* relevant terminology; +* assumptions; +* modeling implications; +* conflicts with other sources; +* usefulness for identity-canon. + +## 8.2 Terminology Extraction + +Extract important terms from each source and classify them by domain. + +For each term, capture: + +* source-specific definition; +* implied assumptions; +* related terms; +* overloaded meanings; +* canonical candidate mapping; +* open questions. + +## 8.3 Conflict Mapping + +Identify where different systems use the same term for different concepts or different terms for similar concepts. + +Examples: + +* `user` vs `person` vs `account` vs `subject` vs `principal`; +* `tenant` vs `organization` vs `realm` vs `customer`; +* `group` vs `community` vs `team` vs `role`; +* `membership` vs `affiliation` vs `follower`; +* `identity` vs `identifier` vs `credential` vs `account`. + +## 8.4 Canonical Concept Design + +Define canonical concepts that minimize overlap and make distinctions explicit. + +Each canonical concept should include: + +* name; +* definition; +* rationale; +* included meanings; +* excluded meanings; +* related concepts; +* examples; +* counterexamples; +* mapping to external systems; +* open issues. + +## 8.5 Model Construction + +Build an initial conceptual entity and relationship model. + +The model should include: + +* entity types; +* actor types; +* identity/account/profile/persona distinctions; +* scope and tenant distinctions; +* collective actor types; +* relationship types; +* synonymity assertions; +* evidence and claim references; +* lifecycle states. + +## 8.6 Scenario Testing + +Test the model against representative scenarios. + +Initial scenarios should include: + +1. single person with one local account; +2. person with multiple accounts across different scopes; +3. enterprise with sub-organizations; +4. vendor tenant providing applications to customer tenants; +5. customer organization with delegated administrators; +6. family with guardian and dependent accounts; +7. spontaneous interest group; +8. community with members, moderators, and followers; +9. social media follower graph; +10. bot or service account acting for an organization; +11. AI agent acting under delegated authority; +12. weak identity match from imported data; +13. strong account link after explicit verification; +14. pseudonymous profile linked only within a restricted scope; +15. organization represented by a legal entity and several operational tenants. + +## 8.7 Model Revision + +Refine the model based on scenario tests and terminology conflicts. + +Revisions should explicitly document: + +* what changed; +* why it changed; +* which ambiguity was resolved; +* which scenarios are better supported; +* which trade-offs remain. + +## 9. Expected Deliverables + +The repository should eventually provide the following deliverables. + +## 9.1 Research Corpus + +A structured set of notes on relevant standards, tools, and conceptual domains. + +Suggested location: + +```text +research/ +``` + +## 9.2 Source Summaries + +Concise summaries of individual sources. + +Suggested location: + +```text +research/sources/ +``` + +## 9.3 Terminology Inventory + +A collected inventory of terms across sources. + +Suggested location: + +```text +terminology/TerminologyInventory.md +``` + +## 9.4 Terminology Conflict Map + +A document showing overloaded, conflicting, and ambiguous terms. + +Suggested location: + +```text +terminology/TerminologyConflictMap.md +``` + +## 9.5 Canonical Glossary + +The core glossary of identity-canon terms. + +Suggested location: + +```text +canon/CanonicalGlossary.md +``` + +## 9.6 Concept Cards + +Reusable concept definition files for important canonical concepts. + +Suggested location: + +```text +canon/concepts/ +``` + +## 9.7 Conceptual Model + +A conceptual model describing entity types, relationship types, scopes, synonymity assertions, and evidence references. + +Suggested location: + +```text +model/ConceptualModel.md +``` + +## 9.8 Scenario Tests + +A set of scenario-based model validation notes. + +Suggested location: + +```text +scenarios/ +``` + +## 9.9 Open Questions + +A running list of unresolved conceptual decisions. + +Suggested location: + +```text +OpenQuestions.md +``` + +## 9.10 Downstream Recommendations + +Recommendations for later implementation repositories. + +Suggested location: + +```text +DownstreamRecommendations.md +``` + +## 10. Suggested Repository Structure + +```text +identity-canon/ + INTENT.md + ResearchProposal.md + README.md + + research/ + CorpusIndex.md + sources/ + scim.md + ldap.md + oidc.md + saml.md + nist-digital-identity.md + keycloak.md + zitadel.md + ory.md + activitypub.md + foaf.md + webid-solid.md + zanzibar-openfga.md + cedar.md + did.md + verifiable-credentials.md + entity-resolution.md + gdpr-pseudonymization.md + + terminology/ + TerminologyInventory.md + TerminologyConflictMap.md + ExternalTermMappings.md + + canon/ + CanonicalGlossary.md + DesignPrinciples.md + concepts/ + Entity.md + Actor.md + NaturalPerson.md + CollectiveActor.md + Organization.md + Community.md + FamilyOrHousehold.md + Tenant.md + Scope.md + Identity.md + Account.md + Identifier.md + Profile.md + Persona.md + Credential.md + Principal.md + Relationship.md + Membership.md + Affiliation.md + Representation.md + Delegation.md + Ownership.md + Trust.md + SynonymityAssertion.md + Evidence.md + Claim.md + + model/ + ConceptualModel.md + RelationshipModel.md + SynonymityModel.md + ScopeModel.md + LifecycleModel.md + + scenarios/ + ScenarioIndex.md + SinglePersonSingleAccount.md + EnterpriseWithSubOrganizations.md + VendorCustomerTenants.md + FamilyWithDependentAccounts.md + CommunityWithFollowers.md + SpontaneousInterestGroup.md + ServiceAccountActingForOrganization.md + WeakIdentityMatch.md + StrongAccountLink.md + PseudonymousProfile.md + + decisions/ + DecisionLog.md + + OpenQuestions.md + DownstreamRecommendations.md +``` + +## 11. Success Criteria + +The research should be considered successful when it provides: + +1. a clear distinction between persons, users, accounts, identities, profiles, personas, principals, and actors; + +2. a clear distinction between tenants, realms, organizations, legal entities, customers, vendors, communities, families, groups, and scopes; + +3. a relationship model that can represent memberships, affiliations, followers, ownership, representation, delegation, administration, and trust without collapsing them into generic groups or roles; + +4. a synonymity model that can represent weak, strong, scoped, operational, legal, and privacy-preserving identity links; + +5. terminology mappings to major external standards and tools; + +6. scenario tests showing that the model can represent enterprise IAM, social graph, family, community, vendor/customer, and agentic use cases; + +7. enough clarity for downstream projects to design schemas, APIs, CLI workflows, UI workflows, and adapters without re-solving the terminology problem. + +## 12. Risks and Challenges + +## 12.1 Over-Abstraction + +The model may become too abstract to guide implementation. To reduce this risk, concepts should be tested against concrete scenarios. + +## 12.2 Product Terminology Contamination + +The model may accidentally inherit the terminology of one specific tool, such as Keycloak, LDAP, or OpenFGA. To reduce this risk, external mappings should be kept separate from canonical definitions. + +## 12.3 Conceptual Collapse + +Terms such as `user`, `group`, `role`, `tenant`, and `organization` may continue to overlap. To reduce this risk, the project should explicitly document excluded meanings and counterexamples for each canonical concept. + +## 12.4 Privacy and Legal Complexity + +Identity linking, synonymity, family relationships, and organizational representation may have privacy or legal implications. The research should document these implications without attempting to provide legal advice. + +## 12.5 Scope Creep + +The research may expand into implementation, authorization policy design, UI design, or operational tooling. To reduce this risk, downstream implementation ideas should be captured as recommendations, not built inside this repository. + +## 13. Immediate Next Steps + +1. Create the initial repository structure. + +2. Add `INTENT.md` and `ResearchProposal.md`. + +3. Create `research/CorpusIndex.md`. + +4. Seed source notes for SCIM, LDAP, OIDC, SAML, Keycloak, ActivityPub, OpenFGA, Cedar, DID, Verifiable Credentials, and entity resolution. + +5. Create `terminology/TerminologyInventory.md`. + +6. Create `terminology/TerminologyConflictMap.md`. + +7. Draft the first version of `canon/DesignPrinciples.md`. + +8. Draft the first version of `canon/CanonicalGlossary.md`. + +9. Create the first scenario tests. + +10. Refine the conceptual model based on the scenario tests. + +## 14. Working Definition of the Project + +`identity-canon` researches and defines the conceptual language needed to model identity-related systems before they become implementation-specific. + +It aims to make identity, account, organization, tenant, community, family, agent, relationship, and synonymity concepts precise enough that future systems can be built with less ambiguity, better interoperability, and clearer security boundaries. + diff --git a/research/CorpusIndex.md b/research/CorpusIndex.md new file mode 100644 index 0000000..6882fa1 --- /dev/null +++ b/research/CorpusIndex.md @@ -0,0 +1,66 @@ +# CorpusIndex.md + +# identity-canon Research Corpus Index + +This index tracks the research corpus for `identity-canon`. + +The repository is focused on research and terminology. The corpus should collect source notes, terminology extracts, conflict observations, and modeling implications from standards, product documentation, semantic vocabularies, authorization systems, decentralized identity work, and entity-resolution/privacy research. + +## Source Stack + +### identity-provisioning + +- `scim-rfc7643-rfc7644.md` +- `ldap-rfc4519-inetorgperson-rfc2798.md` +- `keycloak-organizations.md` +- `zitadel-organizations-projects.md` +- `ory-kratos-keto.md` + +### authentication-federation + +- `oidc-core-subject-identifiers.md` +- `saml-nameid-federation.md` +- `nist-800-63-4.md` +- `shared-signals-caep-risc.md` + +### social-community-graphs + +- `activitypub-actors-followers.md` +- `foaf-agent-person-group-onlineaccount.md` +- `webid-solid-profile.md` +- `schema-org-person-organization-membership.md` + +### authorization-relationships + +- `zanzibar-rebac.md` +- `openfga-modeling.md` +- `cedar-principal-action-resource-context.md` +- `cerbos-abac-derived-roles.md` + +### verifiable-claims + +- `did-core.md` +- `vc-data-model-2.md` +- `openid4vc.md` + +### entity-resolution-privacy + +- `deterministic-vs-probabilistic-matching.md` +- `synonymity-assertions.md` +- `gdpr-pseudonymization.md` + +## Source Note Template + +Each source note should capture: + +- source name; +- source type; +- domain; +- key concepts; +- relevant terminology; +- assumptions; +- modeling implications; +- conflicts with other sources; +- usefulness for identity-canon; +- candidate canonical mappings; +- open questions. diff --git a/research/README.md b/research/README.md new file mode 100644 index 0000000..e0f0378 --- /dev/null +++ b/research/README.md @@ -0,0 +1,10 @@ +# research + +This directory contains the research corpus for `identity-canon`. + +Start with: + +- `ResearchSeed.md` for the initial research framing and seeded terminology; +- `CorpusIndex.md` for the source stack and source note structure. + +Each subdirectory corresponds to one research domain. diff --git a/research/ResearchSeed.md b/research/ResearchSeed.md new file mode 100644 index 0000000..b85ec4d --- /dev/null +++ b/research/ResearchSeed.md @@ -0,0 +1,549 @@ +# ResearchSeed.md + +# identity-canon Research Seed + +This file captures the initial research seeding information for `identity-canon`. + +The research goal is to distill a canonical terminology and conceptual data model for identity, user, organization, community, tenant, and relationship management in complex systems that are multi-tenant, multi-vendor, multi-community, and multi-user capable. + +The model should support enterprises with sub-organizations, social communities, social-media follower graphs, single users, family entities, spontaneous interest groups, bots, service accounts, AI agents, and weak/strong synonymity between identity records. + +## Initial Framing + +The project should not start from a simple `user` table or from a classic `users + groups + roles` IAM schema. + +A more robust canonical core is a graph of: + +- actors; +- identities; +- accounts; +- identifiers; +- profiles; +- personas; +- scopes; +- tenants; +- organizations; +- communities; +- families/households; +- memberships; +- relationships; +- credentials; +- claims; +- evidence; +- synonymity assertions. + +Classic IAM systems, social networks, enterprise directories, family accounts, communities, vendors, customers, and spontaneous groups can then be modeled as specializations or patterns over that graph. + +## Important Research Domains + +## 1. Identity Provisioning and Directory Models + +Important sources: + +- SCIM 2.0: RFC 7643 and RFC 7644; +- LDAP and inetOrgPerson: RFC 4519 and RFC 2798; +- Keycloak Organizations; +- ZITADEL organizations and projects; +- Ory Kratos and Keto. + +Research focus: + +- provisioning semantics; +- users and groups; +- organization/member terminology; +- directory assumptions; +- account lifecycle; +- separation between identity management and authorization. + +SCIM is especially important as a provisioning baseline because it defines platform-neutral schemas and protocol operations for user and group resources. + +LDAP and inetOrgPerson remain important because lightweight IAM stacks and enterprise systems still inherit LDAP-style person, organizational unit, and group terminology. + +Keycloak and ZITADEL provide live multi-tenant IAM product vocabularies. Ory is useful because it separates identity management from authorization. + +## 2. Authentication and Federation + +Important sources: + +- OpenID Connect Core; +- SAML 2.0; +- NIST SP 800-63-4; +- OpenID Shared Signals, CAEP, and RISC. + +Research focus: + +- issuer and subject concepts; +- pairwise and public subject identifiers; +- authentication assurance; +- federation assurance; +- assertions and claims; +- risk and security event streams; +- account linking and pseudonymous identifiers. + +OIDC is central because externally issued subject identifiers and pairwise identifiers directly affect synonymity and account-linking semantics. + +SAML remains important for enterprise federation and assertion semantics. + +NIST identity guidance is useful for separating identity proofing, authentication assurance, federation assurance, and lifecycle management. + +Shared Signals, CAEP, and RISC suggest that canonical identity models should also anticipate dynamic security and lifecycle events. + +## 3. Social Graph and Community Models + +Important sources: + +- ActivityPub; +- FOAF; +- WebID; +- Solid profiles; +- Schema.org Person and Organization. + +Research focus: + +- actors; +- followers/following; +- public profiles; +- handles; +- accounts on federated servers; +- communities; +- groups; +- social relationships; +- semantic vocabularies for persons and organizations. + +ActivityPub is especially relevant because it treats users as server-side actors with inboxes and outboxes. A person may have several actors across servers, which maps well to contextual identities and personas. + +FOAF and Schema.org are useful because they distinguish persons, agents, organizations, groups, accounts, and membership-like properties. + +WebID/Solid are useful for user-controlled profiles and decentralized identity-style profile discovery. + +## 4. Authorization and Relationship Semantics + +Important sources: + +- Google Zanzibar; +- OpenFGA; +- Cedar; +- AWS Verified Permissions; +- Cerbos. + +Research focus: + +- relationship-based authorization; +- subject-relation-object tuples; +- principals; +- resources; +- actions; +- context; +- roles vs permissions vs relationships; +- delegated administration. + +Zanzibar/OpenFGA-style relationship tuples are especially close to what `identity-canon` needs for memberships, ownership, representation, delegation, family roles, community moderation, vendor/customer relationships, and tenant administration. + +Cedar’s principal-action-resource-context distinction is useful for preserving orthogonality between identity, action, resource, and request context. + +## 5. Decentralized Identity and Verifiable Claims + +Important sources: + +- W3C DID Core; +- W3C Verifiable Credentials Data Model 2.0; +- OpenID for Verifiable Credentials. + +Research focus: + +- decentralized identifiers; +- DID subjects and controllers; +- verification methods; +- claims; +- issuers; +- holders; +- verifiers; +- presentations; +- portable identity claims; +- externally controlled identifiers. + +DID and Verifiable Credentials are relevant when identity, membership, authorization, or representation claims are issued outside the platform. + +The canonical model should distinguish claims from verified facts and should preserve issuer, evidence, scope, validity, and revocation state. + +## 6. Entity Resolution, Synonymity, and Privacy + +Important sources: + +- deterministic matching; +- probabilistic matching; +- entity resolution and record linkage literature; +- GDPR pseudonymization and anonymization guidance. + +Research focus: + +- weak identity matches; +- strong identity links; +- scoped identity equivalence; +- operational account linking; +- legal identity links; +- privacy-preserving links; +- source and evidence; +- confidence; +- revocation; +- GDPR implications. + +The model should avoid treating identity linkage as a destructive merge. Instead, synonymity should be modeled as an assertion with strength, scope, source, evidence, confidence, validity, and revocation state. + +## Terminology Challenge + +Many common terms are overloaded: + +| Term | Common Meanings | Modeling Risk | +| --- | --- | --- | +| User | Human, account, login principal, profile, customer record, app user | Collapses person, account, and actor | +| Account | Login credential set, billing account, social media handle, tenant account | Collapses authentication and business relationship | +| Organization | Legal entity, tenant, department, team, community, vendor, customer | Collapses legal structure, membership scope, and operational boundary | +| Group | LDAP group, social group, permission group, family, team, community | Collapses social grouping and authorization grouping | +| Role | Job function, permission bundle, relationship label, social role | Collapses semantics, permissions, and responsibility | +| Identity | Real-world personhood, credentialed subject, account identity, profile | Collapses entity, claim, authenticator, and identifier | +| Principal | Human user, service account, agent, organization acting entity | Good for authorization, too narrow for social modeling | +| Tenant | Isolation boundary, customer organization, billing unit, realm | Collapses infrastructure boundary and social/legal actor | + +The key design move is to stop using `user` as the root concept. + +## Candidate Canonical Vocabulary + +## Entity and Actor Layer + +### Entity + +Anything that can be referred to as a modeled thing: person, organization, family, community, bot, service, account, resource, project, domain, or device. + +### Actor + +An entity capable of intentional or delegated action in a system. Examples include human persons, organizations acting through representatives, AI agents, service accounts, and community bots. + +### Natural Person + +A human being. This should not be identical to `user`, because a person can have many accounts, profiles, personas, and relationships. + +### Collective Actor + +A group-like actor that can act collectively or be represented by members/admins. Subtypes include enterprise, department, family, community, interest group, vendor, customer tenant, and project team. + +### Artificial Actor + +A bot, service account, automation, coding agent, or autonomous agent. + +## Identity and Account Layer + +### Identity + +A claim-bearing representation of an actor in a context. An actor can have multiple identities. + +### Identifier + +A value used to refer to an identity or entity: UUID, email address, username, OIDC subject, SAML NameID, DID, domain name, phone number, employee number. + +### Account + +A system-local operational identity used for login, profile, preferences, sessions, and credentials. + +### Profile + +A presentation surface of an identity or account. A profile may be public, private, tenant-local, app-local, community-local, or audience-specific. + +### Persona + +A deliberate contextual identity expression of an actor. Examples include private person, employee persona, admin persona, and pseudonymous community handle. + +### Credential + +Something used to authenticate or prove a claim: password, passkey, certificate, TOTP seed, recovery factor, verifiable credential, or domain ownership proof. + +### Authenticator + +The concrete authentication factor or mechanism bound to an account/subscriber. + +## Scope and Tenancy Layer + +### Scope + +A bounded context in which identifiers, memberships, roles, policies, and profile data have meaning. + +### Tenant + +A scope with operational isolation and delegated administration. A tenant may be backed by an organization, family, community, individual, vendor, or platform unit. + +### Realm / Identity Domain + +A hard identity boundary with separate users, credentials, clients, policies, and lifecycle. + +### Organization + +A structured collective actor with governance, membership, and possibly sub-organizations. It may or may not be a legal entity. + +### Legal Entity + +An organization recognized by a jurisdiction. Not every organization, community, or team is a legal entity. + +### Community + +A collective actor primarily organized by shared interest, social graph, participation, or moderation rules rather than employment/legal hierarchy. + +### Household / Family + +A collective actor organized around family/household relationships, guardianship, shared resources, and dependent accounts. + +### Spontaneous Group + +A lightweight collective actor created ad hoc around temporary interest, event, project, or conversation. + +Important distinction: tenant, organization, and community must not be synonyms. A tenant is an operational boundary. An organization, community, or family is a social/legal actor that may own or inhabit a tenant. + +## Relationship Layer + +### Relationship + +A typed edge between entities, actors, accounts, scopes, resources, or other modeled concepts. + +### Membership + +A relationship where an actor participates in a collective actor or scope. + +### Affiliation + +A looser relationship indicating association without necessarily implying membership, authority, or access. + +### Representation + +A relationship where one actor can act on behalf of another. + +### Delegation + +A scoped, revocable grant of authority from one actor to another. + +### Administration + +A delegated authority to manage lifecycle, membership, policy, or resources in a scope. + +### Ownership + +A strong control or responsibility relationship over an entity, resource, or scope. This may require legal, operational, and data-control subtypes. + +### Follower Relationship + +A directional social relationship expressing subscription or attention, not necessarily trust, membership, or permission. + +### Trust Relationship + +A relationship where one actor accepts claims, credentials, or decisions from another actor under defined conditions. + +## Role and Capability Layer + +### Role + +A named relationship pattern in a scope. Examples include member, owner, moderator, billing admin, guardian, employee, and vendor admin. + +### Capability + +An ability to perform an action, usually derived from roles, policies, relationships, credentials, or explicit grants. + +### Permission + +A concrete allowed action on a resource type or instance. + +### Policy + +A rule that derives permissions or capabilities from relationships, attributes, credentials, and context. + +This prevents the classic collapse of role, group, permission bundle, and job title. + +## Synonymity and Identity Resolution Layer + +### Strong Synonymity + +Two identifiers, accounts, or identities are asserted to refer to the same underlying actor with high confidence and strong evidence. + +Examples: + +- same verified OIDC subject from the same issuer; +- account explicitly linked after re-authentication; +- verifiable credential bound to the same DID/controller. + +### Weak Synonymity + +Two records may refer to the same actor based on partial, contextual, or probabilistic evidence. + +Examples: + +- same email seen in imported CSV and social profile; +- matching name/domain; +- same account handle without explicit proof. + +### Scoped Synonymity + +Two identifiers are treated as equivalent only within a defined context. + +Example: + +- a pairwise OIDC subject mapped to a local account for one relying party. + +### Operational Link + +A system-level account link used for convenience, not necessarily a real-world identity assertion. + +### Legal Identity Link + +A stronger assertion that may support contracts, billing, employment, guardianship, or compliance. + +### Privacy-Preserving Link + +A link that enables continuity without exposing global identity. + +Examples: + +- pairwise identifiers; +- pseudonymous handles; +- tenant-local subjects. + +## Synonymity Assertion Fields + +A synonymity assertion should carry at least: + +```text +source +target +relation_type: same_as | probably_same_as | linked_to | represents | controls | acts_for +strength: weak | medium | strong | authoritative +scope +evidence +issuer/source_system +created_at +valid_from / valid_until +revocation_state +privacy_classification +``` + +## Initial Conceptual Model Shape + +```text +Entity + ├─ Actor + │ ├─ NaturalPerson + │ ├─ CollectiveActor + │ │ ├─ Organization + │ │ ├─ LegalEntity + │ │ ├─ Community + │ │ ├─ FamilyOrHousehold + │ │ └─ SpontaneousGroup + │ └─ ArtificialActor + │ ├─ ServiceAccount + │ ├─ Bot + │ └─ Agent + ├─ Account + ├─ Profile + ├─ Credential + ├─ Resource + └─ Scope + ├─ Tenant + ├─ Realm + ├─ OrganizationScope + ├─ CommunityScope + └─ ApplicationScope +``` + +## Initial Relationship Model Shape + +```text +Relationship + subject_entity_id + relation_type + object_entity_id + scope_id + source + evidence_ref + strength + status + valid_from + valid_until + metadata +``` + +## Example Statements the Model Should Express + +```text +Bernd is member of Binect +Binect is sub-organization of Whynot GmbH +User account A is operated by Bernd +ActivityPub actor @x follows @y +Child account C is represented by guardian G +Vendor tenant V provides application App1 +Customer tenant C consumes application App1 +Service account S acts for organization O in scope T +OIDC subject sub123 is strongly linked to local account U in relying-party scope R +Email e@example.com is weakly linked to person P based on imported evidence +``` + +## CLI/UI Implications for Later Work + +Although `identity-canon` is not an implementation repository, the model should later support convenient CLI/UI workflows such as: + +```text +create-person +create-organization +create-community +create-family +create-spontaneous-group +create-tenant-for-actor +invite-member +link-account +claim-domain +assign-admin +delegate-authority +create-service-account +create-agent +add-follower-edge +assert-synonymity +review-synonymity +revoke-link +export-scim +sync-ldap +provision-keycloak +``` + +These workflows should remain downstream implementation concerns. + +## Working Hypothesis + +A strong canonical model can be based on five orthogonal primitives: + +```text +Actor who/what can act +Identity how an actor is represented or claimed in a context +Scope where a statement has meaning +Relationship how modeled things are connected +Evidence why a statement is trusted +``` + +From these, operational IAM concepts can be derived: + +```text +User = account/identity used by a natural person in a scope +Tenant = operational scope with delegated administration +Group = collective actor or membership set, depending on context +Role = named relationship/policy pattern in a scope +Org = structured collective actor +Community = participatory collective actor +Family = household/kinship collective actor +``` + +## Research Direction + +The next step is to populate the source-stack notes, extract terminology from each source, and create: + +- terminology inventory; +- terminology conflict map; +- canonical glossary; +- concept cards; +- scenario tests; +- conceptual model; +- synonymity model; +- scope model; +- downstream recommendations. diff --git a/research/authentication-federation/nist-800-63-4.md b/research/authentication-federation/nist-800-63-4.md new file mode 100644 index 0000000..1d10e3f --- /dev/null +++ b/research/authentication-federation/nist-800-63-4.md @@ -0,0 +1,50 @@ +# Nist 800 63 4 + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +NIST Digital Identity Guidelines: identity proofing, authenticator assurance, federation assurance. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/authentication-federation/oidc-core-subject-identifiers.md b/research/authentication-federation/oidc-core-subject-identifiers.md new file mode 100644 index 0000000..e142cf4 --- /dev/null +++ b/research/authentication-federation/oidc-core-subject-identifiers.md @@ -0,0 +1,50 @@ +# Oidc Core Subject Identifiers + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +OpenID Connect subject identifiers, claims, pairwise/public subjects, relying parties, and issuers. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/authentication-federation/saml-nameid-federation.md b/research/authentication-federation/saml-nameid-federation.md new file mode 100644 index 0000000..aaa4437 --- /dev/null +++ b/research/authentication-federation/saml-nameid-federation.md @@ -0,0 +1,50 @@ +# Saml Nameid Federation + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +SAML assertions, NameID formats, identity provider/service provider federation terminology. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/authentication-federation/shared-signals-caep-risc.md b/research/authentication-federation/shared-signals-caep-risc.md new file mode 100644 index 0000000..cc48311 --- /dev/null +++ b/research/authentication-federation/shared-signals-caep-risc.md @@ -0,0 +1,50 @@ +# Shared Signals Caep Risc + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +OpenID Shared Signals, CAEP, and RISC for security event exchange and lifecycle/risk signaling. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/authorization-relationships/cedar-principal-action-resource-context.md b/research/authorization-relationships/cedar-principal-action-resource-context.md new file mode 100644 index 0000000..974af9e --- /dev/null +++ b/research/authorization-relationships/cedar-principal-action-resource-context.md @@ -0,0 +1,50 @@ +# Cedar Principal Action Resource Context + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +Cedar principal-action-resource-context model and policy terminology. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/authorization-relationships/cerbos-abac-derived-roles.md b/research/authorization-relationships/cerbos-abac-derived-roles.md new file mode 100644 index 0000000..3bdb873 --- /dev/null +++ b/research/authorization-relationships/cerbos-abac-derived-roles.md @@ -0,0 +1,50 @@ +# Cerbos Abac Derived Roles + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +Cerbos ABAC/RBAC policy concepts, derived roles, resources, principals, and conditions. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/authorization-relationships/openfga-modeling.md b/research/authorization-relationships/openfga-modeling.md new file mode 100644 index 0000000..1db6682 --- /dev/null +++ b/research/authorization-relationships/openfga-modeling.md @@ -0,0 +1,50 @@ +# Openfga Modeling + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +OpenFGA authorization models, relationship tuples, users, objects, and relations. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/authorization-relationships/zanzibar-rebac.md b/research/authorization-relationships/zanzibar-rebac.md new file mode 100644 index 0000000..a32a1e6 --- /dev/null +++ b/research/authorization-relationships/zanzibar-rebac.md @@ -0,0 +1,50 @@ +# Zanzibar Rebac + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +Google Zanzibar-style relationship-based authorization concepts. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md b/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md new file mode 100644 index 0000000..e861ff7 --- /dev/null +++ b/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md @@ -0,0 +1,50 @@ +# Deterministic Vs Probabilistic Matching + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +Deterministic and probabilistic matching patterns for entity resolution and identity linking. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/entity-resolution-privacy/gdpr-pseudonymization.md b/research/entity-resolution-privacy/gdpr-pseudonymization.md new file mode 100644 index 0000000..00e2bc4 --- /dev/null +++ b/research/entity-resolution-privacy/gdpr-pseudonymization.md @@ -0,0 +1,50 @@ +# Gdpr Pseudonymization + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +GDPR-relevant pseudonymization, anonymization, data minimization, and identity linkage considerations. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/entity-resolution-privacy/synonymity-assertions.md b/research/entity-resolution-privacy/synonymity-assertions.md new file mode 100644 index 0000000..602390c --- /dev/null +++ b/research/entity-resolution-privacy/synonymity-assertions.md @@ -0,0 +1,50 @@ +# Synonymity Assertions + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +Weak, strong, scoped, operational, legal, and privacy-preserving synonymity assertions. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/identity-provisioning/keycloak-organizations.md b/research/identity-provisioning/keycloak-organizations.md new file mode 100644 index 0000000..81d40df --- /dev/null +++ b/research/identity-provisioning/keycloak-organizations.md @@ -0,0 +1,50 @@ +# Keycloak Organizations + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +Keycloak organizations, realms, groups, roles, clients, and B2B/B2B2C organization management terminology. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md b/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md new file mode 100644 index 0000000..721e702 --- /dev/null +++ b/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md @@ -0,0 +1,50 @@ +# Ldap Rfc4519 Inetorgperson Rfc2798 + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +LDAP directory schema, RFC 4519 attribute/object class vocabulary, and inetOrgPerson RFC 2798. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/identity-provisioning/ory-kratos-keto.md b/research/identity-provisioning/ory-kratos-keto.md new file mode 100644 index 0000000..3f5ff42 --- /dev/null +++ b/research/identity-provisioning/ory-kratos-keto.md @@ -0,0 +1,50 @@ +# Ory Kratos Keto + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +Ory Kratos identity/user management and Ory Keto relationship-based authorization separation. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/identity-provisioning/scim-rfc7643-rfc7644.md b/research/identity-provisioning/scim-rfc7643-rfc7644.md new file mode 100644 index 0000000..e9aea0f --- /dev/null +++ b/research/identity-provisioning/scim-rfc7643-rfc7644.md @@ -0,0 +1,50 @@ +# Scim Rfc7643 Rfc7644 + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +SCIM 2.0: RFC 7643 schema and RFC 7644 protocol. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/identity-provisioning/zitadel-organizations-projects.md b/research/identity-provisioning/zitadel-organizations-projects.md new file mode 100644 index 0000000..5744377 --- /dev/null +++ b/research/identity-provisioning/zitadel-organizations-projects.md @@ -0,0 +1,50 @@ +# Zitadel Organizations Projects + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +ZITADEL organizations, projects, roles, grants, and multi-tenancy concepts. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/social-community-graphs/activitypub-actors-followers.md b/research/social-community-graphs/activitypub-actors-followers.md new file mode 100644 index 0000000..ee23ca6 --- /dev/null +++ b/research/social-community-graphs/activitypub-actors-followers.md @@ -0,0 +1,50 @@ +# Activitypub Actors Followers + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +ActivityPub actors, inboxes, outboxes, followers, following, federation, and social identities. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md b/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md new file mode 100644 index 0000000..d008d9c --- /dev/null +++ b/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md @@ -0,0 +1,50 @@ +# Foaf Agent Person Group Onlineaccount + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +FOAF Agent, Person, Organization, Group, OnlineAccount, and social relationship vocabulary. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/social-community-graphs/schema-org-person-organization-membership.md b/research/social-community-graphs/schema-org-person-organization-membership.md new file mode 100644 index 0000000..63c2f3b --- /dev/null +++ b/research/social-community-graphs/schema-org-person-organization-membership.md @@ -0,0 +1,50 @@ +# Schema Org Person Organization Membership + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +Schema.org Person, Organization, memberOf, affiliation, and public entity metadata. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/social-community-graphs/webid-solid-profile.md b/research/social-community-graphs/webid-solid-profile.md new file mode 100644 index 0000000..61f0f6f --- /dev/null +++ b/research/social-community-graphs/webid-solid-profile.md @@ -0,0 +1,50 @@ +# Webid Solid Profile + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +WebID and Solid profile concepts for decentralized/social identity and profile discovery. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/verifiable-claims/did-core.md b/research/verifiable-claims/did-core.md new file mode 100644 index 0000000..c650d70 --- /dev/null +++ b/research/verifiable-claims/did-core.md @@ -0,0 +1,50 @@ +# Did Core + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +W3C DID Core: decentralized identifiers, DID subjects, DID controllers, verification methods, and services. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/verifiable-claims/openid4vc.md b/research/verifiable-claims/openid4vc.md new file mode 100644 index 0000000..93a4d40 --- /dev/null +++ b/research/verifiable-claims/openid4vc.md @@ -0,0 +1,50 @@ +# Openid4Vc + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +OpenID for Verifiable Credentials concepts and identity/federation implications. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes. diff --git a/research/verifiable-claims/vc-data-model-2.md b/research/verifiable-claims/vc-data-model-2.md new file mode 100644 index 0000000..051bd35 --- /dev/null +++ b/research/verifiable-claims/vc-data-model-2.md @@ -0,0 +1,50 @@ +# Vc Data Model 2 + +## Source Type + +TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference. + +## Domain + +TODO: Classify the source domain. + +## Why This Source Matters + +W3C Verifiable Credentials Data Model 2.0: issuer, holder, subject, verifier, claims, presentations. + +## Key Concepts + +TODO: +- concept 1 +- concept 2 +- concept 3 + +## Relevant Terminology + +TODO: Extract terms used by the source and note their source-specific meaning. + +## Modeling Assumptions + +TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials. + +## Identity-Canon Implications + +TODO: Explain what this source suggests for the canonical identity model. + +## Terminology Conflicts + +TODO: Record where this source uses terms differently from other sources. + +## Candidate Canonical Mappings + +TODO: Map source-specific concepts to identity-canon candidate concepts. + +## Open Questions + +TODO: +- Question 1 +- Question 2 + +## References + +TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.