FEP-ae97: クライアントサイドにおける活動署名機能

概要

既存のFediverseサーバーでは、ユーザーに代わって署名鍵を管理しています。本提案では、ユーザーが自身の鍵を用いて活動に署名できる新たなタイプの[ActivityPub][ActivityPub]クライアントと、クライアントが署名した活動を他のサーバーへ配布可能なサーバーアーキテクチャについて記述します。

経緯

この提案の初期バージョン（https://codeberg.org/fediverse/fep/src/commit/fc9c65daca267be9f91761ed854eac9e829222a2/fep/ae97/fep-ae97.md）は、[FEP-c390]のアイデンティティ証明方式を用いて暗号学的な識別子とアクターオブジェクトを紐付ける仕組みに依存していました。この手法は後に[FEP-ef61]によって置き換えられ、完全なデータポータビリティが実現されました。

要件

本文書中で使用される「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」の各用語は、[RFC-2119][RFC-2119]で規定された解釈に従うものとします。

発見機構

署名鍵を管理可能なクライアントをサポートするサーバーは、/.well-known/apgatewayパスにディスカバリエンドポイントを設置しなければなりません。

このエンドポイントに対してHTTP GETリクエストが送信された場合、サーバーは自身に関する情報を含むJSONオブジェクトを返す必要があります。当該オブジェクトは空であっても構いません。

例:

{
  "uploadMedia": "https://gateway.example/.well-known/apgateway-media"
}

アクターの登録

クライアントは[FEP-ef61]に準拠したポータブルなアクターオブジェクトを作成し、保存します。ポータブルアクターが作成される際、クライアントは以下の処理を実施しなければなりません: 1. リクエスト署名用の鍵（メインアクターキー）を生成する 2. [FEP-521a]で規定されている通り、assertionMethod配列にこの鍵のMultikey表現を追加する当該鍵の識別子は[互換性のある識別子][CompatibleIdentifiers]であってはなりません。

サーバーへポータブルアクターを登録する前に、クライアントは必ずアクターオブジェクトのgateways配列にサーバーURLを追加しなければなりません。

アクター登録を行うため、クライアントは/.well-known/apgatewayパスのゲートウェイエンドポイントに対してHTTP POSTリクエストを送信します。リクエストボディにはアクターオブジェクトを含める必要があります。

サーバーは登録要求に制限を設けることが推奨されます（例えば招待コードの取得を必須とするなど）。サーバーが登録要求を受理した場合、RSA鍵を生成して応答として返します。この応答は必ず201 Createdステータスコードを持つものとします。レスポンス本文は、[Multikey][CI-Multikey]形式で生成されたRSA公開鍵を含むJSONオブジェクトとします。

例:

{
  "assertionMethod": [
    {
      "type": "Multikey",
      "publicKeyMultibase": "z4MXj1wBzi9jUstyPMS4jQqB6KdJaiatPkAtVtGc6bQEQEEsKTic4G7Rou3iBf9vPmT5dbkm9qsZsuVNjq8HCuW1w24nhBFGkRE4cd2Uf2tfrB3N7h4mnyPp1BF3ZttHTYv3DLUPi1zMdkULiow3M1GfXkoC6DoxDUm1jmN6GBj22SjVsr6dxezRVQc7aj9TxE7JLbMH1wh5X3kA58H3DFW8rnYMakFGbca5CB2Jf6CnGQZmL7o5uJAdTwXfy2iiiyPxXEGerMhHwhjTA1mKYobyk2CpeEcmvynADfNZ5MBvcCS7m3XkFCMNUYBS9NQ3fze6vMSUPsNa6GVYmKx2x6JrdEjCk3qRMMmyjnjCMfR4pXbRMZa3i"
    }
  ]
}

サーバーがアクターの登録を行えない場合、必ず400 Bad Requestステータスコードを返すものとします。

登録が正常に完了した場合、クライアントはRSA鍵をアクターオブジェクトにpublicKeyプロパティとして付加し、さらに[FEP-521a]で規定されている通りassertionMethod配列にも追加しなければなりません。サーバーの応答に他の鍵が含まれている場合も、同様にassertionMethod配列に追加する必要があります。

クライアントが[互換性のある識別子][CompatibleIdentifiers]を使用する場合、鍵の識別子は必ずサーバーの[origin][Origin]を用いて生成されなければなりません。

アクターオブジェクトを更新した後、クライアントは当該アクターに対してUpdate活動を公開しなければなりません。

活動の送信

クライアントは、署名済みの[FEP-ef61]形式の活動をアクターのアウトボックスへ送信します。ActivityPub仕様書の[6. Client to Server Interactions]セクション（https://www.w3.org/TR/activitypub/#client-to-server-interactions）で規定されている内容とは異なり、サーバーは活動のIDを上書きしてはなりません。代わりに新規IDを付与するのではなく、提供されたIDが過去に使用されていないことを検証する必要があります。サーバーが当該活動を受け付けた場合、その応答は必ず202 Acceptedステータスコードを持つものとします。

活動にラップドオブジェクト（CreateおよびUpdate活動に含まれるもの）が含まれる場合、これは[FEP-ef61]に準拠して作成されたポータブルオブジェクトでなければなりません。サーバーは活動IDと同様に、オブジェクトIDについても検証を行う必要があります。

サーバーは、内容を改変することなく適切な受信者へ確実に活動を配信しなければなりません。HTTPリクエストに署名する際、サーバーは登録時に生成したRSA鍵を使用するものとします。

アウトボックスの所有者が未登録の場合、サーバーは必ず404 Not Foundステータスコードを返すものとします。

送信された活動のアクターがアウトボックス所有者と異なる場合、サーバーは必ず403 Forbiddenステータスコードを返すものとします。

著作権情報

本Fediverse拡張提案の著者は、法律で認められる範囲内において、当該著作物に関するすべての著作権および関連権利を放棄しています。これはパブリックドメインへの献呈を意味するものです。