Internet Infrastructure Review（IIR）Vol.52
2021年9月30日

2. フォーカス・リサーチ（1）

Verifiable CredentialとBBS+署名

2.1 はじめに

新しいデジタルアイデンティティのあり方として、自己主権型アイデンティティ（Self-Sovereign Identity、SSI）が注目を集めています。デジタルアイデンティティは「自分が何者であるか」をデジタル空間の中で表現したもので、名前、生年月日、性別、メールアドレスのような属性の集まりでできています（注1）。従来、デジタルアイデンティティの管理はアプリケーションや業務システム、またはGAFAMに代表されるアイデンティティプロバイダによって行われてきました。これをアイデンティティの持ち主である自分自身が主体的に管理できるようにしようというのが自己主権型アイデンティティの考え方です。

本レポートのVol.43（注2）で自己主権型アイデンティティを取り上げてから2年が経過しました。この間に、Verifiable Credential （以下VCと略します）、非中央集権型識別子（Decentralized Identifier、DID）、デジタルエージェント、デジタルウォレット、ガバナンスフレームワークなど、自己主権型アイデンティティの実現に必要な技術や仕組みは発展を続けています。これらの網羅的な説明は他の文献（注3）（注4）に譲り、本稿では自己主権型アイデンティティの中核と言えるVCにフォーカスを絞って概要を示します。また、昨年からコミュニティの関心を集めている、BBS+署名を使ったVCの実装についても簡単に紹介します。

2.2 クレデンシャルと Verifiable Credential

クレデンシャルという言葉は文脈によって様々な意味を持ちます（注5）が、本稿ではWorld Wide Web Consortium（W3C）の仕様（注6）を参考に「対象者に対する発行者のClaim（主張）の集まり」という意味で使います。例えば、運転免許証というクレデンシャルは、対象者（=免許証の持ち主）に対して発行者（=都道府県の公安委員会）が主張するClaimの集まり（=持ち主の氏名、住所、生年月日、顔写真、運転できる車の種類など）と言えます。

クレデンシャルを使うことで、私たちは「自分が何者であるか」をクレデンシャル発行者の言葉を借りて伝えることができます。例えば私が銀行口座を開設しようとして「私は○○市に住む××という者で生年月日が△△の男性である」と手ぶらで主張したとしても、銀行の担当者には信用してもらえないでしょう。こうした場合にはクレデンシャルである運転免許証を見せることで、私の主張が都道府県の公安委員会によって保証され、主張の信用度を高めることができます（注7）。

ただしクレデンシャルを使った主張を受け入れてもらうためには、相手にとって信用に足るクレデンシャルでなければなりません。それは誰によって発行されたものか。別の者に書き換えられたり偽造されたりしていないか。有効期限内であって失効されていないか。そうした検証作業を行って初めてクレデンシャルに書かれた情報が受け入れられます。

物理的なクレデンシャルの場合、相手は券面に書かれた情報を確認し、透かしのような特殊印刷があればそれをチェックすることで正しさを検証します。こうした検証作業はしばしば職人芸を要する難しいものとなります。

VCはクレデンシャルをデジタル化して機械的に検証できるようにしたものです。単に券面をスキャンして画像データにしたものとは違い、デジタル署名技術を使うことで「発行者が誰であるか」「内容に改ざんがないか」を機械的に検証することができます。Anonymous CredentialやAttribute-based Credentialと呼ばれる暗号理論の研究成果が土台となっており、ゼロ知識証明技術を使ったプライバシー保護の仕組みを備えることも可能です。

2.3 Verifiable Credentialの利用イメージ

VCの使われ方をより具体的にイメージするため、ここでは「住民票の写し」がVC化された世界を想像して、発行から利用までのシナリオを示します。

X市に住むAさんは、B社が提供する有料サービスを家族で利用しようと考えました。B社のサービスはX市の住民に割引が適用されます。割引を受けるためにはAさんは自身とその家族がX市に住んでいることを示す必要があります。

そこでAさんはX市の住民サービスを訪れ、VC版「住民票の写し」の発行を依頼することにしました。

