Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SSIとDIDで何を解決したいのか?(β版)

1,249 views

Published on

2019/4/23に開催されたdidconの資料。
Decentralized Identifier、Self Sovereign Identity周りの背景や関連仕様、Blockchainとの関係性についてお話しました。
https://idcon.connpass.com/event/126296/

Published in: Technology

SSIとDIDで何を解決したいのか?(β版)

  1. 1. SSIとDIDで 何を解決したいのか? (β版) Naohiro Fujie 2019/04/23 Copyright 2019 Naohiro Fujie 1
  2. 2. 前提など • 課題設定、仕様調査などはまだまだ浅めです • 本日人数を絞ったのもざっくばらんな意見交換をしたかったか らなので、途中でもよいので疑問、意見などは積極的に発言い ただければと思います • 議論を通じで本資料を育てていけると良いな、と • 資料は後で共有します(議論の結果を反映できると嬉しい) Copyright 2019 Naohiro Fujie 2
  3. 3. Self Sovereign Identityとは何ぞや • 自己主権型アイデンティティ(SSI)とは、個人は、管理主体 が介在することなく、自身のアイデンティティを所有しコント ロールできるべきである、と考えるデジタル・ムーブメントを 表す言葉である。SSIを使うと、人々は現実世界で彼らが行っ ているのと同じ自由度と信頼性をもってデジタル世界でも活動 することが出来る。 • https://sovrin.org/faq/what-is-self-sovereign-identity/ • 抄訳:ふじえ Copyright 2019 Naohiro Fujie 3
  4. 4. SSIがデジタル化を目指す現実世界の体験 (できているかどうかは別として) 自分自身でコンテキストに応じてアイデン ティティを使い分けることが可能な世界 Copyright 2019 Naohiro Fujie 4
  5. 5. デジタル化にあたっての考慮点① 現実世界 デジタル世界 識別の精度 不確実(アナログ) ⇒照合は難しい 識別情報を使いデジタルに 識別 ⇒容易に照合できてしまう 情報の保持・維 持 記憶が頼り、忘れられる可 能性 ⇒拡散しても忘れてくれる 確実に記録される ⇒一度拡散すると実質は消 去不能 記憶に残っている可能性 記録が消えると本当に消え る デジタルなので、良くも悪くも正確・確実 Copyright 2019 Naohiro Fujie 5
  6. 6. デジタル化にあたっての考慮点② 自分に分かっている 自分に分かっていない 他人に分かってい る 開放の窓 盲点の窓 他人に分かってい ない 秘密の窓 ⇒プロファイリング対象の 象限 未知の窓 ⇒AI/BigDataにより、よ り深いプロファイリング~ マネタイズ対象となってき ている象限 ジョハリの窓でいうところの秘密・未知の象限を探索されやすい Copyright 2019 Naohiro Fujie 6
  7. 7. これまで と これから 少しこれまでの経緯をさかのぼることで、SSI勢が設定している課題は何な のか?を紐解きましょう Copyright 2019 Naohiro Fujie 7
  8. 8. 個別認証の時代 ⇒それぞれで受付、ID提示 Copyright 2019 Naohiro Fujie 8
  9. 9. 個別認証の時代 ⇒それぞれで受付、ID提示 非効率で不便 Copyright 2019 Naohiro Fujie 9
  10. 10. シングルサインオン(Proxy型) ⇒中央で受付、ID提示 Copyright 2019 Naohiro Fujie 10
  11. 11. シングルサインオン(Proxy型) ⇒中央で受付、ID提示 ボトルネック SPOF Copyright 2019 Naohiro Fujie 11
  12. 12. シングルサインオン(Proxy型) ⇒中央で受付、ID提示 スケールアウト Copyright 2019 Naohiro Fujie 12
  13. 13. シングルサインオン(Federation) ⇒事務所で受付、結果を持ちまわる Copyright 2019 Naohiro Fujie 13
  14. 14. シングルサインオン(Federation) ⇒事務所で受付、結果を持ちまわる SPOF 受付結果は本物? Copyright 2019 Naohiro Fujie 14
  15. 15. シングルサインオン(Federation) ⇒事務所で受付、結果を持ちまわる 真贋確認 (Phone Home) スケールアウト クラウド化 Copyright 2019 Naohiro Fujie 15
  16. 16. まだまだ課題は残る 問い合わせ元で 行動把握が可能 結託されると 行動把握が可能 Copyright 2019 Naohiro Fujie 16
  17. 17. まだまだ課題は残る 問い合わせ元で 行動把握が可能 結託されると 行動把握が可能 Copyright 2019 Naohiro Fujie 17 プライバシーの課題 ジョハリの窓でいう、 秘密の窓と未知の窓への侵入
  18. 18. まだまだ課題は残る 問い合わせ元で 行動把握が可能 結託されると 行動把握が可能 Copyright 2019 Naohiro Fujie 18 KYC的な課題 IdPへの問い合わせコスト IdPで属性更新が行われてもユーザがログイン するまでRPは更新を知りえない
  19. 19. DIFモデル 個別会員カード+チケットの半券 Copyright 2019 Naohiro Fujie 19 割り印でもいいかも 良いメタファーが浮かばない
  20. 20. DIFモデル 個別会員カード+チケットの半券 公共の掲示板に 半券を掲示 個々の会員証を 利用し名寄せ防止 チケットの半券の 突合で真贋確認 チケットも個別に 発行、名寄せ防止 Copyright 2019 Naohiro Fujie 20
  21. 21. SIOPでいいのでは? RPでの紐づけもsub_type=pairwiseでいいし Copyright 2019 Naohiro Fujie 21
  22. 22. DIFモデルが成立するために必要なもの 堅牢な掲示板上の 会員と関連する半券 会員カードとチケット を入れておく財布 個人情報を確認 できる書類 Copyright 2019 Naohiro Fujie 22
  23. 23. DIFモデルが成立するために必要なもの DID/DID Document on Ledgers User Agent Identity Hub Copyright 2019 Naohiro Fujie 23
  24. 24. Copyright 2019 Naohiro Fujie 24
  25. 25. コンポーネントとイベント コンポーネント 概要 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
  26. 26. 言い換えるとこんな感じ? コンポーネント 概要 User Agent 財布とキャッシュカード Identity Hub 銀行の顧客データベース Distributed Ledger 銀行の顧客台帳(インデックスのみ) Universal Resolver ー Verifiable Credentials 銀行口座を開設する際に提示した公的証明書 イベント 概要 DID Registration 銀行口座の開設を行うこと DID Authentication キャッシュカードの持ち主であることを証明すること (登録されている個人情報が正しいことの証明ではない) Copyright 2019 Naohiro Fujie 26
  27. 27. 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
  28. 28. 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
  29. 29. 要素 内容 例 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
  30. 30. 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
  31. 31. DID、DID Documentの扱い • DIDとDID Documentは共有台帳上に配置される • ブロックチェーンである必要はない • 台帳は対象ネットワーク内でデータのレプリケーションを行う • DID、DID Document上に個人識別情報(PII)は存在しない • Walletが鍵を管理し、公開鍵を台帳上に公開 • このことにより、Issuerがクローズしたとしても、クレデン シャルのVerifyが可能となる Copyright 2019 Naohiro Fujie 31
  32. 32. DID、DID Documentの生成と公開 • 以下の手順 1. 鍵ペアの生成 2. メソッド、Identity Hubのエンドポイントと生成した公開鍵を合わせ てJWSにして登録エンドポイントへPOST 3. DIDが生成され返却される 4. しばらくするとDID Documentが台帳上に書き込まれる Copyright 2019 Naohiro Fujie 32
  33. 33. 公開鍵を読み込み、JWKへ メソッド、serviceEndpoint、 publicKeyを指定(Body) 秘密鍵で署名してJWSを生成 Copyright 2019 Naohiro Fujie 33
  34. 34. 生成したJWSの中身 Copyright 2019 Naohiro Fujie 34
  35. 35. 生成したJWSを https://beta.register.did.microsoft.com/api/v1.1 へPOST(Content-Type: application/jwt) Copyright 2019 Naohiro Fujie 35
  36. 36. didが採番される DID Documentは登録中(in-progress) Copyright 2019 Naohiro Fujie 36
  37. 37. https://beta.register.did.microsoft.com/api/v1.0/{did} をGETして登録状況を確認 登録完了(registered) Copyright 2019 Naohiro Fujie 37
  38. 38. https://beta.dicsover.did.microsoft.com/v1.0/identifiers/{did} をGETして登録されたDID Documentを確認 Copyright 2019 Naohiro Fujie 38
  39. 39. { "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
  40. 40. "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
  41. 41. User Agent • スマホアプリやブラウザExtension • 役割 • 鍵ペアの生成 • 秘密鍵はSecure Storageへ • 公開鍵は台帳上のDID Documentへ • イメージはセキュアなパスワードマネージャ • DID Authの認証器 • 複数のDIDと紐づく秘密鍵を保持 • 財布の中に複数の会員カードが入っているイメージ Copyright 2019 Naohiro Fujie 41
  42. 42. MS DID ProjectのChrome Extension 先ほどのDID登録をWalletから実行可能 Copyright 2019 Naohiro Fujie 42
  43. 43. MS DID ProjectのChrome Extension Copyright 2019 Naohiro Fujie 43
  44. 44. Identity Hub • クラウドやサーバにホストされる常時稼働しているアプリケー ション • Smart Contractにより個人の代わりに決定をしたり、データを 共有したり、処理を行う • DID Documentにエンドポイントの情報が記載されている Copyright 2019 Naohiro Fujie 44
  45. 45. ここはDID Auth DID、Private Key、DID Resolver Endpointでログオン Copyright 2019 Naohiro Fujie 45
  46. 46. Copyright 2019 Naohiro Fujie 46
  47. 47. 以下の順で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
  48. 48. "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
  49. 49. { "@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
  50. 50. 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
  51. 51. 基本パターン Copyright 2019 Naohiro Fujie 51
  52. 52. 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
  53. 53. 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
  54. 54. 事前準備Relying PartyのDIDを登録 Copyright 2019 Naohiro Fujie 54
  55. 55. Copyright 2019 Naohiro Fujie 55
  56. 56. 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
  57. 57. 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
  58. 58. 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
  59. 59. 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
  60. 60. Issuerが発行した検証可能な属性のセット 一つ以上のVerifiable Credentialsより派生 した検証可能なデータ表現 Verifiable CredentialsとVerifiable Presentations Copyright 2019 Naohiro Fujie 60
  61. 61. Verifiable CredentialsとVerifiable Presentations • 直接Verifiable Credentialsを提示しても良い • Verifiable CredentialsのすべてのClaimsをVerifierに提示する 必要が無いケース、複数のVerifiable Credentialsをまとめて Verifierに提示したいケースなどにおいては、Verifiable Presentationsを利用する Copyright 2019 Naohiro Fujie 61
  62. 62. 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
  63. 63. 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
  64. 64. やり取りの方法 • W3CではVerifiable Credentials/Presentationの データ構造までは定義してい るが、やり取りの方法につい ては標準化していない • 結果、各実装者毎の方法が乱 立している状態となっている • Sovrin:ゼロ知識証明 • uPort : attestation Copyright 2019 Naohiro Fujie 64
  65. 65. オマケ Copyright 2019 Naohiro Fujie 65
  66. 66. ベースとなる関連技術と(黒)歴史? これまでの実装 • 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
  67. 67. Microsoft U-Prove • Untraceability • U-ProveトークンにIssuerの署 名や公開鍵の情報を含まない • トークン発行から利用の間での 紐づけを行うことが出来ない • Unlinkablity • 同じProverのトークンであった としても、トークン同士の紐づ けを行うことは出来ない Copyright 2019 Naohiro Fujie 67
  68. 68. IBM IdeMix • Flexible public keys • Pseudonymsと呼ばれる独立し た複数の公開鍵を一つの秘密鍵 と紐づける • Flexible credentials • トークンに含める属性をユーザ が選択・変更したとして、改変 後の公開鍵でトークンの検証が 出来る Copyright 2019 Naohiro Fujie 68
  69. 69. もっと深い黒歴史も・・・ (HailStorm, CardSpace) Copyright 2019 Naohiro Fujie 69
  70. 70. 結局課題解決になるのか? Copyright 2019 Naohiro Fujie 70
  71. 71. プライバシの課題 問い合わせ元で 行動把握が可能 結託されると 行動把握が可能 Copyright 2019 Naohiro Fujie 71
  72. 72. Copyright 2019 Naohiro Fujie プライバシの課題への対応? 個々の会員証を 利用し名寄せ防止 チケットも個別に 発行、名寄せ防止 72
  73. 73. KYCの課題 問い合わせコスト ログインしないと IdPの属性更新を知 りえない Copyright 2019 Naohiro Fujie 73
  74. 74. KYCの課題への対応? Identity Hubへの参照 で属性値の鮮度保証 Copyright 2019 Naohiro Fujie 74 Issuerへの直接 確認は不要 共有台帳の利用で Issuer消失へ対応
  75. 75. SSIはKYCを変えるのか?サマリ • 従来のKYCの難しさ • 本人から提示されるアイデンティティの確からしさの証明 • 難しさ故に、ユーザや事業者への負担(UX、コスト)がある状態 • 複数の本人確認書類の提示 • 独自レポジトリ(ブラックリスト)とのマッチング • ライフサイクル管理(Continuous KYC)はさらに難しい • SSIによる解決の方向性 • 確からしさ • Verifiable Credentialsの以下の特徴への期待? • Issuerへの直接確認が不要 • Issuerが無くなっても確認可能 • Continuous KYC • Identity Hubを通じたバックチャネル連携=ワンストップ化への期待? Copyright 2019 Naohiro Fujie 75
  76. 76. 結局ブロックチェーンは? Copyright 2019 Naohiro Fujie 76
  77. 77. 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
  78. 78. ブロックチェーンの使いどころ • Immutability • 後から変えられない(変えにくい) • Verifiable Credentialsなどの証明履歴が残せる • Portability • 自分のID Hubのエンドポイントを持ち歩いて、引っ越し先のDID Documentを作成する • DID自体は変わる:銀行口座番号と同じ • データは引き継げる:預金の移管と同じ • では、ID Hub自体の引っ越しは? • 分散ノードによる可用性 • DID Documentへのアクセスの可用性の担保 Copyright 2019 Naohiro Fujie 78
  79. 79. まとめ(仮) Copyright 2019 Naohiro Fujie 79
  80. 80. まとめ(仮) • プライバシーやKYCに関連する課題に役に立つ可能性 • IdPによる行動把握 • RP間での紐づけ ⇒識別子についてのみ。結局他の属性でトラッキングされる? でなければPairwiseで少なくともRP側は解決できていたはず • KYCの課題に役に立つ可能性 • 属性確からしさをIdPへ問い合わせ無く検証可能 • Identity Hubによる属性鮮度の維持 • ブロックチェーン • 無くても良いが、Immutabilityなどの特徴によりSSIを少しは加速? Copyright 2019 Naohiro Fujie 80

×