SSIとDIDで
何を解決したいのか？
（β版）
Naohiro Fujie
2019/04/23
Copyright 2019 Naohiro Fujie 1

前提など
• 課題設定、仕様調査などはまだまだ浅めです
• 本日人数を絞ったのもざっくばらんな意見交換をしたかったか
らなので、途中でもよいので疑問、意見などは積極的に発言い
ただければと思います
• 議論を通じで本資料を育てていけると良いな、と
• 資料は後で共有します（議論の結果を反映できると嬉しい）
Copyright 2019 Naohiro Fujie 2

Self Sovereign Identityとは何ぞや
• 自己主権型アイデンティティ（SSI）とは、個人は、管理主体
が介在することなく、自身のアイデンティティを所有しコント
ロールできるべきである、と考えるデジタル・ムーブメントを
表す言葉である。SSIを使うと、人々は現実世界で彼らが行っ
ているのと同じ自由度と信頼性をもってデジタル世界でも活動
することが出来る。
• https://sovrin.org/faq/what-is-self-sovereign-identity/
• 抄訳：ふじえ
Copyright 2019 Naohiro Fujie 3

SSIがデジタル化を目指す現実世界の体験
（できているかどうかは別として）
自分自身でコンテキストに応じてアイデン
ティティを使い分けることが可能な世界
Copyright 2019 Naohiro Fujie 4

デジタル化にあたっての考慮点①
現実世界 デジタル世界
識別の精度 不確実（アナログ）
⇒照合は難しい
識別情報を使いデジタルに
識別
⇒容易に照合できてしまう
情報の保持・維
持
記憶が頼り、忘れられる可
能性
⇒拡散しても忘れてくれる
確実に記録される
⇒一度拡散すると実質は消
去不能
記憶に残っている可能性 記録が消えると本当に消え
る
デジタルなので、良くも悪くも正確・確実
Copyright 2019 Naohiro Fujie 5

デジタル化にあたっての考慮点②
自分に分かっている 自分に分かっていない
他人に分かってい
る
開放の窓 盲点の窓
他人に分かってい
ない
秘密の窓
⇒プロファイリング対象の
象限
未知の窓
⇒AI/BigDataにより、よ
り深いプロファイリング～
マネタイズ対象となってき
ている象限
ジョハリの窓でいうところの秘密・未知の象限を探索されやすい
Copyright 2019 Naohiro Fujie 6

これまで と これから
少しこれまでの経緯をさかのぼることで、SSI勢が設定している課題は何な
のか？を紐解きましょう
Copyright 2019 Naohiro Fujie 7

個別認証の時代
⇒それぞれで受付、ID提示
Copyright 2019 Naohiro Fujie 8

個別認証の時代
⇒それぞれで受付、ID提示
非効率で不便
Copyright 2019 Naohiro Fujie 9

シングルサインオン（Proxy型）
⇒中央で受付、ID提示
Copyright 2019 Naohiro Fujie 10

シングルサインオン（Proxy型）
⇒中央で受付、ID提示
ボトルネック
SPOF
Copyright 2019 Naohiro Fujie 11

シングルサインオン（Proxy型）
⇒中央で受付、ID提示
スケールアウト
Copyright 2019 Naohiro Fujie 12

シングルサインオン（Federation）
⇒事務所で受付、結果を持ちまわる
Copyright 2019 Naohiro Fujie 13

シングルサインオン（Federation）
⇒事務所で受付、結果を持ちまわる
SPOF
受付結果は本物？
Copyright 2019 Naohiro Fujie 14

シングルサインオン（Federation）
⇒事務所で受付、結果を持ちまわる
真贋確認
（Phone Home）
スケールアウト
クラウド化
Copyright 2019 Naohiro Fujie 15

まだまだ課題は残る
問い合わせ元で
行動把握が可能
結託されると
行動把握が可能
Copyright 2019 Naohiro Fujie 16

まだまだ課題は残る
問い合わせ元で
行動把握が可能
結託されると
行動把握が可能
Copyright 2019 Naohiro Fujie 17
プライバシーの課題
ジョハリの窓でいう、
秘密の窓と未知の窓への侵入

まだまだ課題は残る
問い合わせ元で
行動把握が可能
結託されると
行動把握が可能
Copyright 2019 Naohiro Fujie 18
KYC的な課題
IdPへの問い合わせコスト
IdPで属性更新が行われてもユーザがログイン
するまでRPは更新を知りえない

