FEP-8b32: オブジェクト整合性証明
概要
この提案では、ActivityPubサーバーとクライアントが自己認証アクティビティとオブジェクトを作成する方法について説明します。
HTTP 署名は、サーバー間のやり取り中の認証によく使用されます。ただし、これにより認証がアクティビティの配信に結び付けられ、プロトコルの柔軟性が制限されます。
整合性証明は、デジタル署名とそれを検証するために必要なパラメータを表す属性のセットです。これらの証明は任意のアクティビティまたはオブジェクトに追加でき、受信者はアクターの ID とデータの整合性を検証できます。これにより、認証がトランスポートから切り離され、アクティビティのリレー、埋め込みオブジェクト、クライアント側の署名など、さまざまなプロトコルの改善が可能になります。
歴史
Mastodon は2017年からLinked Data 署名をサポートしており、その後、他の多くのプラットフォームでもサポートが追加されました。これらの署名は整合性証明に似ていますが、他の標準に置き換えられた古いLinked Data Signatures 1.0仕様に基づいています。
要件
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC-2119で説明されているとおりに解釈されます。
完全性の証明
提案された認証メカニズムは、データ整合性仕様に基づいています。
証明の生成
証明は、データ整合性仕様のセクション4.2「証明の追加」に従って作成する必要があります。
証明生成のプロセスは、次の手順で構成されます。
- 正規化は、何らかの決定論的アルゴリズムに従って、JSON オブジェクトをハッシュに適した形式に変換することです。
-
ハッシュ化は、暗号ハッシュ関数を使用して変換されたデータの識別子を計算するプロセスです。
-
署名生成は、入力データの整合性を変更から保護する値を計算するプロセスです。
結果の証明は、元のJSONオブジェクトのproof
キーに追加されます。オブジェクトには複数の証明が含まれる場合があります。
整合性証明で使用される属性のリストは、データ整合性仕様のセクション2.1 証明で定義されています。証明タイプはセクション3.1 DataIntegrityProof
で指定されているようにDataIntegrityProof
である必要があります。proofPurpose
属性の値はassertionMethod
でなければなりません。
証明のverificationMethod
属性の値は、公開鍵のHTTP(S)URLまたはDID URLとすることができる。検証方法を表現するコントローラドキュメントは、アクターオブジェクト、またはActivityPubアクターに証明的に関連付けることができる他のドキュメント(DIDドキュメントなど)でなければならない[MUST]。検証メソッドは、コントローラドキュメントのassertionMethod
プロパティと関連付けなければならない[MUST]。コントローラドキュメントがアクターオブジェクトである場合、実装者は、FEP-521aに記載されているように、assertionMethod
プロパティを使用すべきである[SHOULD]。
Proof verification
Recipients of an object SHOULD perform proof verification if it contains integrity proofs. Verification process MUST follow the Data Integrity specification, section 4.4 Verify Proof. It starts with the removal of the proof
value from the JSON object. Then verification method is retrieved from the controller document as described in Controller Documents specification, section 3.3 Retrieve Verification Method. Then the object is canonicalized, hashed and signature verification is performed according to the parameters specified in the proof.
If both HTTP signature and integrity proof are used, the integrity proof MUST be given precedence over HTTP signature. The HTTP signature MAY be dismissed.
Algorithms
Implementers are expected to pursue broad interoperability when choosing algorithms for integrity proofs.
eddsa-jcs-2022 cryptosuite is RECOMMENDED:
- Canonicalization: JCS
- Hashing: SHA-256
- Signatures: EdDSA
[!WARNING]
eddsa-jcs-2022
cryptosuite specification is not stable and may change before it becomes a W3C Recommendation.
Backward compatibility
Integrity proofs and linked data signatures can be used together, as they rely on different properties (proof
and signature
, respectively).
If compatiblity with legacy systems is desired, the integrity proof MUST be created and inserted before the generation of the linked data signature.
If both proof
and signature
are present in a received object, the linked data signature MUST be removed before the verification of the integrity proof.
Special cases
Activities
The controller of the verification method MUST match the actor of activity, or be associated with that actor.
例
Signed 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"
}
}
Signed activity
{
"@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"
}
}
Signed activity with embedded signed object
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/data-integrity/v1",
{
"object": {
"@id": "as:object",
"@type": "@json"
}
}
],
"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"
}
}
Test vectors
See fep-8b32.feature
実装
- Mitra
- Vervis (generation, verification)
- Streams
- Hubzilla
- Fedify
Use cases
- Forwarding from inbox
- Conversation Containers
- FEP-ef61: Portable Objects
- FEP-ae97: Client-side activity signing
参考文献
- Christine Lemmer Webber, Jessica Tallon, ActivityPub, 2018
- S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 1997
- Dave Longley, Manu Sporny, Verifiable Credential Data Integrity 1.0, 2024
- Manu Sporny, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele, Christopher Allen, Decentralized Identifiers (DIDs) v1.0, 2022
- Dave Longley, Manu Sporny, Markus Sabadello, Drummond Reed, Orie Steele, Christopher Allen, Controller Documents 1.0, 2024
- silverpill, FEP-521a: Representing actor's public keys, 2023
- Dave Longley, Manu Sporny, Data Integrity EdDSA Cryptosuites v1.0, 2024
- A. Rundgren, B. Jordan, S. Erdtman, JSON Canonicalization Scheme (JCS), 2020
著作権
CC0 1.0 ユニバーサル (CC0 1.0) パブリック ドメイン
法律で認められる範囲において、この Fediverse 拡張提案の著者は、この作品に対するすべての著作権および関連する権利または隣接する権利を放棄しています。