FEP-8b32: オブジェクト整合性証明

Warning

このFEPはまだ翻訳が完了していません。

ここから翻訳に協力することができます。

概要

この提案では、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

実装

Use cases

参考文献

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 拡張提案の著者は、この作品に対するすべての著作権および関連する権利または隣接する権利を放棄しています。