分散型IDの実像

1.8K Views

September 07, 23

スライド概要

2023/9/6のGeekers nite #3でしゃべった内容です。
https://geekersnites.connpass.com/event/294145/

profile-image

OpenIDファウンデーション・ジャパン代表理事 デジタルアイデンティティ関連のスライドを公開して行きます。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
2.

富⼠榮 尚寛(ふじえ なおひろ) Copyright © 2023, Naohiro Fujie, All Rights Reserved 2

3.

分散型ID? Copyright © 2023, Naohiro Fujie, All Rights Reserved 3

4.

今⽇覚えて帰って欲しいこと Copyright © 2023, Naohiro Fujie, All Rights Reserved 4

5.

ID(アイ・ディー)とは? • ⾝分証明書:Identity Document • ⾝分証明に利⽤するドキュメント(運転免許証など) • 「Show me your ID」のIDはこちら • 識別⼦:IDentifier 富⼠榮 ⼤阪府 富⼠榮 • アイデンティティ:IDentity ⽇本 富⼠榮 富⼠榮 要素 解説 例 属性 後天的に取得された主体に関わる情報 (後から変化する) 名前、電話番号、メアド等 好み 主体の嗜好に関わる情報 ⽢いものが好き 形質 主体の先天的な特有の性質 (後から変化しにくい) Copyright © 2023, Naohiro関係性 Fujie, All Rights Reserved 他の主体との関係に関わる情報 ⽣年⽉⽇、性別 XX⼤学卒業、YY部所属 5

6.

エンティティとアイデンティティの関係性 • エンティティ(主体・実体)は直接 観測できない • アイデンティティ(属性の集合)を 通じて認識・観測する • ⾃観︓提供する属性を通じ、他⼈に ⾒てほしい「⾃⼰像」 • 他観︓提供された属性を通じ、実際 に感じ取った「⾃⼰像」 • 提供する相⼿毎に提供する属性を変 えて「⾃⼰像」を形成 (コンテキストの切り替え) 出典)@_NAT ZONE https://www.sakimura.org/2011/06/1124/ Copyright © 2023, Naohiro Fujie, All Rights Reserved 6

7.

インターネットとアイデンティティの課題 Copyright © 2020, Naohiro Fujie, All Rights Reserved 7

8.

識別⼦:通信するために必要なもの ⼀意に特定 集合(名前空間)の⼤きさ • 空間の管理 Copyright © 2023, Naohiro Fujie, All Rights Reserved 8

9.

アイデンティティ:通信する“相⼿“ • アイデンティティ(属性情報や資格情報) 信じる根拠 Copyright © 2023, Naohiro Fujie, All Rights Reserved 9

10.

暗黙のうちの前提事項 • 組織等の主体がアイデンティティ(識別⼦・属性)を管理していること Copyright © 2023, Naohiro Fujie, All Rights Reserved 10

11.

事業者のみに管理されるということ ライフサイクルが掌握 • 相⼿を確認しようとすると⾏動把握 信頼性は⾼い Copyright © 2023, Naohiro Fujie, All Rights Reserved 11

12.

要件に⾒えるもの Copyright © 2023, Naohiro Fujie, All Rights Reserved 12

13.

短絡的な答えとしての「web3」? • 全公開せずに検証可能な状態でアイデンティティをやり取りできること • 検証可能な資格情報(Verifiable Credentials) 分散型識別⼦(DID) Copyright © 2023, Naohiro Fujie, All Rights Reserved 13

14.

アイデンティティの検証 鮮度の必要性 権威の必要性 ⾼い (付与されてすぐに利⽤) 低い (付与と利⽤の間に時間的なラグあり) ⾼い 認証、属性ベースの認可 (特定事業者への依存 (認証結果の伝達によるログイン・SSO、組織や 性が⾼い) 役職によるアクセス制御) ⾝分証明、資格証明 (学位、ワクチン証明書、学修歴証明など) 低い リスクベース認証、動的認可 (特定事業者への依存 (IPアドレスや場所などのコンテキストベースの認 性が低い) 可) 個⼈ベースの情報、評判 (個⼈端末/Walletに関する情報、レピュテー ションなど) Copyright © 2023, Naohiro Fujie, All Rights Reserved 14

15.

