第三回
エネルギー・ブロックチェーン入門

田町 京子
Kaula Lab
Published in
15 min readSep 7, 2020

EW-DOSとデジタルアイデンティティ

今回は、連載第一回の【E2】EW-DOS 概要 にて触れた各サービスが、新しい概念であるデジタルアイデンティティをどのように導入したかについて説明します。(有効性については連載第二回【E4.2】のAPGの事例をご参照ください。)
【B2】にてその基本の概念であるSSI/DID (自己主権型アイデンティティ Self-Sovereign Identity / 非中央集権型識別子 Decentralized Identifiers)の詳細を説明した後、【E5】ではその目的と実現方法について述べます。

********** 目次 ************
【B2】SSI/DID
【B2.1】現在のデジタルアイデンティティ管理の課題
【B2.2】SSI / DID 概要
【B2.3】DID の仕様
【B2.4】SSI / DID についての海外の動向

【E5】EW-DOS におけるアイデンティティ管理
【E5.1】DID 関連サービス
【E5.2】EW-DOSにおけるクレーム
****************************

【B2】SSI/DID 概要

【B2.1】現在のデジタルアイデンティティ管理の課題

金融、医療、旅行等、各種オンラインサービスの本人確認やデジタルな契約における多くの場面で、ユーザー(個人または組織)のアイデンティティ(実体に関する属性情報の集合)の提示が求められます。これらの情報はデジタルアイデンティティと呼ばれ、その提示に同意することで、サービスを享受し利便性を向上させることができます。

複数の組織による中央集権型のアイデンティティ管理(出展:著者作成)

一方で、これまでのデジタルアイデンティティには、以下のような問題点がありました:
1) 特定の団体・組織(個人の選択によるものではない)によってのみ認識され、 限られた状況・用途でのみ使用できる。他のサービス利用時には別途、アイデンティティの登録が必要になる(上図参照)。
2) その管理は巨大IT企業等により中央集権的になされ、各個人の管理下にはない。 データの選択的開示が不可能であり、不必要に個人情報が明らかにされる可能性がある(下図参照)。
3) 企業サーバーの不具合による破損など、管理組織の失敗により、消える、あるいは無効になる可能性がある。
4) 悪意のある第三者による漏洩や改ざん、不正流出(不正に複製 および なりすまし などに利用)のリスクがある。 (このため各国も規制強化を進め、EUにおけるGDPR (一般データ保護規則)や 米国カリフォルニア州のCCPA (カリフォルニア州消費者プライバ シー法)などが制定されています。)

個人情報の選択的開示が必要な例:運転免許証で本人が成人であることを示す場合(出展:著者作成)

【B2.2】SSI / DID とは

この数年、今後のあるべきデジタルアイデンティティの姿への関心が高まっています。特に、Self-Sovereign Identity (自己主権型アイデンティティ、以下 SSIと表記)の概念に基づく 、Decentralized Identifiers(非中央集権型識別子、以下 DID と表記) および Verifiable Claims(*1)は、各種基盤への取り込みも進んでいます。EW-DOSでもIdentity Directoryとして取り入れられています(【E5】参照)。

(*1) Verifiable Claims(以下 “VC”と表記):検証可能な(暗号技術で証明可能な)個人・法人情報。 w3c(【B2.4】参照)による規格。個人・法人情報における特定の事実を証明するためのデータ形式。VCを複数含んだ個人・法人情報のセットを Verifiable Credential(検証可能な資格情報)という。

SSIとは、自分が自身の個人情報を管理する、デジタルアイデンティティのポリシー(考え方)です。IDを一括管理する中央集権的な管理主体が介在することなく、個々が個々のIDを管理する「自己主権的」な考え方が基本となっています。アナログの世界でも日本人は自分のハンコを自分で管理していますが、SSIにおける個人情報は分散化・暗号化されおり、グローバルでも有効です。

SSIの利点として挙げられる事項は以下です:
1) データの選択的開示が可能。開示したいデータだけを開示できる 。
ex) 名前、年齢だけを送信して、住所、写真データは送らない
2) 多数の個人(または組織)についての情報を持つ企業による個人情報の独占市場化を防止。
3) 自分のデータにいつでもアクセスでき、システムの透明性が高い。
4) 自分の個人情報を他の団体やプラットフォームでも利用できる。
5) データの存続性が高く、自分の意志による消去も可能。

DIDには以下の特徴があります:

DIDの特徴 (w3cサイト情報等から著者作成)

