generated from coulomb/repo-seed
tegwick
1c1b5c9bc6
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.
5.8 KiB
5.8 KiB
Ory Kratos and Keto
Source Type
Product documentation and open-source implementation reference for Ory Kratos (identity management) and Ory Keto (relationship-based authorization).
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 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
- 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@subjectassertion 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
| 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
- 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
- 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
- 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
| 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
- 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
- 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