DIFモデル
個別会員カード＋チケットの半券
Copyright 2019 Naohiro Fujie 19
割り印でもいいかも
良いメタファーが浮かばない

DIFモデル
個別会員カード＋チケットの半券
公共の掲示板に
半券を掲示
個々の会員証を
利用し名寄せ防止
チケットの半券の
突合で真贋確認
チケットも個別に
発行、名寄せ防止
Copyright 2019 Naohiro Fujie 20

SIOPでいいのでは？
RPでの紐づけもsub_type=pairwiseでいいし
Copyright 2019 Naohiro Fujie 21

DIFモデルが成立するために必要なもの
堅牢な掲示板上の
会員と関連する半券
会員カードとチケット
を入れておく財布
個人情報を確認
できる書類
Copyright 2019 Naohiro Fujie 22

DIFモデルが成立するために必要なもの
DID/DID Document
on Ledgers
User Agent
Identity Hub
Copyright 2019 Naohiro Fujie 23

Copyright 2019 Naohiro Fujie 24

コンポーネントとイベント
コンポーネント 概要
User Agent いわゆるIdentity Wallet。スマホアプリやブラウザExtensionとして実装される。
鍵ペアの生成とDIDの登録、DID Authにおける認証器の役割を果たす
Identity Hub DIDに関連するIdentity情報を保存する
Distributed Ledger DIDとDID Documentを記録する分散台帳
Universal Resolver 他の台帳上にあるDID Documentを解決する
Verifiable
Credentials
第3者から発行された検証可能なアイデンティティ情報（を表すデータ構造の
標準）
イベント 概要
DID Registration DIDとDID Documentを台帳上に登録すること
DID Authentication DIDが主体の制御化にあることを証明すること
以降、MicrosoftのDID Projectを使って解説していきます。
https://didproject.azurewebsites.net/
注意）結構な頻度でDID関係のエンドポイントのAレコードが消えます
Copyright 2019 Naohiro Fujie 25

言い換えるとこんな感じ？
コンポーネント 概要
User Agent 財布とキャッシュカード
Identity Hub 銀行の顧客データベース
Distributed Ledger 銀行の顧客台帳（インデックスのみ）
Universal Resolver ー
Verifiable
Credentials
銀行口座を開設する際に提示した公的証明書
イベント 概要
DID Registration 銀行口座の開設を行うこと
DID Authentication キャッシュカードの持ち主であることを証明すること
（登録されている個人情報が正しいことの証明ではない）
Copyright 2019 Naohiro Fujie 26

DID（Decentralized Identifier）
• User Agentが鍵ペアを生成する時に付与される識別子
• フォーマット
• [スキーム]：[メソッド]：[メソッド固有の識別子]
• 例）did:sov:123456789abcdefghi
• メソッド一覧
• https://w3c-ccg.github.io/did-method-registry/
• 仕様
• https://w3c-ccg.github.io/did-spec/
Copyright 2019 Naohiro Fujie 27

DID Document
• DIDに関連するデータモデルをシリアライズしたもの
• 仕様
• https://w3c-ccg.github.io/did-spec/
• 中身（JSON-LDで記述）
要素 内容 例
@context 要はスキーマ定義
（標準＋メソッド固有の定義が可能）
https://w3id.org/did/v1
（デフォルト）
id DID Documentが差し示す主体のDID did:example:123456789abcdefghi
publicKey 認証やサービスエンドポイントへのアク
セスに使われるデジタル署名の検証用
- id, type：鍵ID毎に形式を定義
- controller：対応する秘密鍵の管理主体
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyPem": "-----BEGIN PUBLIC KEY...
END PUBLIC KEY-----¥r¥n"
Copyright 2019 Naohiro Fujie 28

