Verifiable Credentialと画像を用いたSSOの実証
と課題点

Copyright © 2023 chaintope Inc. All rights reserved.
自己紹介
2
● Yukishige Nakajo
● 株式会社chaintope
Chief Ethereum Researcher
● core research
○ EVM, Beacon chain consensus
○ go-ethereum implementation
○ truffle
● twitter: @nakajo
● blog:
https://y-nakajo.hatenablog.com/
https://goblockchain.network/

Copyright © 2023 chaintope Inc. All rights reserved.
今日の話すこと
3
1. 実証のポイント
2. 実証で作成したシステムの構成
3. DIDとVCとは何か？
4. DID/VCを実際に用いる際の課題

Copyright © 2023 chaintope Inc. All rights reserved.
実証ポイント
4
1. 目視確認もできる様に画像にVerifiable Credentialを埋め込み※1たい。
2. Verifiable Credentialを埋め込んだ画像を認証に用いたい
※2。
3. 一番わかりやすい認証＝ログイン
4. Verifiable Credentialをログインに用いるため、今回は
OpenIDと簡易的に融合させた
※3。

Copyright © 2023 chaintope Inc. All rights reserved.
システム構成
5
ID Provider / VC Issuer
Resource Provider
PNG chunk
Verifiable Data Registry
(Nginx, did:web)
1. 登録
2. 発行
＜
3. 画像でlogin
4. did:webで検証
5. userInfo要求
画像の保有者であるとい
うclaim
subjectは保有者。一意
のidを発行
6. ログイン要求
・アクセス許可

Copyright © 2023 chaintope Inc. All rights reserved.
一般的なOpenID Connect
6
https://www.slideshare.net/oidfj/openid-connect-intro-september-2013 より
この部分をVCを
使って省略

Copyright © 2023 chaintope Inc. All rights reserved.
Verifiable Credentialの一般構成
7
ID Provider
が兼任
Resource
Providerが兼任
did:webを利用

Copyright © 2023 chaintope Inc. All rights reserved.
DIDとVerifiable Credentialの整理
8
DID
● 人物・物・データ等何かしらの Entityを識別するだけのもの。 (Identifier)
● 属性情報(名前や年齢など)は一切持たない。
● 唯一、claimを表現可能とするために検証可能な鍵情報と紐づいているのみ
Verifiable Credential
● 1つもしくは複数のclaimを表す物。
● これ自体はIDではなく、資格情報であり属性情報。
● Entityを表すのにDIDは不要。
● Issuerが発行したこと・内容が改ざんされていないことが検証可能でなければなら
ない。
● Privacyに配慮して、必要最低限の情報しか載せない。
(ex: 18歳以上であることを示すために、誕生日を記載するのは開示しすぎ。 )

Copyright © 2023 chaintope Inc. All rights reserved.
Verifiable Credential発行までの流れ
9
1. CredentialのClaimで使うためのschemaを策定
2. schemaを表現するcontextを策定
3. Verifiable Credentailの発行機能(Issuer)を実装
4. Verifiable Credentialの検証機能(Verifier)を実装
5. DID Documentをwebサーバ(今回は自前のNginx)に配置
6. Verifiable Credentialを発行
● 1.と2. を策定するのが大変。
○ claimは自由に定義可能。
○ claimはPrivacyに配慮して最低限、もしくはゼロ知識であるのが好
ましい※4。
○ claimのサンプルが増えてくると利用が加速していくのかも？
● claimのschemaが個別に異なるため、Verifier = Issuerの構造になりや
すい。

Copyright © 2023 chaintope Inc. All rights reserved.
contextとは
10
画像の所有者を表す
context（独自定義） credentialのcontext定義
(https://www.w3.org/2018/credentials/v1)
● Issuer - Holder - Verifier間でVCの（機械的な）解釈を統一させるためのもの。
● Verifiable Credentialに含まれるparameterと型情報などを定義するもの。
● JSON-LD形式で定義する。人間が可読可能なドキュメント形式でも可。
● XMLSchemaなど標準でさまざまな typeも定義されている。

Copyright © 2023 chaintope Inc. All rights reserved.
理想的なVerifiable Credential発行の流れ
11
Issuer Holder Verifier
1. 認証要求
2. 必要なclaimと
Issuerを指示
3. VC発行依頼
4. VC発行 or 拒否
5. VCの提出
Verifiable Data Registry
6. VCの検証
7. OK / NG
● 必要となった時に、最低限の情報のみを持つ VCが発行できることが望ましい。
● 実現のためには、2. と 3. を可能にするプロトコル定義が必要

株式会社chaintope
Chief Ethereum Researcher
中城 元臣
info@chaintope.com
12

Copyright © 2023 chaintope Inc. All rights reserved.
Appendix
13
※1. OpenBadgeのbakingをVCで利用可能であるかの検証も見越しての仕様。
https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/baking/index.html
※2. 証明書関連は検証方法として目視確認も求められるため。
※3. DID + OpenIDの標準仕様はすでにある。が、今回はこれに準拠したいわけではなく、 VCを使っ
た何らかのシステム構築が目的。
https://openid.net/specs/openid-connect-self-issued-v2-1_0.html
※4. Verifiable Credetialの仕様にPrivacyに十分に配慮する必要性が記載されている。
https://www.w3.org/TR/vc-data-model/#privacy-considerations