coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/infospace/assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md
tegwick 372f671eef
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Distribute frozen federation corpus by concept destination 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
2026-09-06 00:44:37 +02:00

5.8 KiB
Raw Blame History

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@subject assertion for ReBAC checks.
  • Namespace (Keto): typed object class in the authorization model with defined relations and permissions.
  • Subject (Keto): entity in a relation tuple; may reference a Kratos identity or arbitrary identifier.
  • Permission check: evaluate whether a subject has a relation to an object in a namespace.

Relevant Terminology

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