DID および DID Document(【B2.3】参照)の保存先としてのDIDインフラストラクチャとして、ブロックチェーンを使用するメリットは以下です。(Public型かPermission型かは関係ありません。(【B1】参照))
1) 情報を改ざんできない。
2) 中央集権的な特定の企業や機関の管理に依存しない。
3) 分散して存在する全チェーンが消失しないかぎり、情報は永久に残る。
4) DIDとVCを組み合わせることにより、自分の個人情報の必要箇所だけを選択的に開示し、 かつそれが正しい情報であることをブロックチェーンを使って証明できる。

【B2.3】 DIDの仕様

DIDインフラストラクチャは、グローバルなKey-Valueストア(*2)と考えることができます。 この仮想データベースでは、キーはDID、値はDID Documentであり、これによりDIDはひもづけられたDID Documentにアクセスすることができます。
(*2) key-value ストア: 非リレーショナルデータベースの一種。データを、キー(一意の識別子として機能)と値のペアのシンプルな集合として格納。

DIDアーキテクチャーの基本コンポーネント (出典: Decentralized Identifiers (DIDs) v1.0 等から著者作成)

<1> DIDのフォーマット
DIDは、以下の形式である必要があります:
[スキーム]:[DIDメソッド]:[DIDメソッド固有の識別子]

例)既存のアドレスをそのまま識別子として使用する場合もあります did:erc725:2F2B37C890824242Cb9B0FE5614fA2221B79901E
did:ethr:mainnet:0xb9c5714089478a327f09197987f16f9e5d936e8a did:sov:123456789abcdefghi

<2> DIDメソッド
DIDが特定のブロックチェーンでどのように機能するか(Create、Read(resolve)、Update、管理等) を定義します。
識別子の形式と生成は、メソッド固有。 メソッド固有の識別子文字列は、そのDIDメソッドの名前空間内で一意である必要があります。
参照)全てのDIDメソッドの仕様:
https://w3c.github.io/did-spec-registries/#did-methods

<3> DID Document
DID Documentは、DIDに関連するデータモデルをJSON-LD(Linked Data)で記述したものです。
DID、公開鍵、サービス情報、DID Document の生成日時と更新日時、Identity Hub (*3)情報等を含みます。

(*3) Identity Hub: DIDに関するアイデンティティ情報(VCなど)を保存・共有する。クラウドやサーバー上で稼働。Personal Data Storeと呼ぶこともある。

例)

出典: Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations https://w3c.github.io/did-core/#a-simple-example

【B2.4】SSI/DID についての海外の動向

SSI および DIDの普及、標準化にむけて多数の団体が活動しています。主な団体は以下です。

