はじめに
さて、2020年もはじまりましたねQiitaアドベントカレンダー。
こちらはnem #2 のお部屋となります。まだ若干の空き枠がありますので、ぜひご参加ください！
しばらくの間、過去カレンダーも載せておきます。
nem Advent Calendar 2019 - Qiita
nem #2 Advent Calendar 2019 - Qiita
nem Advent Calendar 2018 - Qiita
nem #2 Advent Calendar 2018 - Qiita
nem Advent Calendar 2017 - Qiita
本題
NEMはんこはブロックチェーンを利用して従来の印鑑が持つ機能をデジタルに置き換えるプロジェクトです。現在実装は完了し、アルファ版としてGitHub上でリリースしています。
本記事では、昨今注目されつつある分散型識別子「DID」と比較しながらNEMはんこの機能について解説したいと思います。（DIDが出来た背景や将来性などについてはこれらの記事が分かりやすいです。「DID/SSIについて、考えてみる」、「[PDF]デジタルアイデンティティ ～自己主権型/分散型アイデンティティ～」）
DIDは将来的にトレーサビリティや電子投票、IoT間での認証などにも利用できる可能性のある取り決めです。今のURLと同じぐらいに日常で見かける機会が出てくるかもしれません。しかし、私的には現在のスキームは若干課題点があり、メインチェーンで完結させずにサイドチェーン（L2）を売り込みたい事業者の思惑も見え隠れします（本記事の最後に少し考察を書いています）。現時点でブロックチェーンNEMが実現できることを再確認し、デジタルアイデンティティの正しい発展に寄与できればと思い、本記事を書きました。
なお、DID寄りの人にNEMブロックチェーンを知ってもらいたい意図があるので、文章は比較的DID側の用語を使用します。私自身DIDについては最近勉強を始めたばかりですので、間違い等ございましたら遠慮なくご指摘いただけるとうれしいです。
分散型識別子DID(Decentralized Identifiers)
DIDを構成する要素は識別子(DID)、DIDドキュメント(DID Document)、検証可能な証明書(Verifiable Credential)の3つがあります。
DIDは、HTMLやCSSの規格を提唱しているW3C（World Wide Web Consortium）によって定義された識別子で、以下のようなフォーマットで表現します。
A Primer for Decentralized Identifiers - The Format of a DIDより
DIDを作成する時にアカウントの秘密鍵が割り当てられ、所有者（ユーザー:Holder）が管理します。
この識別子１つにつき、１つのDIDドキュメントが紐付けられます。
DIDドキュメントには公開鍵とVerifiable Credentialへアクセスするためのエンドポイントが記録されていて、Verifiable Credentialには証明書(免許証など)と署名が記載されています。
構成図（アーキテクチャ）
DIDとNEMはんこの構成図を描いてみて比較します。
DID 構成図
ユーザ(Holder)がDIDをid cardで証明書（Verifiable Credential）を所有する例で考えてみます。
id cardにはHolderの所有するDIDが記載されており、これを提示することで自身を証明します。id cardの内部には秘密鍵情報が記録されています。DIDに対応するDID Documentがブロックチェーンに保存し、証明書情報はDID Documentに記録されているエンドポイント経由でVerifiable Credentialに保存します。Verifiable Credentialへの書き込みは証明書発行者（発行者もまたいずれかののDID Holderになります）の秘密鍵による署名が必要です。検証にはDID Documentに記載された公開鍵で検証します。
参考までに、DID DocumentとVerifiable Credentialの例を示します。
DID Document（DIDドキュメント）
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}],
"service": [{
"id":"did:example:123456789abcdefghi#vcs",
"type": "VerifiableCredentialService",
"serviceEndpoint": "https://example.com/vc/"
}]
}
Decentralized Identifiers (DIDs) v1.0
Core architecture, data model, and representations より
publicKeyBase58に公開鍵、serviceEndpointにエンドポイントが指定されています。これがブロックチェーンによって改ざんされずに保存されています。
Verifiable Credential （検証可能な証明書）
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/1872",
"type": ["VerifiableCredential", "AlumniCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T19:73:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Université",
"lang": "fr"
}]
}
},
"proof": {
"type": "RsaSignature2018",
"created": "2017-06-18T21:19:10Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://example.edu/issuers/keys/1",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}
Verifiable Credentials Data Model 1.0 より
credentialSubjectに証明する内容、proof.jwsに署名情報が記されています。この内容はたとえ改ざんされたとしても、DID Documentに記載された公開鍵でその真偽性が検証可能です。
次にNEMはんこの構成を示します
NEMはんこ 構成図
Holderはアカウントの公開鍵をQRコード等に出力して自身の証明として使用します。
NEMはんこはNEMアポスティーユを発展させた形で開発しており、DIDのRegistryに当たる部分の実装は行っていません。代わりに証明したいデジタルコンテンツ(Apostille)のハッシュ値をトランザクションメッセージに載せて発行者に送信してもらいます。
Holderへ送信したメッセージ（payload）上でIssuerが証明書の存在を認めるという形で表現します。またトランザクションのメッセージを利用するため、アカウントとの関係性が分離不可能になりますが、Holderとマルチシグ(1-of-1)を挟むことで証明情報との間に自由度を持たせています。ちなみにこのマルチシグを(2-of-3)などにすれば複数人におけるDIDの共有所有なども表現できます。この仕組みは組織がDIDを所有するという状況が生まれた時に非常に意味を持ってくるようになります。
追記：ブロックチェーン内にアポスティーユなど（証明書）のハッシュ値を記録したのは、NEMはんこができるだけサードパーティのシステムに依存せず自律分散的に成立させようとしているためです。例え私がNEMはんこのソースコードを削除して失踪したとしても、このプロトコルを守った形で誰かが同チェーン上で再開すれば、過去のNEMはんこも問題なく使用できます。payloadの部分にRegistryへのエンドポイントを記載すれば、DIDと同様の仕組みにすることができます。ただし、この場合はRegistryの存続を保証する別のトラストレスな仕組みが必要となります。
エコシステム
では、具体的にどういったエコシステムを構築できるのか検証してみましょう。
DID エコシステム
学生が学生証をもとにサービスを受けたり、卒業証書を就職先企業に提示するスキームを例に挙げてみました。
(VCはVerifiable Credentialの略です)
- 学生がDIDを作成(Create)し、所有
- 大学が学生DIDに紐づいた証明書を発行(Issue,Write)
- 学生が企業に証明書を提示(Send)
- 企業が証明書の検証(Read,Verify)
分散型DIDを採用することで以下のような特徴があります。
- DIDは学生本人が作成している（作成手段を学生が選べる）
- 学校はそのDIDに対して、在校生であるか（あるいは卒業生）の情報のみ付与している
- 学校側からDIDが流出したとしてもそれ以上の情報は洩れない
- 企業は学生情報にアクセスするための特別なプラットフォームに参加する必要がない
分散型アイデンティティを用いることのメリットがここに集約されています。
でもこれ、よく見ると印鑑証明と似たスキームなんですよね。印鑑を自分で手配して役所に届け出れば、
どんな契約の現場でも印鑑の持ち主が役所に届け出た本人であるという事実だけを証明してくれるのです。
NEMはんこを作ろうとしたのは、この印鑑の良さをデジタルでさらに拡張できないか？と思ったことがきっかけでした。当時のIT政策担当大臣に「印鑑問題はしょせんは民間の話」と言われて、怒りに任せて40時間ほどで作り上げたわけではありません
NEMはんこ エコシステム
さて、NEMはんこのスキームを図で表現してみましょう。
（Registryへの書き込み、読み込みいった部分の表現は省略しました）
解説
具体的なプロダクトですので、矢印の数が増えています。役割と機能に分けてDIDのエコシステム図と対応させながら説明していきます。
役割
- Alice：学生（Holder）
- BobとCarolの連署者が存在し、図ではAliceの所有をBobからCarolへ譲渡しています。DIDでは回復(Recovery)という用語で検討が進められているようです。
- Ivan：学校（Issuer）
- 証明書の発行者です。
- Victor：企業（Verifier）
- 証明書の検証者です。
機能
具体的な使用用途をイメージした機能一覧です。
- 自署
- 自身への署名を社会的認知度の高い媒体に提示することでIssuerの信頼性を高めます。
- 承認
- Holderに対してIssuerが証明書ファイルのハッシュ値をメッセージ送信します。
- 期限更新（未実装）
- 定期的に有効期限を明示したトークンをAliceに付与することで証明書の有効期限を表現します。
- 無効化
- Alice本人がキャンセルしたい場合に証明書の無効を表現します。
- 譲渡
- 検証者に対して証明書を提示できる権限を移行します。また、証明書の紛失や漏洩などのトラブルから回復します。
- 認証
- 過去に発行した証明書をHolderが所有しているか確認します。
構成に多少の違いはありつつも、実現しようとしているエコシステムはDIDと非常によく似ていると感じていただけたのではないでしょうか？
次回はさらに発展させてブロックチェーンの社会実装についてNEMを使えばどのように実現できるか、そのデザインパターンについて解説したいと思います。
さいごに考察（ひとりごと）
DIDの設計の要は良くも悪くも「ブロックチェーンに多くを頼りすぎない」ことだと思います。ビットコインやイーサリアムなどプラットフォームの特徴に依存せずにDIDを実現できるように設計されたのでしょう。DID Documentさえ”適切”に分散管理できればDIDやRegistryはプロトコル外でも支障なく運用することが可能です。しかし、私は以下の2点においてDIDは課題を抱えていると思います。
DID Documentの信頼性
DIDに紐づくVeridiable Credentialの信頼性はDID Documentを正しく取得してこそ生かされますが、その取得にエージェント（Webで言うところの「ブラウザ」のようなもの）に依存せざるを得ない点を考えると、厳密な信頼性検証のためにはVerifierが都度分散台帳上の全ブロックヘッダーを検証する必要があるのではないかと思います。
Issuerの鍵交換
Holderが複数鍵を所有し、用途に応じてDIDを使い分けられるのは便利ですが、これがIssuerについても同じように便利かと言えば話は別です。VerifierはIssuerのDIDを頼りに信頼性を検証するため、このDID値がころころ変わるようでは運用全体に影響が出てしまいます。Issuerの秘密鍵が漏洩した場合もDIDを変えずにDID Documentを差し替えられるような機能が必要と考えます。