要素 内容 例
authentication DID主体の認証方式
（認証専用の公開鍵を使う場合はこのセ
クションにpublicKeyを書く）
"did:example:123456789abcdefghi#keys-1",
"did:example:123456789abcdefghi#biometric-1",
{“id”: “did:example:hoge”, “type”:”Rsa…”}
authorization
and
delegation
鍵のリカバリなどの際にDID主体の替わり
に振舞うことのできるDIDに関する情報を
記載（未定義）
議論中っぽい
（guardianとかauthenticationを使う感じ）
service DID主体が公開したいサービスに関する情
報を記載
- id, type : エンドポイントIDとアクセス
方法
- serviceEndpoint : エンドポイントのURI
"id": "did:example:123456789abcdefghi;openid",
"type": "OpenIdConnectVersion1.0Service",
"serviceEndpoint": "https://openid.example.com/"
created DID Documentが生成された日時 "created": "2002-10-10T17:00:00Z"
updated DID Documentが更新された日時 "updated": "2016-10-17T02:41:00Z"
proof DID Documentの完全性の証明
※DIDとDID Documentが紐づいていると
いう証明ではない
"type": "LinkedDataSignature2015",
"created": "2016-02-08T16:02:20Z",
"creator": "did:example:8uQhQ…1ja#keys-1",
"signatureValue": "QNB13Y7Q9...1tzjn4w=="
Copyright 2019 Naohiro Fujie 29

DID Documentのサンプル
{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefghi",
"publicKey": [{
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----¥r¥n"
}],
"authentication": [
"did:example:123456789abcdefghi#keys-1“
],
"service": [{
"type": "OpenIdConnectVersion1.0Service",
"serviceEndpoint": "https://openid.example.com/"
}]
}
Copyright 2019 Naohiro Fujie 30

DID、DID Documentの扱い
• DIDとDID Documentは共有台帳上に配置される
• ブロックチェーンである必要はない
• 台帳は対象ネットワーク内でデータのレプリケーションを行う
• DID、DID Document上に個人識別情報（PII）は存在しない
• Walletが鍵を管理し、公開鍵を台帳上に公開
• このことにより、Issuerがクローズしたとしても、クレデン
シャルのVerifyが可能となる
Copyright 2019 Naohiro Fujie 31

DID、DID Documentの生成と公開
• 以下の手順
1. 鍵ペアの生成
2. メソッド、Identity Hubのエンドポイントと生成した公開鍵を合わせ
てJWSにして登録エンドポイントへPOST
3. DIDが生成され返却される
4. しばらくするとDID Documentが台帳上に書き込まれる
Copyright 2019 Naohiro Fujie 32

公開鍵を読み込み、JWKへ
メソッド、serviceEndpoint、
publicKeyを指定（Body）
秘密鍵で署名してJWSを生成
Copyright 2019 Naohiro Fujie 33

生成したJWSの中身
Copyright 2019 Naohiro Fujie 34

生成したJWSを
https://beta.register.did.microsoft.com/api/v1.1
へPOST（Content-Type: application/jwt）
Copyright 2019 Naohiro Fujie 35

didが採番される
DID Documentは登録中（in-progress）
Copyright 2019 Naohiro Fujie 36

https://beta.register.did.microsoft.com/api/v1.0/{did}
をGETして登録状況を確認
登録完了（registered）
Copyright 2019 Naohiro Fujie 37

https://beta.dicsover.did.microsoft.com/v1.0/identifiers/{did}
をGETして登録されたDID Documentを確認
Copyright 2019 Naohiro Fujie 38

{
"document": {
"@context": "https://w3id.org/did/v1",
"id": "did:test:46d778b1-1970-4291-a726-92be0b060bbc",
"created": "2019-04-10T15:40:48.526Z",
"publicKey": [
{
"id": "did:test:46d778b1-1970-4291-a726-92be0b060bbc#key-1",
"type": "RsaVerificationKey2018",
"publicKeyJwk": {
"kty": "RSA",
"n":
"5nT4ALaq4Puj138jXjG43Nyc_mpw_QSKORVDuKG6haOrX01YQ9APHH6a14NZVIJQ0vcqk8l6-
6VlrmbOTU7Q02MPsDXzaVfe1CuSHU27Vk7qhJpAD0wMdYuL6GQtk53BaafTVh3wXnFpq8b7UlVJugLzUNKIwMau
ZIXIC_IRtzXPrzuinYOzlBaxPYAmSVQU_X3yO6Uhp3wiWsFwi76Rj0LfjeLNOdvJ93X8yMWUtdUedYrVpc8PEUA
zTZ1COx7hsgPRv96JmZEZNVRY2RdUkMylEtS_KajDCCeWup8WV1qbwGkNMzh1xXun3UCQ_FhgbZEte7hKKInGso
EV_XF22w",
"e": "AQAB",
"kid": "did:test:46d778b1-1970-4291-a726-92be0b060bbc#key-1"
},
"owner": "did:test:46d778b1-1970-4291-a726-92be0b060bbc"
}
], Copyright 2019 Naohiro Fujie 39

"service": [
{
"type": "IdentityHub",
"publicKey": "did:test:46d778b1-1970-4291-a726-92be0b060bbc#key-1",
"serviceEndpoint": {
"@context": "schema.identity.foundation/hub",
"@type": "UserServiceEndpoint",
"instances": [
"did:test:hub.id"
]
}
}
]
},
"resolverMetadata": {
"driverId": "did:test",
"driver": "HttpDriver",
"retrieved": "2019-04-10T15:47:10.879Z",
"duration": "60.4683ms"
}
} Copyright 2019 Naohiro Fujie 40

