XSL Lab寄稿
検証可能な資格情報（クレデンシャル）は、所有者に送信される前に、発行者は署名します。検証者に提示される前に、所有者は検証可能なプレゼンテーション（検証可能なクレデンシャルを含むプレゼンテーション）に署名する流れです。
検証可能なクレデンシャルと検証可能なプレゼンテーションへの署名
したがって、発行者はVCを、所有者に送信し、所有者は自分のIDウォレット（モバイルアプリケーション（dApp）など）にこのVCを保存します。 前回の記事では、IDウォレットのソリューションとしてNFCカードを使用することが可能であると述べました。
「メタマスク」のような専用のブラウザ拡張機能を使用することもできます。この「myDid」ブラウザ拡張機能の開発の 進捗状況についてまたお知らせします。
このブラウザ拡張機能は、発行者からの検証可能なクレデンシャルを保存し、機能として、最初にユーザーの「インフォームドコンセント」（同意）を取得してから検証者に提示できる必要があります。
2つの主要な署名は、発行者よりのVCの署名と、所有者よりのVPの署名です。 ただし、下記の通り、この3者の間で他の2つのオプションの署名を行うこともできます。
- 所有者のウォレットがVCを要求する場合。（ユーザーはこの要求に署名することもできます。特に発行者は検証を行うため）
- 検証者がユーザーにVC要求を行う場合。（検証者はこの要求に署名することもできます）
検証者のリクエストについては、署名されたクレデンシャルのリクエストが少ないみたいです。ユーザーによる「検証者の検証」は、SSL/TLSの安全な通信にリンクされたIDと比較することにより、視覚的または部分的に実行することができます。検証者は常に識別可能なDID（分散型ID）を持っているとは限りません（必須ではありません）。
さて、今度は検証可能な資格情報の「発行者」の役割と、そのキーと署名を管理するための可能なオプションに焦点を当てましょう。
発行者向けのさまざまなキーおよび署名管理のオプション
すべての場合において、発行者はユーザーの要求を管理するために「管理インターフェース」（多かれ少なかれ自動化可能である）を持っている必要があります。
このインターフェースは、VCを作成するときに、ユーザーの要求とそのステータス（署名の検証後）を受信して保存できる必要があります。
現在、我々のチームは署名を実行するための3つの可能なオプションを開発しています。
- 発行者のウェブインターフェースは、自分で選んだクラウド KMS（キー管理システム）を使用します。AWS、Azure、GCPなど、使用するクラウドアーキテクチャに応じて、いくつかのKMSを使用することができます。または、KMIP（キー管理相互運用プロトコル）と互換性のある統合可能なプライベートKMSを使用することも可能です。
- ブラウザーレベルでキーを直接に管理する（単純なソフトウェア保護）、または署名の要求をメタマスクと互換性のある、Ledger Nanoのようなハードウェアウォレットに送信するブラウザー拡張機能を開発しています。
- 発行者のサーバーに接続されている1つまたは複数のHSM（ハードウェアセキュリティモジュール）は最後のオプションです。
VC内でいくつかのタイプの署名を定義できますが、最も機密性の高い署名はメタマスクを介した署名です。
実際、メタマスク（eth_sign）を介して最初の署名方法では、任意のハッシュ、特にブロードキャスト可能なトランザクションのハッシュに署名することができます。
この他にも、署名のサポートは、W3C³によるVC署名の可能なソリューションとして、新しいメソッドであるEIP712¹（Ethereum Improvement Proposal）や、現時点ではドラフト状態の最新メソッド（signTypedData_v4²）で改善されています。
このため、IDウォレットなどのVCユーザー向けのソリューションと並行して、モバイルアプリケーション、ブラウザ拡張機能、NFCカードの形等、VC発行者の「すぐに使用できる」管理ソリューションにも取り組んでいます。
詳細については、まもなく新しい記事を投稿します。
