@xemahq/contracts 0.76.0 → 0.78.0

package/dist/authorization-module/platform/xema_core.fga

@@ -43,6 +43,16 @@ module xema_core
 # originate a durable delegation whose authority OWNER is this subject?". It
 # grants no capability, scope or holder. These are the zero-configuration
 # defaults; a biome can never extend a platform type, so nothing widens them.
+#
+# Who may originate over an ANCHOR (`deriveDelegationOriginationChecks`,
+# `@xemahq/contracts/authzen`, the one derivation every consumer uses):
+# "Originating a delegation for an anchor requires `originate` on the anchor.
+# When the anchor's `owner` is a USER, it ALSO requires `may_delegate_for` on
+# that user for the initiator (by default `is_self`: the initiator IS the
+# owner; a deployment may only tighten it). An org admin or a configurer cannot
+# originate over a user-owned anchor. When the owner is the ORG, `originate`
+# alone admits: the authority lent is the org's, the initiator only originates
+# and is recorded as `authorisedBy`."
 type user
   relations
     define is_self: [user]
@@ -54,10 +64,11 @@ type app
 type external-subject
 
 # An ORGANIZATION as a DELEGATOR — never a member of anything, never granted
-# anything. It appears only as the OWNER of an org-owned session, which derives
-# no human rights: no relation evaluates `owner` for a user, and an org-owned
-# session has no `parent` to inherit from. Access to such a session is by the
-# delegation it is bound to, checked by the service that owns it.
+# anything. It appears only as the OWNER of an org-owned session: no relation
+# evaluates `owner` for a user, and acting in such a session is by the
+# delegation it is bound to, checked by the service that owns it. Its
+# MANAGEMENT follows the owning space: the org's admins, through the
+# session's `owner_org` (see `xema_session`).
 type organization
 
 type org