X市の住民サービスは適切な方法によってAさんの本人確認を行います。例えば対面で顔写真付きの証明書の提示を求めたり、オンラインで別のVCの提示を求めたりします。

Aさんの本人確認ができたら、X市の住民サービスは住民情報データベースからAさんとその家族の属性を取得し、「住民票の写し」相当のVCを発行します。VCにはAさんとその家族の住所、氏名、生年月日、性別、住民となった年月日などが属性として含まれます。発行されたVCはAさんのスマートフォンへ格納されます。

続いてAさんはB社のサービスの利用申請を行います。AさんはX市に発行してもらったVCを提示することで、Aさんとその家族がX市在住であることを示そうとします。

2.4 Verifiable Credentialのエコシステム

上の例には、VCを発行するX市、それを受け取って提示するA さん、提示されたクレデンシャルを検証するB社が登場しました。VCに関わる登場人物とそれらの関係性はVCのエコシステムと呼ばれ、図-2のような形で整理されています。

発行者（Issuer）は、VCを発行する人や組織です。先程の例ではX市が該当します。

所有者（Holder）は、発行者が発行したVCを受け取り、自身のスマートフォンなどに保存します。そして必要に応じてそれを検証者に提示します。上の例ではAさんが「住民票の写し」VC の所有者でした。

対象者（Subject）は、VCによって主張されるClaimの対象です。多くの場合では所有者と同じですが、例えば出生証明書のように対象者が乳児、所有者はその保護者と異なることもあります。上の例でも、所有者であるAさんに加えてAさんの家族も対象者に含まれます。

検証者（Verifier）は、所有者が提示したVCを検証し、そこに書かれた情報を利用する人や組織です。上の例ではB社やC社がそれにあたります。

最後の検証可能データレジストリ（Verifiable Data Registry） は、発行者、所有者、検証者が利用するデータ置き場です。発行者の識別子や公開鍵、クレデンシャルの失効情報など、検証に必要な情報が記録されます。誰でも参照可能ですが書き換えはできません。その性質上、ブロックチェーンで実装されることが多いです。

VCや自己主権型アイデンティティはブロックチェーンと共に語られることが多く、しばしばVC自体がブロックチェーンに記録されると思われがちですが、これは誤解です。検証可能データレジストリは誰もが参照できて書き換えのできないレジストリなので、パーソナルデータを含むVCの置き場としては適切でないとされています（注8）。

先程の例で見たように、VCの2大イベントは、発行者から所有者へのクレデンシャル発行と、所有者から検証者へのクレデンシャル提示です。所有者は発行者にクレデンシャルの発行を依頼し、対象者の属性を含むVCを発行してもらいます。所有者はそれを自身のスマートフォンなどに保存した上で、必要な部分だけを検証者へ提示し、検証者がそれを検証します。結果として、発行者によって主張される属性を対象者が持っていることが、検証者によって確認されます。

拡大する

図-2 Verifiable Credential のエコシステム

2.5 Verifiable Credentialと 従来のデジタル証明書の違い

実のところ、デジタル署名技術を使ったクレデンシャルは目新しいものではありません。私たちが日々利用しているHTTPS通信では、デジタル証明書（Digital Certificate）の検証が常に行われています。デジタルアイデンティティの連携によく使われるOpenID Connectでも、デジタル署名が付与されたIDトークンの中にアイデンティティ情報を格納し、検証可能にしています。その意味ではこれらのデジタル証明書やトークンもまた検証可能なクレデンシャル、すなわち"Verifiable Credential"であると言えそうです。

ではVCと従来のデジタル証明書の違いはどこにあるのでしょうか。筆者は主に以下の3つの点にあると考えています。すべてのVCがこれらを完全に満たすわけではありませんが、少なくとも1つ以上の特徴を備えるものがVCと呼ばれているように見受けられます。

1. 提供データを最小化する仕組みが備わっている
2. 発行者と検証者の間に必ず所有者が介在する
3. 非中央集権型識別子（DID）を使う