User Agent
• スマホアプリやブラウザExtension
• 役割
• 鍵ペアの生成
• 秘密鍵はSecure Storageへ
• 公開鍵は台帳上のDID Documentへ
• イメージはセキュアなパスワードマネージャ
• DID Authの認証器
• 複数のDIDと紐づく秘密鍵を保持
• 財布の中に複数の会員カードが入っているイメージ
Copyright 2019 Naohiro Fujie 41

MS DID ProjectのChrome Extension
先ほどのDID登録をWalletから実行可能
Copyright 2019 Naohiro Fujie 42

MS DID ProjectのChrome Extension
Copyright 2019 Naohiro Fujie 43

Identity Hub
• クラウドやサーバにホストされる常時稼働しているアプリケー
ション
• Smart Contractにより個人の代わりに決定をしたり、データを
共有したり、処理を行う
• DID Documentにエンドポイントの情報が記載されている
Copyright 2019 Naohiro Fujie 44

ここはDID Auth
DID、Private Key、DID
Resolver Endpointでログオン
Copyright 2019 Naohiro Fujie 45

Copyright 2019 Naohiro Fujie 46

以下の順でIdentity Hubへアクセス
• DID主体のDID Documentを取得
• DID Document内のserviceのtypeが”IdentityHub”のモノを取得、
instancesからIdentity HubのDIDを取得
• did:test:hub.id
• Identity HubのDIDからDID Documentを取得
• /1.0/identifiers/did:test:hub.id
• DID Document内のserviceよりIdentity HubのLocationを取得
• Identity HubのI/F定義はdiscoveryエンドポイントから取得
• https://beta.hub.microsoft.com/.well-known/hub-configuration
• 現状はMSのIdentity Hubでは動作せず
Copyright 2019 Naohiro Fujie 47

"service": [
{
"type": "IdentityHub",
"publicKey": "did:test:hub.id#HubSigningKey-
RSA?9a1142b622c342f38d41b20b09960467",
"serviceEndpoint": {
"@context": "schema.identity.foundation/hub",
"@type": "HostServiceEndpoint",
"locations": [
"https://beta.hub.microsoft.com/"
]
}
}
]
Copyright 2019 Naohiro Fujie 48

{
"@context": "https://schema.identity.foundation/1.0/hub",
"@type": "IdentityHubConfiguration",
"endpoints": [{
"@context": "http://schema.identity.foundation/1.4/hub",
"@type": "InterfaceMap",
"interfaces": {
"Collections": "https://hub.azure.com/Collections",
"Profile": "https://www.foo.com/whatever-path/Profile",
"Actions": "https://id.bar.org/.identity/Actions"
}
}],
"signature": {
"kid": "did:btcs:456#key-1",
"value": "jv9323lavjsdav0d9ada2...",
"timestamp": "2018-10-24T18:39:10.10:00Z"
}
}
Copyright 2019 Naohiro Fujie 49

DID Auth
• DID Authの目的
• DIDをコントロールできる主体であることを相手に示すこと
• 基本は以下のやり取りで成り立つ
• Relying PartyからIdentity OwnerへのChallengeの送信
• Identity OwnerからRelying PartyへのResponseの送信
• 認証方法はDID Documentのauthenticationオブジェクトの
typeプロパティで指定する
• Biometrics
• PKI
• WebAuthn
• OpenID Connect
Copyright 2019 Naohiro Fujie 50

基本パターン
Copyright 2019 Naohiro Fujie 51

