Contenu connexe
Similaire à SSIとDIDで何を解決したいのか?(β版) (20)
Plus de Naohiro Fujie (20)
SSIとDIDで何を解決したいのか?(β版)
- 3. Self Sovereign Identityとは何ぞや
• 自己主権型アイデンティティ(SSI)とは、個人は、管理主体
が介在することなく、自身のアイデンティティを所有しコント
ロールできるべきである、と考えるデジタル・ムーブメントを
表す言葉である。SSIを使うと、人々は現実世界で彼らが行っ
ているのと同じ自由度と信頼性をもってデジタル世界でも活動
することが出来る。
• https://sovrin.org/faq/what-is-self-sovereign-identity/
• 抄訳:ふじえ
Copyright 2019 Naohiro Fujie 3
- 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. 言い換えるとこんな感じ?
コンポーネント 概要
User Agent 財布とキャッシュカード
Identity Hub 銀行の顧客データベース
Distributed Ledger 銀行の顧客台帳(インデックスのみ)
Universal Resolver ー
Verifiable
Credentials
銀行口座を開設する際に提示した公的証明書
イベント 概要
DID Registration 銀行口座の開設を行うこと
DID Authentication キャッシュカードの持ち主であることを証明すること
(登録されている個人情報が正しいことの証明ではない)
Copyright 2019 Naohiro Fujie 26
- 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. 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. 要素 内容 例
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. 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. DID、DID Documentの扱い
• DIDとDID Documentは共有台帳上に配置される
• ブロックチェーンである必要はない
• 台帳は対象ネットワーク内でデータのレプリケーションを行う
• DID、DID Document上に個人識別情報(PII)は存在しない
• Walletが鍵を管理し、公開鍵を台帳上に公開
• このことにより、Issuerがクローズしたとしても、クレデン
シャルのVerifyが可能となる
Copyright 2019 Naohiro Fujie 31
- 32. DID、DID Documentの生成と公開
• 以下の手順
1. 鍵ペアの生成
2. メソッド、Identity Hubのエンドポイントと生成した公開鍵を合わせ
てJWSにして登録エンドポイントへPOST
3. DIDが生成され返却される
4. しばらくするとDID Documentが台帳上に書き込まれる
Copyright 2019 Naohiro Fujie 32
- 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. "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. User Agent
• スマホアプリやブラウザExtension
• 役割
• 鍵ペアの生成
• 秘密鍵はSecure Storageへ
• 公開鍵は台帳上のDID Documentへ
• イメージはセキュアなパスワードマネージャ
• DID Authの認証器
• 複数のDIDと紐づく秘密鍵を保持
• 財布の中に複数の会員カードが入っているイメージ
Copyright 2019 Naohiro Fujie 41
- 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. "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
- 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
- 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. 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
- 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
- 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. 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
- 61. Verifiable CredentialsとVerifiable Presentations
• 直接Verifiable Credentialsを提示しても良い
• Verifiable CredentialsのすべてのClaimsをVerifierに提示する
必要が無いケース、複数のVerifiable Credentialsをまとめて
Verifierに提示したいケースなどにおいては、Verifiable
Presentationsを利用する
Copyright 2019 Naohiro Fujie 61
- 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. 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
- 67. Microsoft U-Prove
• Untraceability
• U-ProveトークンにIssuerの署
名や公開鍵の情報を含まない
• トークン発行から利用の間での
紐づけを行うことが出来ない
• Unlinkablity
• 同じProverのトークンであった
としても、トークン同士の紐づ
けを行うことは出来ない
Copyright 2019 Naohiro Fujie 67
- 68. IBM IdeMix
• Flexible public keys
• Pseudonymsと呼ばれる独立し
た複数の公開鍵を一つの秘密鍵
と紐づける
• Flexible credentials
• トークンに含める属性をユーザ
が選択・変更したとして、改変
後の公開鍵でトークンの検証が
出来る
Copyright 2019 Naohiro Fujie 68
- 75. SSIはKYCを変えるのか?サマリ
• 従来のKYCの難しさ
• 本人から提示されるアイデンティティの確からしさの証明
• 難しさ故に、ユーザや事業者への負担(UX、コスト)がある状態
• 複数の本人確認書類の提示
• 独自レポジトリ(ブラックリスト)とのマッチング
• ライフサイクル管理(Continuous KYC)はさらに難しい
• SSIによる解決の方向性
• 確からしさ
• Verifiable Credentialsの以下の特徴への期待?
• Issuerへの直接確認が不要
• Issuerが無くなっても確認可能
• Continuous KYC
• Identity Hubを通じたバックチャネル連携=ワンストップ化への期待?
Copyright 2019 Naohiro Fujie 75
- 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. ブロックチェーンの使いどころ
• Immutability
• 後から変えられない(変えにくい)
• Verifiable Credentialsなどの証明履歴が残せる
• Portability
• 自分のID Hubのエンドポイントを持ち歩いて、引っ越し先のDID
Documentを作成する
• DID自体は変わる:銀行口座番号と同じ
• データは引き継げる:預金の移管と同じ
• では、ID Hub自体の引っ越しは?
• 分散ノードによる可用性
• DID Documentへのアクセスの可用性の担保
Copyright 2019 Naohiro Fujie 78
- 80. まとめ(仮)
• プライバシーやKYCに関連する課題に役に立つ可能性
• IdPによる行動把握
• RP間での紐づけ
⇒識別子についてのみ。結局他の属性でトラッキングされる?
でなければPairwiseで少なくともRP側は解決できていたはず
• KYCの課題に役に立つ可能性
• 属性確からしさをIdPへ問い合わせ無く検証可能
• Identity Hubによる属性鮮度の維持
• ブロックチェーン
• 無くても良いが、Immutabilityなどの特徴によりSSIを少しは加速?
Copyright 2019 Naohiro Fujie 80