Typed Permissionは不正なActionとResourceの組み合わせを設計時に減らす
Permissionを文字列だけで扱うと、Can(user, "archive", documentID) のように、そのActionがそのResource typeへ適用可能かをcall siteだけでは判断しにくい。Typed Permission は、ActionがどのPrincipal/Resource typeへ適用できるかをschemaまたは型で表す考え方である。
Cedar schemaのActionは appliesTo にPrincipal type、Resource type、Context shapeを宣言できる。例えば ViewDocument は User と Document にだけ適用する、とvalidation可能である。Goa-AIもTool identityとpayload/result schemaを生成し、ad-hocなstring identifierよりtyped identifierを推奨している。認可そのものではないが、「Capability catalogを型付きで機械可読にする」実例として参考になる。
Application内でも、概念的には次のように表せる。
ArchiveProject : Permission<Project>
ViewDocument : Permission<Document>
この型情報がOperation catalogと結び付けば、Transport adapterはOperationに必要なPermissionを機械的に知ることもできる。
ただし型安全化はpolicy semanticsの正しさを保証しない。ArchiveProject が Project に適用できると型検査できても、「誰に許可するか」は別問題である。またすべてのContext依存条件を静的型へ押し込むと型が肥大化する。Typed Permissionは適用可能性と識別子の誤りを減らす仕組みであり、authorizerの代替ではない。
PermissionはActionとResourceを結び付けるApplication側の認可語彙 と Application CatalogはArchitectureをAIとToolが読めるMachine-readable Dataにする を組み合わせると、Permissionを単なる定数一覧ではなくArchitecture metadataとして扱える。