まず1点目について、多くのVCにはクレデンシャル所有者が開示するデータを最小化する仕組みが用意されています。中でも特徴的なのはゼロ知識証明と呼ばれる暗号学的な技術を利用するものです。ゼロ知識証明を使うことで、所有者はクレデンシャルに書かれた属性の一部を隠しながら必要な属性だけを検証者に提示できます。また、隠した属性がある条件を満たすことだけを示すことも可能です。例えば、運転免許証の氏名、住所、生年月日は隠しつつ、普通自動車の運転資格を持つことや、年齢が20 歳以上であることだけを示せます。こうした仕組みは所有者や対象者のプライバシー保護にとって重要な特徴です。

2点目もまた所有者のプライバシー保護に関する特徴です。発行者をIdentity Provider（IdP）、検証者をRelying Party （RP）とみなすと、VCの仕組みはOpenID ConnectやSAML のような現在広く使われているアイデンティティ連携の仕組みに似ています。VCがこれらと大きく異なるのは、発行者と検証者の間で直接のやり取りをさせずに、必ず両者の間に所有者が介在する点です。自己主権型アイデンティティでVCが中心的な役割を果たす理由の1つがここにあります。所有者がいつ、どの検証者に対して、どのような情報を提示したか。そうした所有者の一挙一動を、発行者や他の検証者に知られたくない場合にこうした特性が役に立ちます。

3点目は、VCと並んで自己主権型アイデンティティの要とされる非中央集権型識別子（DID）に関するものです。DIDは人、組織、モノに付けられる識別子で、デジタル署名の検証に必要な公開鍵と結びつけられるものです。DIDと公開鍵の結びつきは、認証局のような信頼できる第三者には頼らずに、ブロックチェーンなどを用いて非中央集権的に保証されます。DIDを使わずともVCのメリットを得ることは可能ですが、互いの長所を活かし合うことのできるペアとして併用されることが多いです。

2.6 Verifiable Credentialに関する 国内外の動向

こうしたVCの特徴を活かし、ワクチン証明書の実装をはじめとする実験的な試みが国内外で活発に行われています。

2020年4月、VCを使って相互運用性とプライバシー保護に配慮したCOVID-19向けデジタルクレデンシャルを実現するためのCOVID-19 Credentials Initiative（CCI）という取り組みが立ち上がりました（注9）。現在はLinux Foundation Public Health（ LFPH）に合流して活動を継続しています（注10）。2021年 6月には国をまたがるワクチン証明書の交換基盤であるGlobal COVID Certificate Network（GCCN）もLFPHにより開始されています（注11）。並行して、今年の1月にはMicrosoft、Oracle、Salesforce他によるVaccination Credential Initiative（VCI） も発足し、VCに基づくワクチン証明書のデジタル化が進められています（注12）。

同じく2021年6月、欧州委員会が発表したEuropean Digital Identityフレームワークでは、EU（欧州連合）加盟国のすべての市民と居住者が利用可能なDigital Identity Walletというコンセプトが示されました。VCや自己主権型アイデンティティの利用は明記されていませんが、発行者・所有者・検証者で構成されるモデルやユースケース、属性の選択的開示機能など、VCの影響を強く受けていることが見て取れます（注13）。

他にもNPO団体KivaによるマイクロファイナンスのためのeKYC（オンライン本人確認）（注14）や国際航空運送協会（IATA） のIATA Travel Pass（注15）など、VCの活用分野は広がりを見せています。

国内では慶應義塾大学が国内の企業5社と共同で、Microsoftとも連携しながらVCやDIDを使った学生向けアイデンティティ基盤の実証実験を2020年10月に始めています（注16）。またTrusted Web推進協議会が2021年3月に公開したホワイトペーパーでは、Web上に検証可能な領域を増やしていくという目標に向けて、VCの応用可能性についても触れられています（注17）。

こうしたユースケースを支えるプロダクトも次々と開発されています。Linux FoundationのHyperledgerプロジェクトでは、DIDの基盤となる分散型台帳Hyperledger Indy（注18）や、VC を扱うエージェントHyperledger Aries（注19）、それらが活用する暗号ライブラリHyperledger Ursa（注20）を中心に活発な開発が行われています。また、MicrosoftのIdentity as a Service （IDaaS）であるAzure ADにはVC機能が組み込まれ、今年4月からパブリックプレビューが始まっています（注21）。