■Decentralized Identity Foundation (DIF、https://identity.foundation/governance/about)
2017年5月にDIDに関する仕様の検討と標準化のための団体として設立され、インターオペラビリティのための基盤整備などの活動が行われています。2020年9月現在、95の組織・企業がメンバーとして参加しています。
主な参加企業: Consensys, Microsoft, IBM, Accenture, RSA, MasterCard, Enterprise Ethereum Alliance, NEC, Sovrin

DIFメンバー (出展:https://identity.foundation/#contatus

■World Wide Web Consortium (W3C)
Web技術の標準化のための非営利団体です。SSIを提唱し、SSIの概念に基づきDIDとVCを開発、IBMなどの大手IT企業がそれに賛同しています。2019年9月に Decentralized Identifier Working Groupが発足し、Credential Community Group (https://www.w3.org/community/credentials/) にてDIDのスキーマおよびオペレーションの標準化などの活動実施中です。

■Sovrin Foundation (https://sovrin.org/)
SSIの実現にむけた非営利団体です。DIFメンバー。ブロックチェーン基盤 Hyperledger Indyを推進。ゼロ知識証明(zero-knowledge proofs, ZKP)を提唱しています。

■Hyperledger (https://www.hyperledger.org/
Linux Foundation下のブロックチェーン技術推進のためのオープンソースコミュニティ。ブロックチェーン基盤 Hyperledger Fabricを推進、Identity Mixerを提唱しています。

【E5】EW-DOS におけるアイデンティティ管理

EW-DOSの目的の一つに、資産、需要家、系統運用者、サービスプロバイダー、小売電気事業者の間のトランザクション(取引処理)を促進することがあります。その実現のために、特定の個人または機器(発電機や蓄電池等)が使用するすべての製品またはサービスに対して、1つのグローバルで永続的なIDが使用されています。
EW-DOSでは SSI / DID (【B2.2】参照)が基本概念として取り入れられており、アイデンティティはID所有者によって管理・制御され、全ての市場参加者は、ID所有者の許可に基づきアクセスできます。このことにより、エネルギー領域における、トップダウン型の一方的な管理のシステムが変革されます。

【E5.1】DID 関連サービス

EW-DOSでは、複数のコンポーネントが連携し、レガシーなITシステムや分散レジストリ、メッセージングサービスと共に、DIDを実現しています。EW ChainによるDIDインフラストラクチャの実装は、W3C DID標準に基づいており、DIDに関連する上位層の主なコンポーネント(サービス)として、以下が挙げられます。

(出典:EW-DOS: The Energy Web Decentralized Operating System The Open-Source Technology Stack for Accelerating the Energy Transition を元に著者作成)

1) Identity Directory
・ID所有者(DID Subject)はIDに、自分の意図どおりに自分に関する情報を追加(“Claim”)でき、当局(政府、銀行、エネルギー会社、機器について何らかの証明ができるメーカー・業者など)によってこの情報を確認できます。このプロセスにおいて、IDは認証されます(【E5.2】参照)。
Claimの例:
「Aさんは バッテリーBの所有者です。」
「デバイスCは、XXXという属性を持っています。」
「事業者Eは,適格なDERの所有者です。」

2) Energy Web Name Service (EWNS)
・16進文字列等で表現されるDIDを、ユーザーが判読しやすいEWNS名に変換・逆変換します。
・ EWNS名には、電子メールアドレス、契約インターフェイス/アドレス、その他の任意のメタデータ(resource.name.ewcなど)等が用いられます。
・ DIDの管理プロセスや、ユーザーによる契約やアドレス、アプリ等の操作を簡素化します。

3) DID Key Recovery
・EW-DOSにおける DIDの実装では、DID自身がスマートコントラクト(ブロックチェーン上で契約内容を自動で実行するしくみ) であり、公開鍵・秘密鍵のペアにより管理されます。
・ DID Key Recoveryは、DIDの所有者がオリジナルの鍵のペアを失う(コントロールを失う)状況に備えて、 複数のDID Controller(DID Documentの更新ができる)を定義するしくみです。 DID所有者は(オリジナルの鍵ペア以外に)新しい鍵ペアを作成し、新しくControllerになるentityに権限を委任します。

【E5.2】EW-DOSにおけるクレーム

VC 関連のプロセスは以下の手順で実行されます(下図参照)。

— — — — — — — — — — — — — — — — — — — — — — — — —
<登録>
① 自分(自社)のDID をブロックチェーン上に(Ethereumアドレス等を使用して)自分で作成。
② DID Docoment (自分のDID、公開鍵、Identity Hub情報等を含む) をブロックチェーン上に作成。
③ 保証(証明)してほしい相手(VC発行者)に、保証を要求(Claim)し、VCでの保証(attest)をもらう。
例) バッテリーに、バッテリーの所有権を証明してもらう。
④ 受領したVCを、自分のIdentity Hubに保存。
⑤ ④へのリンクについてDID Documentを更新。
<提示>
⑥ VC(その全てまたは必要な情報のみを、自分の秘密鍵で署名して)を取引先の人/システム (例:DSO:配電系統運用者)に提示。
⑦ 取引先は保証情報を確認 (DID Resolutions)。
DIDをkeyにして DID Documentを取得し、公開鍵で真正性を確認。
— — — — — — — — — — — — — — — — — — — — — — — —

Verifiable Claim フロー例 (出典:Webinar:Decentralized Identifiers and Self-Sovereign Identity等を参考に作者作成)

**********************************

■EWF, EW-DOS, EW Chainの最新の詳細については、以下のサイトをご参照ください。
Energy Web Foundation
EW-DOS White Paper Part 1, Vision & Purpose
EW-DOS White Paper Part 2, Technology Details
EW Chain White Paper

■関連記事
Kaula Lab (連載記事一覧)
第一回 エネルギー・ブロックチェーン入門:EWF概要 / ブロックチェーンの基本概念
第二回 エネルギー・ブロックチェーン入門:EW-DOSのユースケース概観と事例紹介
第三回 エネルギー・ブロックチェーン入門:EW-DOSとデジタルアイデンティティ

最後までお読み頂き誠にありがとうございます。
記事へのご意見やご質問などがございましたらお気軽に下記までご連絡ください。
info@kaula-lab.com

******************************

--

--

田町 京子
Kaula Lab

Kyohko Tamachi | IT Specialist | Hyperledger Fabric | Blockchain | Kaula.jp|