PARCは認可問い合わせをPrincipal / Action / Resource / Contextへ分解する
Cedarはauthorization requestを Principal / Action / Resource / Context (PARC) の4要素として明示する。これはWeb Applicationの認可をrouteやhandler名から切り離して考えるための便利な座標系になる。
- Principal: 誰が要求しているか
- Action: 何をしようとしているか
- Resource: 何に対して行うか
- Context: そのrequest固有の条件は何か
CedarではP/A/Rはentity referenceで、Contextはrecordである。さらにbest practiceでは、PrincipalやResourceに属する情報をContextへ押し込まず、Contextは時刻、IP、authentication posture、request parameterなどrequest時点の情報に使うよう推奨している。
Application Operationを ArchiveProject とした場合、REST handlerでもMCP Toolでも、最終的な業務認可を principal=P, action=ArchiveProject, resource=Project:123, context=C という同じ問い合わせへ落とせる。この意味でPARCはTransport-independent authorization interfaceの候補になる。既存ノート Cedar の PARC は resource を認可問い合わせの一級要素にする もこの点を扱っている。
ただしPARCはAuthorization Graphのdata modelそのものではない。OpenFGAやSpiceDBのrelationship graphは「PとRの間にどんな関係があるか」を解決するための構造であり、PARCは「今回何を問い合わせるか」の形である。Authorization GraphはResource Hierarchyとは別のRelationship Graphとして持つ ではこの差を分ける。
またContextを万能bagにすると再び境界が崩れる。Transport-specific情報とDomain-specific条件のどちらがContextに必要かは、policyのownershipと監査可能性を考えて絞るべきである。