2.7 Verifiable Credentialの実装

VCの標準化はW3Cで行われていますが、標準化の対象はデータモデルが中心で、細かい部分は実装によって大きく異なるのが現状です。CCIとLFPHによる解説文書（注22）は、こうした実装のバリエーションを複数の「フレーバー」として整理しています。

本稿では、Internet Identity Workshop（IIW）（注23）とその周辺で注目を集めているJSON-LD ZKP with BBS+というフレーバーを紹介します。JSON-LD ZKP with BBS+は、ニュージーランドのMATTR社が2020年4月のIIWで発表した比較的新しい方式です。コミュニティによって好意的に受け止められ（注24）、現在はMATTR社以外の技術者も加わってW3C Credentials Community Group（CCG）（注25）やDecentralized Identity Foundation（DIF）のCrypto WG（注26）において仕様策定や議論が進められています。開発はGitHub上でオープンに行われており（注27）、筆者もバグ修正などの貢献をしています。

JSON-LD ZKP with BBS+の特徴は、クレデンシャルの記述にJSON-LDというフォーマットを使う点と、デジタル署名方式としてゼロ知識証明と相性の良いBBS+署名を用いる点にあります。

BBS+署名はBBSグループ署名（注28）を拡張したマルチメッセージ型のデジタル署名です（注29）（注30）（注31）。楕円曲線暗号の一種で、ペアリングという演算を活用しています。一般的に使われているRSA署名やECDSA署名とは異なり、（1つのデータではなく） 複数のデータを並べたリストに署名を付けることが可能です。また、ゼロ知識証明と組み合わせやすい構造を備えており、署名したデータのリストから一部の要素を隠したまま署名の有効性を検証できたり、一部の要素を隠したままそれがある条件を満たすことだけを証明することもできます。

JSON-LD ZKP with BBS+では、JSON-LDで書かれたクレデンシャルをLD Canonicalizationという方法でstatementと呼ばれるデータに分解します。そしてstatementのリストに対してBBS+署名の生成や検証を行います。例えば図-3のJSON-LDクレデンシャルは図-4のようなstatementのリストに変換されてから署名されます。BBS+署名を使ってstatementのリストに署名を付けることで、statement単位で見せる/見せないの制御が可能になります。ただし、statementの中に含まれる値（氏名や生年月日など）を隠したまま、それらがある条件（例えば生年月日がある範囲に収まることなど）を満たすような高度な証明はまだ実現できていません。

拡大する

図-4 署名されるstatementのリスト（一部抜粋）。一行一行がstatementと呼ばれる

2.8 Verifiable Credentialの今後

VCやJSON-LD ZKP with BBS+の実用化に向けては解決すべき課題も残っています。ここでは代表的な3つの課題を示し、各課題の解決に向けたアプローチや動向を紹介します。

課題1：既存のアイデンティティ連携技術との相互運用性

VCという新しい概念と、既存のデジタルアイデンティティ関連仕様や製品との相互運用性の確保が第一の課題です。これに対してはOpenID Connectがもともと備えているSelf- Issued OpenID Provider（SIOP）という枠組みを使って、VC をOpenID Connectの上で扱う方法がOpenID Foundation （OIDF）で検討されています。検討にはJSON-LD ZKP with BBS+の提案者であるMATTR社の技術者も参加しています。

課題2：各種仕様の標準化

上で紹介したJSON-LD ZKP with BBS+やLD Canonicalization の仕様はいまだ議論の途中であり、標準仕様としては確立されていません。JSON-LD ZKP with BBS+に関しては上で述べたとおり、W3C CCGでの仕様策定とDIFのCrypto WGにおける議論が並行して行われています。検討の固まった内容から順にW3C仕様として標準化され、将来的な内容については後者のWGで検討や議論が重ねられていくようです。例えば、生年月日を明かさずに20歳以上であることだけを示すような高度な証明の実現方式については、後者のCrypto WG の議論対象に含まれています。LD Canonicalizationに関しては、W3Cで現在立ち上げ準備が進んでいるLinked Data Signatures WGの中で、RDF Dataset Canonicalization （RDC）やLinked Data Integrity（LDI）として検討が進む見込みです。本稿執筆時（2021年8月）のProposed Charter（注32）には、2021年9月から作業を開始し、2023年9月までの2年間でW3C Recommendation化を目指す旨が記載されています。