事業者への依存度を下げたいシナリオ? 鮮度の必要性 権威の必要性 ⾼い (付与されてすぐに利⽤) 低い (付与と利⽤の間に時間的なラグあり) ⾼い 認証、属性ベースの認可 (特定事業者への依存 (認証結果の伝達によるログイン・SSO、組織や 性が⾼い) 役職によるアクセス制御) ⾝分証明、資格証明 (学位、ワクチン証明書、学修歴証明など) 低い リスクベース認証、動的認可 (特定事業者への依存 (IPアドレスや場所などのコンテキストベースの認 性が低い) 可) 個⼈ベースの情報、評判 (個⼈端末/Walletに関する情報、レピュテー ションなど) Copyright © 2023, Naohiro Fujie, All Rights Reserved 15

16.

分散型識別⼦(Decentralized Identifiers/DID) • 特定の事業者に依存しない識別⼦(Identifier) Copyright © 2023, Naohiro Fujie, All Rights Reserved 16

17.

DIDの構造 識別⼦ 等 Copyright © 2023, Naohiro Fujie, All Rights Reserved https://www.w3.org/TR/did-core/ より 17

18.

DID Document 要素 内容 例 @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 © 2020, Naohiro Fujie, All Rights Reserved 18

19.
[beta]
要素

内容

例

authentication

DID主体の認証⽅式
(認証専⽤の公開鍵を使う場合はこのセクショ
ンにpublicKeyを書く)

"did:example:123456789abcdefghi#keys-1",
"did:example:123456789abcdefghi#biometric-1",
{“id”: “did:example:hoge”, “type”:”Rsa…”}

authorization
鍵のリカバリなどの際にDID主体の替わりに振舞
and delegation うことのできるDIDに関する情報を記載(未定
義)

議論中っぽい
(guardianとかauthenticationを使う感じ)

service

DID主体が公開したいサービスに関する情報を記 "id": "did:example:123456789abcdefghi;openid",
載
"type": "OpenIdConnectVersion1.0Service",
- id, type : エンドポイントIDとアクセス⽅法
"serviceEndpoint": "https://openid.example.com/"
- serviceEndpoint : エンドポイントのURI

created

DID Documentが⽣成された⽇時

"created": "2002-10-10T17:00:00Z"

updated

DID Documentが更新された⽇時

"updated": "2016-10-17T02:41:00Z"

proof

DID Documentの完全性の証明
"type": "LinkedDataSignature2015",
※DIDとDID Documentが紐づいているという証 "created": "2016-02-08T16:02:20Z",
明ではない
"creator": "did:example:8uQhQ…1ja#keys-1",
"signatureValue": "QNB13Y7Q9...1tzjn4w=="
Copyright © 2020, Naohiro Fujie, All Rights Reserved

19

20.

Copyright © 2023, Naohiro Fujie, All Rights Reserved 20

21.

分散台帳ベースのTDRを利⽤する場合のDID Discovery Service(Universal resolver等) APIレイヤ データレイヤ (Trusted Data Registry) driver driver driver driver ・・・ did:sov:xxx did:btcr:xxx did:ion:xxx did:eth:xxx ・・・ ION(sidetree) 基盤レイヤ sovrin N N … bitcoin N N N … ・・・ ethereum N N N … N 21

22.

分散台帳ベースのTDRを使うか否か VC+DID(分散台帳ベース) VC+DID(分散台帳以外), VC+jwks_uri 発⾏者の検証⽅法 DID Document内に記載されたDNSドメインを使 発⾏者が運営するドメイン上にホストされたDID い発⾏者のDIDが特定DNSドメインを持つ事業主 Documentやjwks_uriエンドポイントを利⽤するた 体と⼀致していることを確認する め、発⾏者が特定のDNSドメインを持つ事業主体 と⼀致していることは明⽩ VCの検証⽅法 DIDリゾルバで取得したDID Documentに含まれ る公開鍵を利⽤して検証 発⾏者の事業停⽌な どへの対応 発⾏者の事業停⽌でも分散台帳の系が停⽌しな 事業者のエンドポイントが停⽌すると検証⽤の鍵 い限りDID Documentの取得が可能 の取得は不可 • did:webの場合*DIDリゾルバ利⽤ • did:web:{url}のURLに配置されたDID Documentに含まれる公開鍵を利⽤して 検証 • did:ion(Long-form)の場合*DIDリソルバ利⽤ • メソッド固有識別⼦のパラメータに含まれ る公開鍵等を利⽤して検証 • jwks_uriを利⽤する場合 • 直接的にURLにアクセスして公開鍵を取 得し検証 Copyright © 2023, Naohiro Fujie, All Rights Reserved 22

23.
[beta]
JSON File: Japanese Domestic Vaccine Certificate
JWS - Header

