Create Authorizationは存在しないResourceではなくParentやCreation Intentを認可する
既存ResourceへのRead/Update/Deleteは Can(principal, action, resource) と表しやすい。しかしCreateでは、対象Resourceはまだ存在しない。ここで「作成後のResourceを先に組み立ててCanする」だけでは、ID採番、parent ownership、入力値によるpolicyなどの意味が曖昧になる。
Google AIP-133のCreateは、top-level resourceでない限り parent を明示し、「既存collectionの中へ新しいResourceを作る」Operationとして定義する。Cedarのauthorization patternsもresource creationを独立パターンとして扱い、例として POST /tenants/:id/campaigns ではprincipal sliceとtenant sliceを使う。
したがってCreate Authorizationは、典型的には次のどれか、または組み合わせになる。
CanCreate(principal, ResourceType, parent, input/context)
Can(principal, CreateChild, parent)
つまり認可対象は「まだないResource」ではなく、どのParent scopeに、どの種類のResourceを、どの条件で作れるかである。user-specified IDがある場合は、存在確認から情報漏洩が起きないようエラー semanticsにも注意が必要で、AIP-133は見えないduplicate resourceに対して PERMISSION_DENIED を返すよう規定している。
ただしすべてのCreateにParentがあるわけではない。top-level resource、signup、import、stateless operationなどはsynthetic application resourceや別のscopeで表す方が自然なこともある。Createを無理に「未来のResourceへの通常Can」と同型にする必要はない。
Resource HierarchyはOwnershipやScopingを表せるが万能の認可Treeではない と PermissionはActionとResourceを結び付けるApplication側の認可語彙 に接続する論点である。