@@ -86,13 +97,26 @@ type role
     define parent: [org]
     define assignee: [user, agent, service, app, team#member]
 
+# A MEMBERSHIP is one INSTANCE of a user's membership of an org, and is what a
+# human resource grant binds to (`membership#holder`), not the user and org.
+# Identity gives a NEW membership id on every join. The holder tuple
+# (`user:<u> holder membership:<o|m>`) is written on join and DELETED on leave;
+# a role change keeps the id and writes nothing. So a grant bound to a
+# membership ends with it and never revives on rejoin (a new id), while a
+# demotion keeps it. The object id is the org-qualified `org|membershipId`, so
+# org erasure enumerates it by org.
+type membership
+  relations
+    define parent: [org]
+    define holder: [user]
+
 type project
   relations
     define parent: [org, ${XEMA_PARENT_TYPES}]
-    define owner: [user, agent, service]
-    define admin: [user, agent, team#member, role#assignee]
-    define editor: [user, agent, team#member, role#assignee]
-    define viewer: [user, agent, team#member, role#assignee, org#member]
+    define owner: [membership#holder, agent, service]
+    define admin: [membership#holder, agent, team#member, role#assignee]
+    define editor: [membership#holder, agent, team#member, role#assignee]
+    define viewer: [membership#holder, agent, team#member, role#assignee, org#member]
     define xema_admin: owner or admin or xema_admin from parent
     define xema_write: editor or xema_admin or xema_write from parent
     define xema_read: viewer or xema_write or xema_read from parent
@@ -102,28 +126,53 @@ type project
 # the anchored object gains nothing — and it exists so the PDP's delegation
 # scope walk (which follows `parent` AND `anchor`) keeps the session and its
 # descendants inside the delegation's scope. An org-owned session writes
-# `owner` (organization) and `anchor`, and no `parent` and no `participant`.
+# `owner` (organization), `owner_org` and `anchor`, and no `parent` and no
+# `participant`.
+#
+# `parent` is the AUDIENCE the launcher stated (relation `parent`): its readers
+# READ the session (`xema_read from parent`) and nothing more. It is never the
+# owning space and never confers management.
+#
+# `owner_org` is the OWNING SPACE (owner rule 10-09: authority follows the
+# owning space). It is written ONLY for an org-owned session, never for a
+# user-owned one (a personal session gives org admins no implicit authority),
+# and the org's admins MANAGE the session through it (`admin from owner_org`):
+# read, write and administer, exactly what `owner` permits apart from acting.
+# Sessions have no team owner, so the relation admits `org` only.
 #
 # `can_act` is the human turn/interrupt permission (editor/owner). Human
 # session relations never confer workload execution authority; that requires
-# the session's verified launch delegation. It derives NOTHING from `parent`.
+# the session's verified launch delegation. It derives NOTHING from `parent`
+# or `owner_org`: an org admin manages an org-owned session but never acts as
+# it.
 #
-# Managing the session (`xema_write` / `xema_admin`) is the OWNER ONLY and
-# derives NOTHING from `parent`: a parent reader, a parent writer or an org
-# admin only READS the session (`xema_read from parent`); they neither act in
-# it nor manage it. A future admin "close a member's session" door needs an
-# explicit governance capability; inherited manage does not exist.
+# Managing the session (`xema_write` / `xema_admin`) is the owner, or the
+# owning org's admins for an org-owned session. It derives NOTHING from
+# `parent`: a parent reader, a parent writer or an org admin reaching it only
+# through the parent READS the session; they neither act in it nor manage it.
 # An `editor` is also a reader.
+#
+# `participant` and `editor` are org-scoped grants to a PERSON, so each admits
+# `membership#holder` (the person's membership instance) in place of `user`:
+# leaving ends the grant and a rejoin (a new membership id) never revives it; a
+# demotion keeps the id and so the grant. An agent stays an agent.
+#
+# `owner` admits BOTH person subjects, and the writer picks by the session's
+# OWNING SPACE: `user` ONLY for a PERSONAL session (its owning space is the
+# user), so the ownership is the user's own and survives the user leaving any
+# org; `membership#holder` for an org-scoped person grant, which goes inert on
+# leave and never revives on rejoin, like `participant` and `editor`.
 type xema_session
   relations
     define parent: [org, project, ${XEMA_PARENT_TYPES}]
     define anchor: [org, project, ${XEMA_PARENT_TYPES}]
-    define owner: [user, agent, organization]
-    define participant: [user, agent]
-    define editor: [user, agent]
-    define xema_admin: owner
-    define xema_write: owner
-    define xema_read: owner or participant or editor or xema_read from parent
+    define owner: [user, membership#holder, agent, organization]
+    define participant: [membership#holder, agent]
+    define editor: [membership#holder, agent]
+    define owner_org: [org]
+    define xema_admin: owner or admin from owner_org
+    define xema_write: owner or admin from owner_org
+    define xema_read: owner or participant or editor or xema_read from parent or admin from owner_org
     define can_read: xema_read
     define can_write: xema_write
     define can_act: owner or editor
@@ -131,34 +180,16 @@ type xema_session
 type xema_artifact
   relations
     define parent: [org, project, xema_session, ${XEMA_PARENT_TYPES}]
-    define owner: [user, agent, service]
+    define owner: [membership#holder, agent, service]
     define can_delete: owner or xema_admin from parent
     define can_write: owner or xema_write from parent
     define can_read: owner or can_write or xema_read from parent
     define xema_read: can_read
 
-# ── Durable delegation: integrations and the scopes bound to them ──────────
-#
-# Generic plumbing, not a business noun. An integration INSTANCE (a
-# connection's sync, a mailbox intake, a scheduled workflow) is the thing a
-# durable delegation is created FOR; its owning service writes these facts:
-#
-#   parent       — the org it belongs to;
-#   active       — `xema_integration:<o>|<id>#active@org:<o>`, present iff the
-#                  integration is ACTIVE (removed BEFORE a disable commits);
-#   holder       — the workload declared as its executor;
-#   bound_scope  — each opaque scope (`xema_scope`) it is bound to;
-#   configurer   — who may configure it, beside the org's administrators.
+# ── Durable delegation: the opaque scopes a delegation anchor binds ───────
 #
-# A delegation is usable only while these facts hold; the PDP re-checks them
-# at every use and reads no stored verdict.
+# Generic plumbing, not a business noun. A biome declares its own delegation
+# ANCHOR type (implementing `xema.delegation-anchor`) and binds each opaque
+# scope ref to it through `bound_scope: [xema_scope]`; this type is that
+# subject.
 type xema_scope
-
-type xema_integration
-  relations
-    define parent: [org]
-    define active: [org]
-    define holder: [service]
-    define bound_scope: [xema_scope]
-    define configurer: [user, team#member]
-    define configure: configurer or admin from parent