Web Server: https://vc.vrs.digital.go.jp/issuer/
JWKS file: in URL: https://vc.vrs.digital.go.jp/issuer/.well-known/jwks.json
{

{

"keys": [
{
"kty": "EC",
"kid": "f1vhQP9oOZkityrguynQqB4aVh8u9xcf3wm4AFF4aVw",
"use": "sig",
"alg": "ES256",
"x5c": [
"MIIByjC…”,
"MIIBkDC…”,
"MIIBlTC…”
],
"crv": "P-256",
"x": "ViKBgZ0f3pQKv-tSz653HUtIzCS8TVSNu1Hwi0tKpSk",
"y": "01177apKXH2HgGfkn71ZPEljWk0Q2fcEzY2_XOfL_Zc"
},
{
"kty": "EC",
"kid": "5fGcRveDtGxLX2q_CjXLUOITyAR5KuVNsfe9TkjE86k",
…
}
]

alg: 'ES256',
zip: 'DEF',
kid: 'f1vhQP9oOZkityrguynQqB4aVh8u9xcf3wm4AFF4aVw'
}

X.509 CA Certificates for
Issuer’s Signing Key

JWS - Payload
{
"iss": "https://vc.vrs.digital.go.jp/issuer/",
"nbf": 1620992383.218,
"vc": {
"@context": [
"https://www.w3.org/2018/credentials/v1"
],
"type": [
"VerifiableCredential",
"https://smarthealth.cards#health-card",
"https://smarthealth.cards#immunization",
"https://smarthealth.cards#covid19"
],
"credentialSubject": {
"fhirVersion": "4.0.1",
"fhirBundle": {
"resourceType": "Bundle",
"type": "collection",
"entry": [
// ----- Snip -----]
}
}
}

Issuer’s
Signing Key

}

CA
Certificate

Issuer
Certificate

root CA
Certificate

CN=vc.vrs.digital.go.jp CA
CN=vc.vrs.digital.go.jp Issuer

CN=vc.vrs.digital.go.jp Root CA

Self-Signed Root

}

Verifying Device
JWS - Signature
RH5TVWBaYrPnbtb2LXU9gpC1WRra0gQHjZxSE_htNScq8NdIdgoUt5C1kvdiXbYq
D79W87si9x66fFCwmCmgw

Vaccine Certificate App
root CA
Certificate

* Source : https://openbadges.org/
* Source: Prof. Suzuki/KEIO univ.

Note: Part of this example is not from the real certificates, and not from real execution results due to the experimental environment

24.

検証可能な資格情報(Verifiable Credentials) • 検証可能な情報 デジタル署名 • アイデンティティ表現にも利⽤可能 Copyright © 2023, Naohiro Fujie, All Rights Reserved 24

25.

Verifiable CredentialsとVerifiable Presentations Issuerが発⾏した検証可能な属性のセット ⼀つ以上のVerifiable Credentialsより派⽣した 検証可能なデータ表現 Copyright © 2023, Naohiro Fujie, All Rights Reserved 25

26.

Verifiable CredentialsとVerifiable Presentations Copyright © 2020, Naohiro Fujie, All Rights Reserved 26

27.
[beta]
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 © 2020, Naohiro Fujie, All Rights Reserved

27

28.

Verifiable Credentials/Presentations 要素 内容 例 expirationDate 有効期限 2020-01-01T19:23:24Z credentialStatu Credentialのステータス(停⽌、取り消しなどの s 状態) "id": "https://example.edu/status/24", "type": "CredentialStatusList2021" verifiableCrede ⼊れ⼦にするVerifiable Credentials ntial { “@context”: “”, “id”: “http://aaa”, … Copyright © 2020, Naohiro Fujie, All Rights Reserved 28

29.

Verifiable Credentialsの利⽤モデル 個⼈のID Wallet ⾏政/キャリア/企業 など アプリケーション Trusted Data Registry Copyright © 2023, Naohiro Fujie, All Rights Reserved 29

30.

DIDを使うことの利点 個⼈のID Wallet アプリケーション 分散台帳(Trusted Data Registry) Copyright © 2023, Naohiro Fujie, All Rights Reserved 30

31.

インターネットとアイデンティティの課題 • 相⼿の識別 • アイデンティティの検証 問い合わせなくてもできる Copyright © 2020, Naohiro Fujie, All Rights Reserved 31

32.

⽬指す姿 発⾏元を信頼 利⽤者が⾃⾝で 選択して提⽰ IDの発⾏ レンタル ビデオ店 コンビニ 会社 発⾏元への問い合 わせは不要 Copyright © 2023, Naohiro Fujie, All Rights Reserved 病院 32

33.

“分散型ID”によるデジタル化 利⽤者が⾃⾝で選択して 提⽰(VP+SD) *Holder署名付与 ID(VC)の発⾏ *Issuer署名付与 TDR(上の公開鍵)を使っ てVP/VCを検証することで発 ⾏元を信頼 レンタル ビデオ店 コンビニ 会社 公開鍵の登録 Trusted Data Registry VP/VCの検証 Copyright © 2023, Naohiro Fujie, All Rights Reserved 病院 33

34.

ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü 利⽤者のIDの維持が重要 ü ID管理は最低限 ü 滅多にログインしないユーザでもID維持が必要 ü 本⼈確認(eKYC等)によるIDリカバリが重要 ü 利⽤者へIDサービス(認証等)を提供 → ü 提供するIDサービス(認証等)も最低限 可⽤性が⼤切 ü サービスとID基盤が密結合 → スケールしにくい、⾃ID基 盤で確認したID以外の情報は利⽤できない ID管理 ID基盤 サービス 利⽤ なりす まし ID搾取 ID管理は利⽤者側へシフト ü サービスとID基盤が疎結合 → ID情報も合わせて利⽤できる ID管理 サービス 認証 管理者 滅多に使わない⼈の IDも維持・管理が必要 (ライセンス費⽤増) ID連携(密結合) → ID基盤 影響度低 スケールしやすい、他の ID連携不要(疎結合) ID発⾏ /取消 管理者 最低限のID管理で⼗分 (ライセンス最適化、 リスク低減) → サービス サービス 利⽤ 本⼈確認 〜リカバリ ID情報 ID情報 他のID基盤が発⾏ したID情報 ID情報 滅多に使わない⼈の 認証情報は漏洩しても 気が付きにくい (リスク増) 攻撃者 利⽤者 頻度低 利⽤者 ID情報を個⼈に持たせ る=ロストした場合の リカバリが必要 (本⼈確認) Copyright © 2023, Naohiro Fujie, All Rights Reserved 利⽤者 頻度低 利⽤者 34

35.

ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü 利⽤者のIDの維持が重要 ü ID管理は最低限 ü ü → ID管理は利⽤者側へシフト 卒業⽣、研究者のID管理シナリオ 滅多にログインしないユーザでもID維持が必要 ü 本⼈確認(eKYC等)によるIDリカバリが重要 • 過去に在籍したことの証明 利⽤者へIDサービス(認証等)を提供 → 可⽤性が⼤切 ü 提供するIDサービス(認証等)も最低限 → • 卒業・離籍後も⼤学に残した研究データへ継続的にアクセス許可 ü サービスとID基盤が密結合 → スケールしにくい、⾃ID基 盤で確認したID以外の情報は利⽤できない サプライチェーンのID管理シナリオ ID管理 ü サービスとID基盤が疎結合 → ID情報も合わせて利⽤できる • 企業への所属証明、アクセス権限の証明 ID連携(密結合) ID管理 サービス ID基盤 • OEM企業側でのID管理・パスワード管理の⼿間を⼤幅に削減 ID基盤 スケールしやすい、他の ID連携不要(疎結合) ID発⾏ 認証 管理者 顧客、⾃治体における個⼈ID管理シナリオ /取消 サービス • SNSを使った簡易ID登録と⾝元保証の両⽴、事業者への依存度低減 なりす 利⽤ 滅多に使わない⼈の • 年齢等の⾝元確認(公的な⾝分証明の電⼦化) 最低限のID管理で⼗分 まし 本⼈確認 IDも維持・管理が必要 (ライセンス最適化、 管理者 (ライセンス費⽤増) リスク低減) ID搾取 従業員、学⽣のID管理シナリオ • ⼊社、⼊学時の⾝元確認(公的な⾝分証明の電⼦化) 滅多に使わない⼈の • パスワードレス、オンラインでのアカウント払い出し ID情報を個⼈に持たせ 認証情報は漏洩しても る=ロストした場合の 気が付きにくい (リスク増) 攻撃者 利⽤者 頻度低 利⽤者 リカバリが必要 (本⼈確認) Copyright © 2023, Naohiro Fujie, All Rights Reserved 影響度低 サービス サービス 利⽤ 〜リカバリ ID情報 ID情報 他のID基盤が発⾏ したID情報 ID情報 利⽤者 頻度低 利⽤者 35

36.

Copyright © 2023, Naohiro Fujie, All Rights Reserved 36

37.

まとめ&おさらい Copyright © 2023, Naohiro Fujie, All Rights Reserved 37