PermissionはActionとResourceを結び付けるApplication側の認可語彙
Permissionを単なるrole名やHTTP scopeではなく、あるResourceに対してあるActionを実行できるかというApplication側の語彙として置くと、Transportから認可を切り離しやすい。
Cedarのauthorization requestはPrincipal / Action / Resource / Contextを明示的に受け取り、policyはその組み合わせを評価する。SpiceDBではrelationからcomputed setとしてpermissionを定義できる。OpenFGAもuser・relation・objectの関係をmodel化してCheckを行う。表現は異なるが、いずれも「routeに入れたから許可」ではなく、ResourceとActionの意味を独立して扱う。
例えば project.read、project.archive、document.share のようなPermissionをApplication Operationに対応させれば、RESTでもMCPでも同じ業務認可を使える。HTTPのOAuth scopeやMCPのscope challengeは、そのPermissionへ到達するためのTransport-level credentialと分けて考えられる。
ただしPermissionを resourceType + verb の機械的直積として大量生成するとDomain semanticsが薄くなる。approve_invoice、publish_release のように業務上意味のあるActionを使う方がpolicyの意図を表しやすい。またSpiceDBのrelationとpermissionは別概念であり、保存された関係と計算される権限を混同しない方がよい。
PARCは認可問い合わせをPrincipal / Action / Resource / Contextへ分解する、Typed Permissionは不正なActionとResourceの組み合わせを設計時に減らす、Domain AuthorizationはOperationが具体Resourceへ作用してよいかを判定する がこのモデルを詳しく扱う。