分散型IDの実像

2.6K Views

September 07, 23

#Identity Management #Decentralized Identifiers #Internet #Dependency #Authentication

スライド概要

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

Naohiro Fujie

@fujie

スライド一覧

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

またはPlayer版

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

（ダウンロード不可）

関連スライド

学振特別研究員になるために～2025年度申請版

学振 dc1 dc2 jsps pd

大上雅史 464K

研究に使える便利なフリーソフト ImageJ

imagej 放射線技師

片山豊 317.4K

大規模言語モデルに追加学習で専門知識を教える試み (2023, arXiv:2312.03360)

Kan Hatakeyama 236.9K

ウェーブレット変換の基礎と応用事例：連続ウェーブレット変換を中心に

Ryosuke Tachibana 橘亮輔 189.4K

東京大学 3Dスキャン勉強会「フォトグラメトリ」

フォトグラメトリ vr 3dデジタルアーカイブ

龍 lilea 178.6K

StampFlyで学ぶマルチコプタ制御

伊藤恒平 162.1K

各ページのテキスト

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

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

https://www.sakimura.org/2011/06/1124/

10.

11.

12.

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.

17.

https://www.w3.org/TR/did-core/

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

https://w3id.org/did/v1

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.

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.

25.

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.

30.

31.

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.

37.