要約

  • RFC 5397 の DAV:current-user-principal は保護された要求単位のプロパティで、一つの HTTP(S) 主体リソース URL または未認証の疑似主体を返す。
  • 主体には複数の表現があり得る。選ばれた URL は追加照会の入口であって、唯一の人物識別子でも権限付与でもない。
  • 運用証跡は、認証、主体選択、表現の一貫性、主体リソース到達、ホーム発見、権限評価、操作、利用者結果を分ける必要がある。

保存されたものと計算されたもの

WebDAV ACL を定めた RFC 3744 は、利用者やグループを主体リソースとして表し、ACL と権限を扱う仕組みを与えた。現在の利用者に許された操作を問い合わせるプロパティもあった。しかし、認証直後のクライアントが「この利用者を表す主体リソースはどれか」を直接知る推奨手段は欠けていた。

DAV:principal-match による探索は集合を返し得る。本人だけでなく、本人を含むグループも一致するためだ。関係を調べるには正しい応答でも、設定を始める一点としては曖昧である。

RFC 5397 は DAV:current-user-principal を加えた。値は一つの DAV:href または DAV:unauthenticated である。href は HTTP(S) で、主体リソース自身が宣言する主体 URL または代替 URI の一つでなければならない。クライアントはその入口からグループ、別名、カレンダーやアドレス帳のホームを調べる。

ここで得られるのは探索の方向である。対象コレクションへの書き込み権限や同期の完了はまだ決まっていない。

COPY と MOVE が運ばない理由

このプロパティはサーバーが保護し、要求ごとに計算する。したがって COPY や MOVE の対象にならない。文書を移した主体は履歴上重要かもしれないが、「現在この文書を読む主体」と同じ概念ではない。

移行ツールが計算値を静的メタデータとして保存すれば、古い要求の利用者が新しい環境の文書に貼り付く。後の閲覧者に返す値は、その閲覧要求の認証状態から再計算されるべきである。

この境界は監査ログにも必要だ。操作主体を記録する監査イベントと、現在主体を発見する WebDAV プロパティは用途が違う。一方を他方の代用にすると、過去の行為者と現在の閲覧者が混ざる。

一つの URL は一つの人を固定しない

複数 URL が同じ主体リソースを示すことも、一人の認証主体に複数の主体リソースが対応することもある。サーバーは有効な候補から一つを選べるが、同じ主体には一貫した URI を使うことが推奨される。

この仕様は URL を世界共通の人物キーにしない。サービスの権威、認証文脈、時刻とともに記録して初めて意味が限定される。ディレクトリ再編で URL が変わっても人物は変わらない場合がある。別サービスで同じパスが現れても人物が同じとは限らない。

表現を統合するには、サーバーが示す代替 URI などの権威ある証拠が必要である。文字列の近さ、自動転送、同時ログインだけでは履歴を結合してはならない。

一貫性の変化は監視対象だが、直ちに侵害を意味しない。移行、負荷分散、マッピング不良など複数の説明がある。監視は問いを開き、証拠が揃う前に主体を複製・統合しない。

未認証を以前の利用者で埋めない

認証が行われていないか失敗した場合、値は DAV:unauthenticated でなければならない。これは欠損値ではなく、要求の状態を示す明示的な結果である。

クライアントが最後に成功した主体 URL を再利用すれば、画面は滑らかでも行為の帰属が誤る。ユーザー名から URL を組み立てる場合も、サーバーの判断を命名規則で置き換えてしまう。

RFC 6764 は、このプロパティを取得する PROPFIND に認証を強制するようサービス提供者へ求める。プロパティが返らなければ、クライアントは利用者に主体パスを尋ねることがある。返らないことは別経路を必要とする状態であって、推測の許可ではない。

キャッシュには再発見条件がある

CalDAV/CardDAV の設定では、サービスを見つけ、TLS を確認し、認証し、現在主体を取得し、そのリソースからホームコレクションを発見する。RFC 6764 は成功したサービス情報と主体 URL のキャッシュを認める。

同時に、接続や認証が継続して失敗するなら SRV 検索とアカウント発見をやり直すよう求める。キャッシュは権威の移転ではない。いつ、どの認証で得たかと、どの失敗が再発見を起動するかを持つ必要がある。

固定 URL に依存する実装は一時的に速くても、サービス移動や表現変更でロックインを生む。再発見を通常系として試験すれば、変更は障害ではなく管理された遷移になる。

主体を見つけても ACL は残る

現在主体プロパティは「どこから詳しく調べるか」を答える。RFC 3744 の現在利用者権限集合は、特定リソースで許される操作を答える。後者は対象ごとに変わる。

主体リソースを読めても、カレンダーへ書けないことがある。グループ所属があっても、すべてのアドレス帳を変更できるわけではない。書き込み権限があっても、ETag の条件や競合で操作は失敗し得る。

したがって成功の鎖は、サービス、認証、主体、ホーム、対象、権限、HTTP 操作、最終状態へ進む。RFC 5397 は本人確認後の入口を標準化したのであって、残りの判断を省略してはいない。