見出し画像

VCの基本

こんにちは!Recept代表の中瀬です。

本日はVCについて書きます。

VCとは一言で

VCとは、第3者が検証可能なデータ規格のことです。

今まで、個人関連情報を第3者が検証しようとすると、それが偽装されたものであるかどうかを確認することが困難でかつ、データの規格がバラバラだったためシステマチックに検証することができませんでした。

VCをどのように利用するのか


VCを利用するときは上記のようなステークホルダーが存在します。

保持者にVCを与える発行者、VCを保有する保持者、保有するVCを検証する検証者です。

そしてこれらのステークホルダーが通信するのがレジストリとなっていて、このレジストリはブロックチェーンまたは信頼できる第3者的なデータベースになります。

一般的にDIDやVCの話をするときはブロックチェーンで語られることが多いです。

その理由はブロックチェーンの方がよりSSIな思想の実現に近いということがあげられます。

要は、誰かの所有物であるレジストリでは、保存されているデータが改ざんされていないことや、単一障がい点になって攻撃されてしまうというリスクがあると考えられるため、ブロックチェーンの方がよりSSIの実現に近づくと考えています。

発行者がVCを発行する際は、レジストリで保持者のDIDが正当かどうか検証したり、スキーマを取得してスキーマ通りにVCを発行したりします。

保持者はアカウント作成時にDIDを登録したりすることでレジストリとの通信が行われます。

検証者はレジストリと通信して、提示されたVCの検証を行います。

実際にVCはどんなデータなのか

VCはJSONのような形をしたデータになっています。

それぞれのプロパティがW3Cによって定義されていて、その定義通りにVCを作れば、相互運用性をもつことができます。

このW3Cによって定義されたVCのプロパティの中でもいくつか重要なものを紹介しようと思います。

type

typeには、文字列の配列のデータを入れることができます。

基本的には、VerifiableCredentialsかVerifiablePresentationが入ります。

VerifiablePresentationについては別の記事で書きます。

また、運転免許証のVCの場合は、DriversLicenseなど、そのVCが何を示すのかという大分類を示すプロパティでもあります。

credentialSubject

credentialSubjectには、そのVCが表現する資格情報が入ります。

運転免許証の場合、運転免許証に書いてある氏名や住所、免許の種類が記載されます。

運転免許証が原付専用なのか、普通自動車も乗れるのか、などの検証を行う際はこのcredentialSubjectの中の値を確認することで検証することができます。

実はcredentialSubjectの中のプロパティはW3Cによって定義されているものではありません。

つまり、ユースケースによって誰かが運用のルールを決める必要があります。

これには、各業界団体や政府などのトップダウン的な決めが必要です。

弊社でも年齢確認や、学生証などのVC化を進めていきますが、データ規格の策定段階では相互運用可能な設計にすることはもちろん、適切な団体と協議することが必要です。

proof

発行者によって発行されたVCにはproofというプロパティが付いています。

ここには発行者による署名のデータが入っています。

検証者はこのproofのデータを発行者の公開鍵で検証することで、VCが本当に発行者によって発行されたものであることを確認することができます。

VCの課題点

そんなVCでもいくつかの課題が存在します。

①発行者の信頼性

仮にVCによって発行者が発行したものであることが担保できたとして、その発行者が本当に信頼できる人なのかどうかを検証することができません。

これは、DID/VCのネットワークに発行者が参入する際にチェックするしかないです。

ホワイトリスト的にチェックするのかどうか、手法は様々ですが、そもそも信頼できない人がVCを発行できるような仕組みにしないようにするしかないです。

②credentialSubjectの規格の統一

仮にあらゆる大学の卒業証書データの検証をワンストップで実現するとして、それにはデータの規格を統一する必要があります。

例えば、私の卒業証書データが「理工学部」の卒業証書かどうかを判定したいようなユースケースを考えてみます。

この場合、卒業証書のデータの中の、「学部名」のデータの中の値を確認する必要があります。

このときに、credentialSubject内の学部名を表すプロパティ名が発行体によってバラバラだと相互運用性がありません。

これは業界団体や政府など、業界全体を巻き込んでルールを決めていく必要があります。

まとめ

VCの基本と、その課題について書いてみました。

DID/VCがIDTechという産業においてイノベーションを起こすという期待とは裏腹に、まだまだ課題点も存在します。

これらを克服して実装を進める必要がありますし、そのために大きな組織を動かさないといけない場合もあると思います。


この記事が気に入ったらサポートをしてみませんか?