SSIとDIDで何を解決したいのか？（β版）

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

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

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

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

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

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

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

個別認証の時代
⇒それぞれで受付、ID提示

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

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

ボトルネック
SPOF

スケールアウト

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

SPOF
受付結果は本物？

真贋確認
（Phone Home）
スケールアウト
クラウド化

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

結託されると
プライバシーの課題
ジョハリの窓でいう、
秘密の窓と未知の窓への侵入

結託されると
KYC的な課題
IdPへの問い合わせコスト
IdPで属性更新が行われてもユーザがログイン
するまでRPは更新を知りえない

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

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

SIOPでいいのでは？
RPでの紐づけもsub_type=pairwiseでいいし

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

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

コンポーネントとイベント
コンポーネント概要
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レコードが消えます

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

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

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"

要素内容例
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=="

DID Documentのサンプル
{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefghi",
"publicKey": [{
"id": "did:example:123456789abcdefghi#keys-1",
"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/"
}]
}

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

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

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

生成したJWSの中身

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

didが採番される
DID Documentは登録中（in-progress）

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

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

{
"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",
"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と紐づく秘密鍵を保持
• 財布の中に複数の会員カードが入っているイメージ

MS DID ProjectのChrome Extension
先ほどのDID登録をWalletから実行可能

MS DID ProjectのChrome Extension

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

ここはDID Auth
DID、Private Key、DID
Resolver Endpointでログオン

以下の順で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では動作せず

"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/"
]
}
}
]

{
"@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"
}
}

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

基本パターン

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などでデバイス間で直接送信する

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などでデバイス間で直接送信する

事前準備Relying PartyのDIDを登録

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を
パースする

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

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

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に残るので引き続き検証可能

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

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

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": “…………"

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”,
…

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

オマケ

ベースとなる関連技術と（黒）歴史？
これまでの実装
• 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のやり取りをなくす
• 匿名認証（グループ署名）
• 署名者を特定せずに検証を可能とする

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

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

もっと深い黒歴史も・・・
（HailStorm, CardSpace）

結局課題解決になるのか？

プライバシの課題
結託されると

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

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

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

結局ブロックチェーンは？

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

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

まとめ（仮）

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

SSIとDIDで何を解決したいのか？（β版）

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a SSIとDIDで何を解決したいのか？（β版）

Similar a SSIとDIDで何を解決したいのか？（β版） (20)

Más de Naohiro Fujie

Más de Naohiro Fujie (20)

Último

Último (7)

SSIとDIDで何を解決したいのか？（β版）