Resource HierarchyはOwnershipやScopingを表せるが万能の認可Treeではない
Resource Hierarchyは、Organization → Project → Document のようにDomain Resourceの包含・ownership・scopeを表す構造である。Google AIP-121/122はResourceの関係と階層をAPI設計の基本要素とし、child resourceのnameにparentを含める規約を持つ。
この階層は認可にも有用である。Projectのmemberなら配下Documentを読める、Tenant adminなら配下Resourceを管理できる、といった継承を表しやすい。既存ノート パス階層を認可階層として使う のようにHTTP pathと一致する場合はResource Resolutionも効率化できる。
しかし Resource HierarchyとAuthorization Graphは同一ではない。DocumentがFolder配下にあっても、共有link、Team membership、delegation、cross-project relationなどの権限はtreeの外側を横断する。OpenFGAもentity hierarchyをapplication DBに置くことが適切な場合を明示し、fine-grained permission relationとはsource of truthを分けることを勧めている。
したがってResource Hierarchyは主に次の用途へ限定すると扱いやすい。
- canonical identityのscope
- ownership / lifecycle上のparent-child
- Create/Listのscope
- query narrowingのヒント
認可継承に使う場合も、それを唯一のpermission modelにしない方がよい。Authorization GraphはResource Hierarchyとは別のRelationship Graphとして持つ はrelationship-based authorizationを別構造として扱う。
また、Resource nameにparentを埋め込む設計は移動・reparentingとの相性が悪い場合がある。Domain上のlifecycleとidentity stabilityを優先し、階層をnameへ含めるかは個別に判断すべきである。