Relying PartyからIdentity Ownerへの
Challengeの送信方法のパターン
パターン 構成
DID Auth ServiceへのPOSTする Relying PartyがIdentity OwnerのDID Documentから
Authentication Service EndpointをLookupし、Challengeを
POSTする
モバイルアプリでQRコードを読
み込む
Relying PartyがChallengeをエンコードしたQRコードを表示、
Identity Ownerがモバイルアプリで読み込む
Deep Linkやカスタムプロトコル
ハンドラーでモバイルアプリを起
動する
did-auth:jwt/…
<a href=‘did-auth:jwt/…’>Login with DID</a>
UserAgentのJavaScript APIを起
動する
Relying PartyがIdentity OwnerのUserAgentのJavaScript APIを
起動する
Formリダイレクト SAMLやOpenID Connectのform_postの様にHTML FORMを
Identity Ownerに送信し、DID Auth Serviceへ自動POSTさせる
Device間通信 BluetoothやNFC、Wifiなどでデバイス間で直接送信する
Copyright 2019 Naohiro Fujie 52

Identity OwnerからRelying Partyへの
Responseの返信方法のパターン
パターン 構成
Callback URLへのPOST Challenge内もしくはRelying PartyのDID Document内に指定さ
れるCallback URLへPOSTする
モバイルアプリでQRコードを読
み込む
Identity OwnerがResponseをエンコードしたQRコードを表示、
モバイルアプリで読み込むことでRelying Partyへ送信する
JavaScriptのpromiseを使う JavaScript API経由で送信されたChallengeを受け取った後、
promiseでResponseを返信する
Device間通信 BluetoothやNFC、Wifiなどでデバイス間で直接送信する
Copyright 2019 Naohiro Fujie 53

事前準備Relying PartyのDIDを登録
Copyright 2019 Naohiro Fujie 54

Copyright 2019 Naohiro Fujie 55