課題3：量子コンピュータへの耐性

3点目は長期的な課題として、本レポートのVol.49（注33）でも取り上げた「耐量子計算機暗号」に関する話題を紹介します。BBS+ 署名は楕円曲線上の離散対数問題の難しさに安全性の根拠を置いています。これは量子コンピュータによって効率良く解かれてしまうことが分かっている問題です。したがってBBS+署名やそれを用いるJSON-LD ZKP with BBS+方式は、残念ながら量子計算機への耐性を持ちません。それはHyperledger Indyが採用しているCamenisch-Lysyanskaya（CL）署名や、JWTでよく利用されるRSA、ECDSA、EdDSA署名も同様です。耐量子計算機暗号として知られる格子ベースの署名方式やZero-Knowledge Scalable Transparent Arguments of Knowledge（ZK-STARK）の応用も提案されていますが、実用に向けてはまだ性能向上を含めた改善の余地が多く残されている状況です。

2.9 おわりに

国内外で注目を集めるVCと、その実装形態の1つであるJSON-LD ZKP with BBS+フレーバーについて、現在の状況と今後の課題を紹介しました。個人的には、VCはこれまでのデジタル証明書やIDトークンをすべて置き換えてしまうものではなく、適材適所での使い分けが進むものと考えています。人、組織、モノのプライバシーが保護されるべき場面、特に提供するデータの最小化が望まれる場面でVCの真価は発揮されます。また、組織や業界にまたがる広い範囲でのデジタルアイデンティティ連携において、JSON-LDを使ったVCはその表現力と相互運用性の高いクレデンシャル記述を活かせます。実用化に向けた課題は山積していますが、関係団体による標準化や普及の活動を注視しつつ、コミュニティや社会の発展に向けて些少なりとも貢献していきたいと考えます。

