Authorization GraphはResource Hierarchyとは別のRelationship Graphとして持つ
Relationship-based authorizationでは、権限はResource treeそのものではなく、User・Team・Organization・Resourceなどの間の関係を辿って計算される。OpenFGAはuser / relation / objectのrelationship tupleを基本要素とし、SpiceDBはrelationとcomputed permissionをschemaで定義する。
例えばDocumentがProjectに所属するというResource Hierarchyとは別に、次のような関係が存在しうる。
user ─member→ team ─editor→ document
user ─viewer──────────→ document
organization ─parent→ project
この構造ではpermission evaluationはgraph traversalになる。SpiceDBの説明でもCheckPermissionはresourceからschemaとrelationshipsを辿ってsubjectを探索する。既存ノート Zanzibar / OpenFGA は認可関係をデータとして表す も、この「認可関係をapplication codeではなくdata modelとして持つ」考え方を扱っている。
重要なのは、Authorization GraphをDomain Resource Hierarchyのコピーにしないことだ。OpenFGAはentity hierarchyや検索用metadataをApplication DBへ残すべきケースを明示している。Graphへ何でも入れると、Domain queryとauthorization queryが二重管理になりやすい。
逆に、共有・membership・delegationなど「権限そのものとして意味がある関係」はgraph化する価値が高い。Resource Hierarchyはownership/lifecycleを、Authorization Graphはauthority propagationを表す、と役割を分けると理解しやすい。
Resource HierarchyはOwnershipやScopingを表せるが万能の認可Treeではない と Generic Resourceへ寄せすぎるとDomain Semanticsが失われる は、この分離をDomain modeling側から補足する。