Chrome ExtensionでChallengeを拾って
Callback URIへPOSTする
document.addEventListener('did-auth', function(request) {
const challenge = {
client_id: request.detail.client_id,
};
chrome.runtime.sendMessage(challenge);
});
auth.signAuthenticationRequest(authRequest).then(function (authReqJws) {
res.send(authReqJws)
}).catch(function (error) {
res.status(500).send(error)
})
app.post('/auth-response', textParser, function (req, res) {
auth.verifyAuthenticationResponse(req.body).then(function(authResponse) {
if (authResponse.nonce != req.session.id)
throw 'Nonce in auth response did not match nonce in session cookie.’
req.session.did = authResponse.sub;
res.status(200).json();
Challengeの生成と署名
Chrome Extensionで
Challengeを拾う
POSTされたResponseを
パースする
Copyright 2019 Naohiro Fujie 56

Challenge（RPの秘密鍵で署名したJWS）
{
"iss": "did:test:a7d252d8-5444-4e27-8640-f4e1e4781e9c",
"response_type": "id_token",
"client_id": "http://localhost:8080/auth-response",
"scope": "openid",
"nonce": "Ib7UnVO03wAyX-m6p2oNXVeWYAo2LchY"
}
Relying PartyのDID
Copyright 2019 Naohiro Fujie 57

Response（ユーザの秘密鍵で署名したJWS）
{
"iss": "https://self-issued.me",
"sub": "did:test:6e81e266-ccc0-4e5d-94ab-7de0fa163261",
"aud": "http://localhost:8080/auth-response",
"nonce": "Ib7UnVO03wAyX-m6p2oNXVeWYAo2LchY",
"exp": 1555838161,
"iat": 1555837861,
"sub_jwk": {
"kty": "RSA",
"kid": "did:test:6e81e266-ccc0-4e5d-94ab-7de0fa163261#master",
"e": "AQAB",
"n":
"ysaow9MimDhiZirq2DHsTi24P_qRr1V2gOOM177qGGbH7rNjrFVktdHU0kPSyP4XDyJ5gGlCsQRWn5mqiyycfzI2pYm2MnS9INiCIXJY
VYP3DUvb_8NwHbyWgjUDTkymIbb5PSiIujzpxN6wymJiJpGyub0hp2O0PMjtQdoSvgixvyWP_j7tVFmzzSSCINumlK2WJ8vM_i1j0AgMQ
sICa7H-8aN6xhkwmtd-yt0pI2rFC-
1JrmrF1BVTSn8UKLFdSNYN5A8dt3yKgNfrg5Yj0w9qVawfm32IR5MzCtdit6V1h9u65d6IXEVp7wFGzhMfn8gdjJG98KZeZ8WckXPASQ",
"defaultEncryptionAlgorithm": "RSA-OAEP"
},
"did": "did:test:6e81e266-ccc0-4e5d-94ab-7de0fa163261"
}
ユーザのDID
Copyright 2019 Naohiro Fujie 58

Verifiable Credentials
• サードパーティ（Issuer）によって確認・発行されたユーザに関す
るデータの一部（学位など）
• Issuerは自身の秘密鍵でCredentialに署名する
• User AgentにVerified Credentialsとして発行する
• Identity Hub上で管理する
• アプリケーション（Relying Party=Verifier）はIssuerのDID
Document上の公開鍵でCredentialの検証を行う（Issuerへ直接問い
合わせを行う必要はない）
• Issuerが消滅してもVerified CredentialsはIdentity Hub上に、検証
用の公開鍵は台帳上のDID Documentに残るので引き続き検証可能
Copyright 2019 Naohiro Fujie 59

Issuerが発行した検証可能な属性のセット
一つ以上のVerifiable Credentialsより派生
した検証可能なデータ表現
Verifiable CredentialsとVerifiable Presentations
Copyright 2019 Naohiro Fujie 60

Verifiable CredentialsとVerifiable Presentations
• 直接Verifiable Credentialsを提示しても良い
• Verifiable CredentialsのすべてのClaimsをVerifierに提示する
必要が無いケース、複数のVerifiable Credentialsをまとめて
Verifierに提示したいケースなどにおいては、Verifiable
Presentationsを利用する
Copyright 2019 Naohiro Fujie 61

Verifiable Credentials/Presentations
要素 内容 例
@context 要はスキーマ定義
（標準＋メソッド固有の定義が可能）
https://www.w3.org/2018/credentials/v1
（デフォルト）
id Verifiable Credentials自体の識別子 http://example.edu/credentials/3732
type 本データのタイプの定義 VerifiableCredential
credentialSubj
ect
Credentialsが指し示す主体および属性 “id”: “did:example:ebfeb1f712ebc6f1c276e12ec21”,
"degree": {
"type": "BachelorDegree",
"name": "Baccalauréat en musiques numériques"
}
issuer 発行者のURI※JWK_URIやDIDでも可 https://example.edu/issuers/14
issuanceDate 発行日時 2010-01-01T19:23:24Z
proof デジタル署名に関する情報 "type": "RsaSignature2018",
"created": "2018-06-18T21:19:10Z",
"verificationMethod": "https://foo.com/x/keys/1",
"signatureValue": “…………"
Copyright 2019 Naohiro Fujie 62

Verifiable Credentials/Presentations
要素 内容 例
expirationDat
e
有効期限 2020-01-01T19:23:24Z
credentialStat
us
Credentialのステータス（停止、取り消し
などの状態）
"id": "https://example.edu/status/24",
"type": "CredentialStatusList2017"
verifiableCred
ential
入れ子にするVerifiable Credentials {
“@context”: “”,
“id”: “http://aaa”,
…
Copyright 2019 Naohiro Fujie 63

やり取りの方法
• W3CではVerifiable
Credentials/Presentationの
データ構造までは定義してい
るが、やり取りの方法につい
ては標準化していない
• 結果、各実装者毎の方法が乱
立している状態となっている
• Sovrin：ゼロ知識証明
• uPort : attestation
Copyright 2019 Naohiro Fujie 64

オマケ
Copyright 2019 Naohiro Fujie 65

ベースとなる関連技術と（黒）歴史？
これまでの実装
• U-Prove/Microsoft
• https://www.microsoft.com/en-us/research/project/u-prove/
• Idemix（Identity Mixer）/IBM
• https://www.zurich.ibm.com/identity_mixer/
• 認証時にIssuerへ問い合わせをしない
• Verifierからの要求に応じてユーザ自身が選択的に属性を提示する
関連技術
• ゼロ知識証明
• Verifier（RP）はProver（User）が正しいことを、Proverの知っている知識をVerifierに伝える
ことなく知りたい
• VerifierとIssuerのやり取りをなくす
• 匿名認証（グループ署名）
• 署名者を特定せずに検証を可能とする
Copyright 2019 Naohiro Fujie 66

Microsoft U-Prove
• Untraceability
• U-ProveトークンにIssuerの署
名や公開鍵の情報を含まない
• トークン発行から利用の間での
紐づけを行うことが出来ない
• Unlinkablity
• 同じProverのトークンであった
としても、トークン同士の紐づ
けを行うことは出来ない
Copyright 2019 Naohiro Fujie 67

IBM IdeMix
• Flexible public keys
• Pseudonymsと呼ばれる独立し
た複数の公開鍵を一つの秘密鍵
と紐づける
• Flexible credentials
• トークンに含める属性をユーザ
が選択・変更したとして、改変
後の公開鍵でトークンの検証が
出来る
Copyright 2019 Naohiro Fujie 68

もっと深い黒歴史も・・・
（HailStorm, CardSpace）
Copyright 2019 Naohiro Fujie 69

結局課題解決になるのか？
Copyright 2019 Naohiro Fujie 70

プライバシの課題
問い合わせ元で
行動把握が可能
結託されると
行動把握が可能
Copyright 2019 Naohiro Fujie 71

Copyright 2019 Naohiro Fujie
プライバシの課題への対応？
個々の会員証を
利用し名寄せ防止
チケットも個別に
発行、名寄せ防止
72

KYCの課題
問い合わせコスト
ログインしないと
IdPの属性更新を知
りえない
Copyright 2019 Naohiro Fujie 73

KYCの課題への対応？
Identity Hubへの参照
で属性値の鮮度保証
Copyright 2019 Naohiro Fujie 74
Issuerへの直接
確認は不要
共有台帳の利用で
Issuer消失へ対応

SSIはKYCを変えるのか？サマリ
• 従来のKYCの難しさ
• 本人から提示されるアイデンティティの確からしさの証明
• 難しさ故に、ユーザや事業者への負担（UX、コスト）がある状態
• 複数の本人確認書類の提示
• 独自レポジトリ（ブラックリスト）とのマッチング
• ライフサイクル管理（Continuous KYC）はさらに難しい
• SSIによる解決の方向性
• 確からしさ
• Verifiable Credentialsの以下の特徴への期待？
• Issuerへの直接確認が不要
• Issuerが無くなっても確認可能
• Continuous KYC
• Identity Hubを通じたバックチャネル連携＝ワンストップ化への期待？
Copyright 2019 Naohiro Fujie 75

結局ブロックチェーンは？
Copyright 2019 Naohiro Fujie 76

SSIはどのようにブロックチェーンを使うか
• DIDとDID DocumentをPOSTするために使う
• DIDとDID DocumentがブロックチェーンにPOSTされ、ハッシュと共に
ブロックに封入されると、台帳がオンラインである限りは、改変が出来な
くなり、ユーザやエージェントはいつでもDIDとDID Documentを参照す
ることが出来るようになる
• ブレークスルー
• 誰もDIDに識別情報を割り当てていない（GoogleやFacebookアカウントと紐づけら
れていない）
• 誰も特定の識別子にパーミッションを付与しない（ICANNやIANAのような組織がい
ない）
• （ハッキングできたりクラッシュする）サーバ上にホストされていないにもかかわ
らず、分散ネットワークの各ノードにレプリケートされている
• DIDはブロックチェーン上に保持されるが、ブロックチェーンが本質なわ
けではない。他のテクノロジー（例えばIPFSやマークル木、Trillianや
HashGraph）もDIDをストアするために利用することもできる
Copyright 2019 Naohiro Fujie 77

ブロックチェーンの使いどころ
• Immutability
• 後から変えられない（変えにくい）
• Verifiable Credentialsなどの証明履歴が残せる
• Portability
• 自分のID Hubのエンドポイントを持ち歩いて、引っ越し先のDID
Documentを作成する
• DID自体は変わる：銀行口座番号と同じ
• データは引き継げる：預金の移管と同じ
• では、ID Hub自体の引っ越しは？
• 分散ノードによる可用性
• DID Documentへのアクセスの可用性の担保
Copyright 2019 Naohiro Fujie 78

まとめ（仮）
Copyright 2019 Naohiro Fujie 79

まとめ（仮）
• プライバシーやKYCに関連する課題に役に立つ可能性
• IdPによる行動把握
• RP間での紐づけ
⇒識別子についてのみ。結局他の属性でトラッキングされる？
でなければPairwiseで少なくともRP側は解決できていたはず
• KYCの課題に役に立つ可能性
• 属性確からしさをIdPへ問い合わせ無く検証可能
• Identity Hubによる属性鮮度の維持
• ブロックチェーン
• 無くても良いが、Immutabilityなどの特徴によりSSIを少しは加速？
Copyright 2019 Naohiro Fujie 80