FEP-8b32: オブジェクトの完全性証明
Warning
このFEPはgemini-2.5-flash
を利用して2025年08月16日 23時14分
に翻訳されました。オリジナルのFEPはここから閲覧できます。
概要
この提案は、ActivityPubサーバーとクライアントが自己認証可能なアクティビティとオブジェクトを作成する方法を記述します。
HTTP署名(HTTP signatures)は、サーバー間インタラクションにおける認証によく使用されます。しかし、これは認証をアクティビティの配信に結びつけ、プロトコルの柔軟性を制限します。
完全性証明(Integrity proofs)は、デジタル署名とそれらを検証するために必要なパラメータを表す属性のセットです。これらの証明は任意のアクティビティまたはオブジェクトに追加でき、受信者がアクターの身元とデータの完全性を検証することを可能にします。これにより、認証がトランスポートから切り離され、アクティビティのリレー、埋め込みオブジェクト、クライアントサイド署名など、さまざまなプロトコルの改善が可能になります。
履歴
Mastodon は2017年以来Linked Data signaturesをサポートしており、その後他の多くのプラットフォームがそれらをサポートしました。これらの署名は完全性証明に似ていますが、他の標準に置き換えられた古いLinked Data Signatures 1.0仕様に基づいています。
要件
この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC-2119で記述されている通りに解釈されます。
完全性証明
提案される認証メカニズムは、Data Integrity仕様に基づいています。
証明の生成
証明は、Data Integrity仕様のセクション4.2 Add Proofに従って作成されなければなりません(MUST)。
証明の生成プロセスは、以下のステップで構成されます。
- 正規化(Canonicalization)は、JSONオブジェクトを、ある決定論的アルゴリズムに従ってハッシュ化に適した形式に変換することです。
- ハッシュ化(Hashing)は、暗号学的ハッシュ関数を使用して、変換されたデータに対する識別子を計算するプロセスです。
- 署名生成(Signature generation)は、入力データの完全性を改ざんから保護する値を計算するプロセスです。
結果として得られる証明は、元のJSONオブジェクトのproof
キーの下に追加されます。オブジェクトは複数の証明を含むことができます(MAY)。
完全性証明で使用される属性のリストは、Data Integrity仕様のセクション2.1 Proofsで定義されています。証明タイプは、セクション3.1 DataIntegrityProofで指定されているように、DataIntegrityProof
であるべきです(SHOULD)。proofPurpose
属性の値はassertionMethod
でなければなりません(MUST)。
証明のverificationMethod
属性の値は、公開鍵のHTTP(S) URLまたはDID URLであることができます。検証メソッドの識別子は、保護されたドキュメントの識別子と同一オリジンであるか、異なるオリジンであっても、保護されたドキュメントの識別子との間に確立されたクロスオリジントラスト関係を持っていなければなりません(MUST)。
検証メソッドが表現される制御識別子ドキュメントは、アクターオブジェクト、またはActivityPubアクターと証明可能に関連付けられる別のドキュメント(例:DIDドキュメント)でなければなりません(MUST)。検証メソッドは、制御識別子ドキュメントのassertionMethod
プロパティに関連付けられなければなりません(MUST)。制御識別子ドキュメントがアクターオブジェクトである場合、実装者はFEP-521aで記述されているassertionMethod
プロパティを使用すべきです(SHOULD)。
証明の検証
オブジェクトの受信者は、完全性証明が含まれている場合、証明の検証を実行すべきです(SHOULD)。検証プロセスは、Data Integrity仕様のセクション4.4 Verify Proofに従わなければなりません(MUST)。これは、JSONオブジェクトからproof
値を削除することから始まります。次に、Controlled Identifiers仕様のセクション3.3 Retrieve Verification Methodで記述されているように、制御識別子ドキュメントから検証メソッドが取得されます。その後、オブジェクトは正規化され、ハッシュ化され、証明で指定されたパラメータに従って署名検証が実行されます。
HTTP署名と完全性証明の両方が使用される場合、完全性証明はHTTP署名よりも優先されなければなりません(MUST)。HTTP署名は無視されることがあります(MAY)。
アルゴリズム
実装者は、完全性証明のためのアルゴリズムを選択する際に、広範な相互運用性を追求することが期待されます。
eddsa-jcs-2022暗号スイートが推奨されます(RECOMMENDED):
- 正規化(Canonicalization):JCS
- ハッシュ化(Hashing):SHA-256
- 署名:EdDSA
[!WARNING]
eddsa-jcs-2022
暗号スイートの仕様は安定しておらず、W3C勧告になる前に変更される可能性があります。
後方互換性
完全性証明とLinked Data signaturesは、それぞれ異なるプロパティ(proof
とsignature
)に依存しているため、一緒に使用できます。
レガシーシステムとの互換性が必要な場合、完全性証明はLinked Data signatureの生成前に作成され、挿入されなければなりません(MUST)。
受信したオブジェクトにproof
とsignature
の両方が存在する場合、完全性証明の検証前にLinked Data signatureを削除しなければなりません(MUST)。
例
署名されたオブジェクト
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/data-integrity/v1"
],
"id": "https://server.example/objects/1",
"type": "Note",
"attributedTo": "https://server.example/users/alice",
"content": "Hello world",
"proof": {
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/data-integrity/v1"
],
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-jcs-2022",
"verificationMethod": "https://server.example/users/alice#ed25519-key",
"proofPurpose": "assertionMethod",
"proofValue": "...",
"created": "2023-02-24T23:36:38Z"
}
}
署名されたアクティビティ
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/data-integrity/v1"
],
"id": "https://server.example/activities/1",
"type": "Create",
"actor": "https://server.example/users/alice",
"object": {
"id": "https://server.example/objects/1",
"type": "Note",
"attributedTo": "https://server.example/users/alice",
"content": "Hello world"
},
"proof": {
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/data-integrity/v1"
],
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-jcs-2022",
"verificationMethod": "https://server.example/users/alice#ed25519-key",
"proofPurpose": "assertionMethod",
"proofValue": "...",
"created": "2023-02-24T23:36:38Z"
}
}
埋め込み署名付きオブジェクトを含む署名されたアクティビティ
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/data-integrity/v1"
],
"id": "https://server.example/activities/1",
"type": "Create",
"actor": "https://server.example/users/alice",
"object": {
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/data-integrity/v1"
],
"id": "https://server.example/objects/1",
"type": "Note",
"attributedTo": "https://server.example/users/alice",
"content": "Hello world",
"proof": {
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/data-integrity/v1"
],
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-jcs-2022",
"verificationMethod": "https://server.example/users/alice#ed25519-key",
"proofPurpose": "assertionMethod",
"proofValue": "...",
"created": "2023-02-24T23:36:38Z"
}
},
"proof": {
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/data-integrity/v1"
],
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-jcs-2022",
"verificationMethod": "https://server.example/users/alice#ed25519-key",
"proofPurpose": "assertionMethod",
"proofValue": "...",
"created": "2023-02-24T23:36:38Z"
}
}
テストベクトル
fep-8b32.featureを参照してください。
実装
ユースケース
参照
- Christine Lemmer Webber, Jessica Tallon, アクティビティパブ, 2018
- S. Bradner, RFCにおける要件レベルを示すためのキーワード, 1997
- Dave Longley, Manu Sporny, 検証可能なクレデンシャルデータ完全性 1.0, 2024
- Manu Sporny, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele, Christopher Allen, 分散型識別子 (DIDs) v1.0, 2022
- Dave Longley, Manu Sporny, Markus Sabadello, Drummond Reed, Orie Steele, Christopher Allen, 制御識別子 v1.0, 2025
- silverpill, FEP-521a: アクターの公開鍵の表現, 2023
- Dave Longley, Manu Sporny, データ完全性 EdDSA 暗号スイート v1.0, 2025
- A. Rundgren, B. Jordan, S. Erdtman, JSON正規化スキーム (JCS), 2020
- silverpill, FEP-fe34: オリジンベースのセキュリティモデル, 2024
著作権
CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
法律で許される限りにおいて、このFediverse Enhancement Proposalの著者は、この著作物に関するすべての著作権および関連する権利または隣接する権利を放棄しました。