DID Spaceとのすべてのインタラクションのセキュリティと完全性を確保するため、すべてのAPIリクエストは堅牢な暗号署名メカニズムによって保護されています。このプロセスにより、リクエストが本物であること（主張されたアイデンティティによって送信されたこと）、そして転送中に改ざんされていないことが保証されます。
@blocklet/did-space-js SDKはSpaceClientを使用する際にこのプロセスを自動的に処理しますが、その仕組みを理解することは、安全なアプリケーションを構築し、潜在的な問題をトラブルシューティングする上で重要です。このプロセスは、クライアント側でのリクエスト署名とサーバー側での検証という2つの主要な部分から構成されます。
署名プロセス（クライアント側）
DID Space APIにコマンドが送信される前に、SDKは一連のステップを実行して暗号署名を作成します。これにより、サーバーはリクエストの出所と完全性を検証できます。
以下に手順を説明します。
- ダイジェストの作成: SDKはまず、リクエストペイロードの一意で一貫したフィンガープリントを作成します。リクエストのURL、HTTPメソッド、データを取得し、それらを安定したJSON文字列にシリアライズします。この文字列はSHA3-256を使用してハッシュ化されます。このダイジェストにより、リクエスト内のたった一文字の変更でも、全く異なる署名が生成されることが保証されます。
- JWTの作成: JSON Web Token（JWT）が組み立てられます。このトークンのペイロードには、前のステップで作成されたダイジェスト、発行者のDID（ウォレットから）、そしてリプレイ攻撃を防ぐための有効期限タイムスタンプ（通常は1時間）が含まれます。
- JWTの署名: 提供されたウォレットオブジェクトの
secretKeyを使用して、JWT全体が暗号的に署名されます。この署名は、リクエストがそのウォレットの所有者によって開始されたことを証明します。 - HTTPヘッダーの付与: 最後に、SDKは署名と関連情報を、以下のヘッダーを使用して送信HTTPリクエストに付与します。
x-app-did: アプリケーションのウォレットのDID。x-app-pk: リクエストに署名したウォレットに対応する公開鍵。x-app-token: 前のステップで作成された署名済みJWT。x-app-delegation(任意): 委任された権限に使用されるトークン。以下で説明します。
検証プロセス（サーバー側）
DID Space APIサーバーがリクエストを受信すると、それを処理する前に、その真正性と完全性を検証するために逆のプロセスを実行します。
サーバーの検証手順は以下の通りです。
ヘッダーの抽出
サーバーは受信リクエストから
x-app-did、x-app-pk、x-app-tokenヘッダーを読み取ります。アイデンティティの検証
提供された
x-app-didがx-app-pkに対応することを確認します。これにより、公開鍵が指定されたDIDの有効な鍵であることが保証されます。トークン署名の検証
x-app-pk（公開鍵）を使用して、サーバーはx-app-tokenの署名を検証します。検証が成功すると、トークンが対応する秘密鍵の所有者によって署名されたことが証明されます。ペイロードの完全性の検証
サーバーはクライアントと全く同じプロセスを使用して、リクエストのURL、メソッド、データからSHA3-256ダイジェストを独自に再計算します。次に、この新しく計算されたダイジェストを、検証済みのJWTペイロード内にある
digestと比較します。両者が一致すれば、サーバーはリクエストの内容が署名されてから変更されていないことを確信できます。
これらのチェックがすべて通ると、サーバーはリクエストを有効とみなし、その実行に進みます。
委任された権限
このセキュリティモデルの強力な機能は委任です。これにより、プライマリウォレット（例：ユーザーのウォレット）が、別ウォレット（例：サービスやアプリケーション）に、自身に代わって行動するための特定の一時的な権限を付与できます。
これは、別のJWTを含むx-app-delegationヘッダーを使用して実現されます。この委任トークンはユーザーによって署名され、以下を指定します。
from: ユーザーのDID（委任者）。to: アプリケーションのDID（被委任者）。permissions: 付与される権限の配列。このコンテキストではDIDSpaceAgentを含める必要があります。
サーバーが委任ヘッダー付きのリクエストを検証する際、アプリケーション（被委任者）がユーザー（委任者）の代理として行動する権限があることを確認します。その後、リクエストはユーザーの権限で処理されます。
コア関数
SpaceClientを使用する際には直接呼び出すことはありませんが、@arcblock/jwtおよび@ocap/mcryptoパッケージの以下の関数が、このセキュリティモデルの基盤を形成しています。
signRequest
この関数は、クライアントが署名とヘッダーを組み立てるために内部で使用されます。
signRequest Signature
async function signRequest({
url,
method,
data,
headers,
wallet,
delegation,
}: {
url: string;
method: Method;
data: any;
headers: { [key: string]: string };
wallet?: WalletObject;
delegation?: string;
}): Promise<{ url: string; method: Method; data: any; headers: Headers }>;verifyRequest
この関数は、サーバーが受信リクエストを検証するために使用するロジックを表します。
verifyRequest Signature
async function verifyRequest({
url,
method,
data,
headers,
}: {
url: string;
method: Method;
data: any;
headers: Headers;
}): Promise<string>; // 認証されたアプリのDIDを返すこのリクエスト署名と検証のフローを理解することで、DID Space内のデータを保護する堅牢なセキュリティ対策についての洞察が得られます。コアセキュリティモデルを理解した今、これらの概念を実際のシナリオでどのように適用するかを探求できます。