Design: effective authorization context shape across DAW module/application boundaries #12

New issue

Open

opened 2026-09-22 14:49:36 +02:00 by michael · 0 comments

michael commented

2026-09-22 14:49:36 +02:00

Owner

Goal

Define how an effective authorization context is represented and
passed across DAW module/application boundaries -- design only, no
schema, no implementation yet.

Why

Multiple consumers will need to enforce the same kind of boundary:
berhtjan-core (filtering discovered modules and composed fields, see
DAW/daw-modul-berhtjan-core#15), Anagild (query-level
visibility), MCP access, and applications such as Steurjan. If each of
these invents its own ctx.roles / ctx.permissions / ctx.scopes shape
independently, we end up with five incompatible authorization models
before any of them is actually validated against real use.

Starting point (session insight, finding-01)

Daten besitzen neben Inhalt und Beziehungen einen Geltungs- und
Sichtbarkeitskontext. Die Bestätigung eines Datums bedeutet nicht,
dass es global verfügbar wird. Freigaben bestimmen, für welche
Verantwortungen bzw. Systeme ein Datum gelten darf; Rollen und
Gruppen bestimmen, welche Identitäten innerhalb dieses Geltungsraums
darauf zugreifen dürfen. Diese Beschränkungen gelten auch für
Abfragen über Anagild und müssen indirekte Informationslecks über
Beziehungen oder deren Existenz verhindern.

The consequence for this issue: a consumer such as berhtjan-core
should only ever need to ask for the effective authorization for a
given object/field in a given usage context. It should not need to
know whether that effective authorization was derived from a role, a
group, an individual grant, a purpose/scope, or the calling
application. Roles are one possible input to that derivation, not the
shape of the contract itself.

Identity
    |
    +-- roles / groups
    +-- individual grants
    +-- application / purpose
    +-- context (if any)
             |
             v
    effective permissions
             |
             v
      consumer's ctx  (berhtjan-core, Anagild, MCP, ...)

Explicit non-goals for this issue

No daw_authorization_context/v1 schema yet.
No decision on which application or service computes the effective
permissions (this issue does not assign that responsibility to
Steurjan or any other single application -- see discussion: an
application-owned model would become a wrong dependency once
Kaupapi, Anagild, Langan, MCP etc. need the same rules).
No implementation in any consuming repo.

Scope

Gather real requirements from at least berhtjan-core's two entry
points (module-level, field-level) before proposing a shape.
Sketch candidate shapes for "effective authorization context" once
enough real cases exist (this issue can stay open across several
DAW/daw-modul-berhtjan-core sessions while that happens).
Identify which other repos/consumers need the same contract early
(Anagild, MCP surfaces) so the shape isn't fitted to berhtjan-core
alone.

Acceptance criteria

Requirements collected from at least one real consumer
(berhtjan-core's discovery/compose filtering)
A candidate shape for the effective authorization context is
sketched (not yet a numbered contract version)
Explicitly does not assume permissions originate solely from
roles
No application (Steurjan or otherwise) is assigned ownership of
the permission model

DAW/daw-modul-berhtjan-core#15 (first concrete consumer)

## Goal Define how an effective authorization context is represented and passed across DAW module/application boundaries -- design only, no schema, no implementation yet. ## Why Multiple consumers will need to enforce the same kind of boundary: berhtjan-core (filtering discovered modules and composed fields, see DAW/daw-modul-berhtjan-core#15), Anagild (query-level visibility), MCP access, and applications such as Steurjan. If each of these invents its own ctx.roles / ctx.permissions / ctx.scopes shape independently, we end up with five incompatible authorization models before any of them is actually validated against real use. ## Starting point (session insight, finding-01) > Daten besitzen neben Inhalt und Beziehungen einen Geltungs- und > Sichtbarkeitskontext. Die Bestätigung eines Datums bedeutet nicht, > dass es global verfügbar wird. Freigaben bestimmen, für welche > Verantwortungen bzw. Systeme ein Datum gelten darf; Rollen und > Gruppen bestimmen, welche Identitäten innerhalb dieses Geltungsraums > darauf zugreifen dürfen. Diese Beschränkungen gelten auch für > Abfragen über Anagild und müssen indirekte Informationslecks über > Beziehungen oder deren Existenz verhindern. The consequence for this issue: a consumer such as berhtjan-core should only ever need to ask for the *effective* authorization for a given object/field in a given usage context. It should not need to know whether that effective authorization was derived from a role, a group, an individual grant, a purpose/scope, or the calling application. Roles are one possible input to that derivation, not the shape of the contract itself. Identity | +-- roles / groups +-- individual grants +-- application / purpose +-- context (if any) | v effective permissions | v consumer's ctx (berhtjan-core, Anagild, MCP, ...) ## Explicit non-goals for this issue - No daw_authorization_context/v1 schema yet. - No decision on which application or service computes the effective permissions (this issue does not assign that responsibility to Steurjan or any other single application -- see discussion: an application-owned model would become a wrong dependency once Kaupapi, Anagild, Langan, MCP etc. need the same rules). - No implementation in any consuming repo. ## Scope - Gather real requirements from at least berhtjan-core's two entry points (module-level, field-level) before proposing a shape. - Sketch candidate shapes for "effective authorization context" once enough real cases exist (this issue can stay open across several DAW/daw-modul-berhtjan-core sessions while that happens). - Identify which other repos/consumers need the same contract early (Anagild, MCP surfaces) so the shape isn't fitted to berhtjan-core alone. ## Acceptance criteria - [ ] Requirements collected from at least one real consumer (berhtjan-core's discovery/compose filtering) - [ ] A candidate shape for the effective authorization context is sketched (not yet a numbered contract version) - [ ] Explicitly does not assume permissions originate solely from roles - [ ] No application (Steurjan or otherwise) is assigned ownership of the permission model ## Related DAW/daw-modul-berhtjan-core#15 (first concrete consumer)

michael added the

coordination/cross-repo

labels

2026-09-22 14:49:36 +02:00