1. （注1）ISO/IEC 24760-1ではアイデンティティを「エンティティに関する属性の集合」と定義しています。
2. （注2）Internet Infrastructure Review Vol.43「2. ブロックチェーン技術をベースとしたアイデンティティ管理・流通の動向」（https://www.iij.ad.jp/dev/report/iir/043/02.html）。
3. （注3）Alex Preukschat and Drummond Reed, “Self-Sovereign Identity - Decentralized digital identity and verifiable credentials”, Manning Publications, 2021/5（https://www.manning.com/books/self-sovereign-identity）。
4. （注4）鈴木 研吾、合路 健人「アイデンティティはだれのもの？ Hyperledger Indy & Aries で実現する分散アイデンティティ」 インプレスR&D, 2021/5（https://nextpublishing.jp/isbn/9784844379447）。
5. （注5）Internet Infrastructure Review Vol.26「1.4.3 ID管理技術」（https://www.iij.ad.jp/dev/report/iir/026/01_04.html）。
6. （注6）Verifiable Credentials Data Model 1.0（https://www.w3.org/TR/vc-data-model）。
7. （注7）本来、運転免許証は運転資格を持つことを示すためのクレデンシャルです。氏名、住所、性別、生年月日、顔写真という代表的な属性が揃っているため、一般に本人確認のためのクレデンシャルとして利用されることが多くなっています。政府目標としてマイナンバーカードとの一体化も掲げられています。
8. （注8）Stephen Curran, “Why Distributed Ledger Technology（DLT）for Identity?”, Hyperledger（https://www.hyperledger.org/blog/2021/04/21/why-distributed-ledger-technology-dlt-for-identity）。
9. （注9）CCI （COVID-19 Credentials Initiative）（https://www.covidcreds.org/）。
10. （注10）LFPH（Linux Foundation Public Health）（https://www.lfph.io/）。
11. （注11）Introducing the Global COVID Certificate Network（GCCN）（https://www.lfph.io/2021/06/08/gccn/）。
12. （注12）Vaccination Credential Initiative（VCI）（https://vaccinationcredential.org/）。
13. （注13）European Digital Identity - European Commission（https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en）。
14. （注14）Hyperledger Indy、Aries、Ursaを使ったKiva Protocol。シエラレオネ共和国はこのプロトコルを採用し、国民が小口融資を受けるための本人確認を約11秒で実施可能な基盤を構築したそうです（https://www.hyperledger.org/blog/2021/01/20/kiva-protocol-built-on-hyperledger-indy-ursa-and-aries-powers-africas-first-decentralized-national-id-system）。
15. （注15）IATA - Travel Pass Initiative（https://www.iata.org/en/programs/passenger/travel-pass/）。
16. （注16）慶應義塾大学、次世代デジタルアイデンティティ基盤の実証実験を開始　在学証明書や卒業見込証明書をスマートフォンアプリへ発行（https://www.keio.ac.jp/ja/press-releases/2020/10/26/28-75892/）。
17. （注17）Trusted Web ホワイトペーパー ver1.0（https://www.kantei.go.jp/jp/singi/digitalmarket/trusted_web/pdf/documents_210331-2.pdf）。
18. （注18）Hyperledger Indy（https://www.hyperledger.org/use/hyperledger-indy）。
19. （注19）Hyperledger Aries（https://www.hyperledger.org/use/aries）。
20. （注20）Hyperledger Ursa（https://www.hyperledger.org/use/ursa）。
21. （注21）本人確認ソリューション- Microsoft Security（https://www.microsoft.com/ja-jp/security/business/identity-access-management/verifiable-credentials）。
22. （注22）A Path Towards Interoperability: CCI Released a Paper on Different Flavors of Verifiable Credentials（https://www.lfph.io/2021/02/11/cci-verifiable-credentials-flavors-and-interoperability-paper/）。
23. （注23）Internet Identity Workshop（https://internetidentityworkshop.com/）。
24. （注24）Why the Verifiable Credentials Community Should Converge on BBS+（https://www.evernym.com/blog/bbs-verifiable-credentials/）。
25. （注25）BBS+ Signatures 2020, W3C Community Group Draft Report（https://w3c-ccg.github.io/ldp-bbs2020/）。
26. （注26）DIF - Applied Crypto Working Group（https://identity.foundation/working-groups/crypto.html）。
27. （注27）mattrglobal/jsonld-signatures-bbs: A linked data proof suite for BBS+ signatures（https://github.com/mattrglobal/jsonld-signatures-bbs/）。
28. （注28）Dan Boneh, Xavier Boyen, and Hovav Shacham, “Short Group Signatures”, CRYPTO 2004（http://dx.doi.org/10.1007/978-3-540-28628-8_3）。
29. （注29）Jan Camenisch and Anna Lysyanskaya, “Signature Schemes and Anonymous Credentials from Bilinear Maps”, CRYPTO 2004（http://dx.doi.org/10.1007/978-3-540-28628-8_4）。
30. （注30）Man Ho Au, Willy Susilo, and Yi Mu, “Constant-Size Dynamic k-TAA”, SCN 2006（http://dx.doi.org/10.1007/11832072_8）。
31. （注31）Jan Camenisch, Manu Drijvers, and Anja Lehmann, “Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited”, Trust 2016（http://dx.doi.org/10.1007/978-3-319-45572-3_1）。
32. （注32）Linked Data Signatures Working Group Charter（https://w3c.github.io/lds-wg-charter/index.html）。
33. （注33）Internet Infrastructure Review Vol.49「2. 耐量子計算機暗号の動向2020」（https://www.iij.ad.jp/dev/report/iir/049/02.html）。

2. フォーカス・リサーチ（1） Verifiable CredentialとBBS+署名

• 2.1 はじめに
• 2.2 クレデンシャルと Verifiable Credential
• 2.3 Verifiable Credentialの利用イメージ
• 2.4 Verifiable Credentialのエコシステム
• 2.5 Verifiable Credentialと 従来のデジタル証明書の違い
• 2.6 Verifiable Credentialに関する 国内外の動向
• 2.7 Verifiable Credentialの実装
• 2.8 Verifiable Credentialの今後
• 2.9 おわりに