20260311 技術SWG活動報告（デジタルアイデンティティ人材育成推進WG Ph2 活動報告会）

2026/03/11 開催
デジタルアイデンティティ人材育成推進WGフェーズ２：活動報告会 発表資料

技術SWG活動報告
・PAR、RAR、JAR
・パスワードレス認証
・デジタルアイデンティティウォレット（VC）
・SSF（Shared Signal Framework）
・IAL（Identity Assurance Level）

OpenID ファウンデーション・ジャパン
デジタルアイデンティティ人材育成推進ワーキンググループ
技術サブワーキンググループ

Transcript

1. Copyright OpenID Foundation Japan - All Rights Reserved. デジタルアイデンティティ⼈材育成推進ワーキンググループ 技術サブワーキンググループ フェーズ2 活動報告会 2026年3⽉11⽇ OpenIDファウンデーション‧ジャパン
2. Copyright OpenID Foundation Japan - All Rights Reserved. ⽬次 1. PAR、RAR、JAR 2. パスワードレス認証 3. デジタルアイデンティティウォレット（VC） 4. SSF（Shared Signal Framework） 5. IAL（Identity Assurance Level） 本⽇は、デジタルアイデンティティとセキュリティの動向を網羅し、PAR‧RAR‧JARによる認可 リクエストのセキュリティ強化から、パスキー等のパスワードレス認証による利便性と安全性の 解説、さらにはデジタルアイデンティティウォレット（VC）を⽤いた新たな資格証明の仕組みま でを深く掘り下げます。 あわせて、SSFによる事業者間のリアルタイムなリスク共有や、NIST SP 800-63に基づく⾝元確 認保証レベル（IAL）の要件についても解説し、信頼性の⾼いアイデンティティ基盤の構築に向け た技術と運⽤をご紹介します。 2
3. Copyright OpenID Foundation Japan - All Rights Reserved. 1. PAR、RAR、JAR 3
4. Copyright OpenID Foundation Japan - All Rights Reserved. 情報系初学者なので日々学ぶことが多く大変ではありますが、逆 に基礎から積み上げられる貴重な機会と思い、生じた疑問を丁 寧に解決しながら学習に励んでいます。 担当紹介 永⽥ 憲正 ⼤⽇本印刷株式会社 飯岡巧⺒ フリー株式会社 デジタルIDは学ぶことが多く⼤変です が、その分新しい発⾒も多く、 ⽇々楽しみながら取り組んでおります。 普段はハトンと呼んでもらっています。 登壇者 担当者 佐藤 澪花 野村総合研究所 ID‧認証認可は”誰にとっても⾝近な分 野”であるからこそ、”誰でもわかるよう に”を⼼がけて資料を作成しました。
5. Copyright OpenID Foundation Japan - All Rights Reserved. ⽬次 1. OAuth 2.0の課題 2. JAR (JWT Secured Authorization Request) 3. PAR (Pushed Authorization Request) 4. RAR (Rich Authorization Requests) 5. 課題整理と解決策 OAuth 2.0の課題を解決する3つの拡張仕様（JAR/PAR/RAR）を解説します。 5
6. Copyright OpenID Foundation Japan - All Rights Reserved. 1. OAuth 2.0の課題 6 1. PAR、RAR、JAR
7. Copyright OpenID Foundation Japan - All Rights Reserved. セキュリティリスク • 完全性の⽋如 ◦ URLパラメータ（scope, redirect_uri等）はユーザーや攻撃者により改ざん可 能。認可サーバーは検証不能。 • 機密性の⽋如 ◦ URLに含まれる情報は、ブラウザ履歴‧プロキシログ‧リファラ等に残り続け る。 • コンプライアンス上の懸念 ◦ URL経由での個⼈情報送信は、プロキシログ等に残るため、情報漏洩に直結する リスクがある。 ブラウザは信頼できない経路であり、改ざんと情報漏洩のリスクを構造的に抱えている 7
8. Copyright OpenID Foundation Japan - All Rights Reserved. 物理的制約とユーザー体験 • URL⻑の物理的制約 ◦ ブラウザにはURL⻑制限がある。 ◦ 複雑な要求を含めると上限を超過し、リクエスト⾃体が失敗する。 ▪ scope, login_hint, acr_values に加え、JSON形式の claims などを組み合わせると 容易にURL制限を超過する。 ◦ URL制限によりクエリが途中で切り捨てられた場合、エラーにならず⼀部のオプション が認可サーバー側で無視されたまま処理されるリスクもある。 • バリデーションの遅延 ◦ リクエストの検証は認可サーバー到達時に⾏われる。 ▪ クライアントアプリから認可サーバーへリダイレクト後。 ◦ 即時エラーにならず、ユーザー体験を損なう。 URL⻑の物理的制約によるパラメーターの⽋落と検証の遅延が、ユーザー体験とセキュアな機能 拡張を阻害し得る。 8 ?response_type=code&client_id=ClientA&login_hint=user@example.com&acr_v alues=urn:mace:...&claims={"userinfo":{"given_name":{"essential":true}}}&...
9. Copyright OpenID Foundation Japan - All Rights Reserved. 表現⼒の限界 • 単純な⽂字列リスト ◦ 従来のscopeは "scope: payment" 等の単純な羅列。 ◦ 構造化データを扱えず表現⼒が低い。 • 複雑な取引内容 ◦ 「AからBへ1000円送⾦」等の詳細な指⽰が困難。 ◦ 独⾃フォーマットは相互運⽤性を⽋く。 • 同意の不透明さと否認リスク ◦ ⽀払いの権限への同意では、100円の送⾦か100万円の送⾦か、ユーザーは区別が つかない。 ◦ ユーザーが「そんな⾦額送るつもりはなかった」と否認した場合に証明できな い。 単純な⽂字列リストでは表現⼒が乏しく、複雑なビジネス要件に対応できない。 9
10. Copyright OpenID Foundation Japan - All Rights Reserved. 2. JAR 10 1. PAR、RAR、JAR
11. Copyright OpenID Foundation Japan - All Rights Reserved. JWT-Secured Authorization Request (JAR) • OAuth 2.0に対する解決したい課題 ◦ 従来のクエリパラメータは、ユーザーや攻撃者によって容易に改ざん可能であった。 ◦ パラメータがブラウザ履歴、プロキシログ、リファラ等に残るため、個⼈情報の漏洩リスク がある。 認可リクエストのパラメータをJWTとしてひとまとめにし送信する規格[RFC 9101]。 11 認可リクエストパラメータをJWT（Request Object）に集約し、 署名‧暗号化によって保護する⽅法を定義 TLS（通信経路）の安全性に依存せず、アプリケーション層でのエンドツーエンドの完全性と送信元認証を実現する。
12. Copyright OpenID Foundation Japan - All Rights Reserved. Request Object a, b のいずれかを⾏わなければならない。 a: JWS signed b: JWS signed + JWE encrypted JWSによる署名を⾏う場合にはiss, audが必須となる。 Request Objectの中に、⾃分⾃⾝を指す request や request_uri パラメーターを含めてはいけない。 ※ 補⾜: request_uri の参照先として、さらに別の request_uri を含む JWT を配置した時に、Request Object が A→B→C→A→… と循環参照 できる状態が成⽴してしまう。 認可リクエストのパラメーターをJWTとして表現したもの。 12 { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400 } eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI...
13. Copyright OpenID Foundation Japan - All Rights Reserved. Request Object の送信⽅法 request パラメーター 署名済みJWTを request パラメーターに直接含める⽅法 • 実装が単純になる • 内容が多いとURLが⻑くなり、ブラウザの制限超過の可能性がある request_uri パラメーター JWTをサーバー等に保存しその場所を request_uri パラメーターとして伝える⽅法 • URLが短くなり、ブラウザ履歴にデータが残らないため機密性が⾼い • request_uri ⾃体は署名されていないため書き換え可能 Request Object は 2 つの⽅法で認可リクエストのパラメーターに含めることができる 13
14. Copyright OpenID Foundation Japan - All Rights Reserved. JAR フロー clientで⽣成したRequest Object をrequestに指定 14 1. client で Request Object を⽣成 2. Request Objectをrequestに指定してserverへリダイレ クト 3. requestとclient_idを⽤いて認可リクエスト ※【補⾜】クエリパラメーターのclient_idの必要性：認可サーバーがJWTの署名検証 鍵を事前に特定するため、クエリパラメーターとしてもclient_idが必須となる。な お、Request Object内のclient_idと完全に⼀致する必要がある。 ※【補⾜】Requset Objectに含まれるパラメーターを重複してクエリパラメーターに 含めることについて: clientが後⽅互換の⽤途で重複したパラメーターを含めてもよ い。なお、認可サーバーはRequest Objectのパラメーターを優先する必要がある。 4. JWTの署名を検証し従来通りの認可コードグラントへ
15. Copyright OpenID Foundation Japan - All Rights Reserved. JAR フロー 15 1. client で Request Object を⽣成 2. Request Objectの参照先をrequest_uriに指定して serverへリダイレクト 3. request_uriとclient_idを⽤いて認可リクエスト ※【補⾜】request_uriのときも、認可サーバーがJWTの署名検証鍵を事前に特定する ためクエリパラメーターへclient_idが必須となる。 4. request_uriへアクセス 5. Request Objectを参照 6. JWTの署名を検証し従来通りの認可コードグラントへ clientで⽣成したRequest Object をrequest_uriで指定
16. Copyright OpenID Foundation Japan - All Rights Reserved. JAR ユースケース ⾦融‧銀⾏ • オープンバンキングの法的遵守 ◦ FAPI 1.0 Advanced: 認可リクエストの改ざんを防⽌ ◦ FAPI 2.0 Message Signing Profile: ⾼額な決済取引内容の否認を防⽌ 医療‧公的機関 • 個⼈情報の保護: リクエスト⾃体に機密性の⾼い個⼈情報が含まれる場合、JWEによる暗号化 でプライバシーを保護 政府‧⾼保証要件(NIST FAL3) • 「鍵の所有証明 (Holder-of-Key)」による、リクエストの乗っ取り‧なりすまし防⽌ FAPI 2.0 Message Signing や NIST FAL3 等、最⾼レベルのセキュリティ要件を満たすための必須 実装です。 16
17. Copyright OpenID Foundation Japan - All Rights Reserved. JAR Consideration • 鍵管理 • クライアントは署名鍵のローテーション計画が必須。 • リプレイ攻撃対策 • jti (JWT ID) と exp (有効期限) を⽤いて、使⽤済みリクエストの再送を防ぐ。 • request_uri を使う場合は、使い捨てにするのが推奨。 • エラーハンドリング • 署名検証失敗時は "invalid_request_object" を返す。 • 検証エラーの詳細を返しすぎると攻撃のヒントになるため注意が必要。 導⼊には、クライアント側の鍵管理（ローテーション）や、リプレイ攻撃への対策など、運⽤⾯ での考慮が不可⽋です。 17
18. Copyright OpenID Foundation Japan - All Rights Reserved. 3. PAR 18 1. PAR、RAR、JAR
19. Copyright OpenID Foundation Japan - All Rights Reserved. Pushed Authorization Requests (PAR) • OAuth 2.0 + JARに対する解決したい課題 Authorization Grant：Authorization Codeの認可リクエストにおいて、 ◦ 詳細なリクエストやJWTを⽤いる場合、URL⻑がかなり⼤きくなり、ブラウザやサーバーの キャパシティを超える(実質おおよそ2,000⽂字) ◦ client認証をユーザー介在後のトークンリクエストで⾏うため、認可リクエスト時に不正な clientによるリスクが存在する clientがOAuth 2.0認可リクエストを認可サーバーへ直接 “push” するための、 Pushed Authorization Requests(PAR)エンドポイントを定義する規格。 19 JARを補強する形で、認可リクエストを直接認可サーバーへpushする⽅法を定義 加えて、ユーザー介在前にclient認証を⾏うことで不正clientを防ぐ
20. Copyright OpenID Foundation Japan - All Rights Reserved. PAR フロー PAR のシーケンス図 20 1. 認可リクエスト含むパラメータをClientから直接 認可サーバーへ送信(POST)する 2. request_uriを⽣成し、201でレスポンスを返す 3. 受け取ったrequest_uriをUser Agentへ渡す 4. request_uriを⽤いて認可サーバーへ認可リクエストを ⾏う(GET) 5. 認可レスポンスを⽣成し、302でclientにリダイレクト 6. clientへリダイレクト 7. 認可レスポンスを取得、後続のトークンリクエストへ
21. Copyright OpenID Foundation Japan - All Rights Reserved. PAR パラメータ 認可リクエスト含むパラメータをClientから“直接”認可サーバーへ送信(POST)する • PARエンドポイントURLはHTTPSスキーマを⽤いなければならない(MUST) • request_uriパラメータを含んではならない(MUST NOT) • client認証のために適切なパラメータを含む(e.g., clinet_secret, client_assertionとclient_assertion_type ) • PKCEと組み合わせることが可能（組み合わせ必須の記載はない） • requestパラメータをJWTにして送ってもよい(MAY) PAR エンドポイントへのpushリクエストパラメータ（⼀部抜粋） 21 POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded response_type=code &state=af0ifjsldkj &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U &code_challenge_method=S256&scope=account-information &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer &client_assertion=eyJraWQi0.eyJpc3MiOiJz…jEicXTixEkdRuzsgUCm6GQ JWTにし、request = “JWT”にしてもよい
22. Copyright OpenID Foundation Japan - All Rights Reserved. PAR パラメータ 認可サーバーはレスポンスを返すために、下記を⾏う(MUST) • client認証 • 認可リクエストの検証 上記が成功した場合、下記パラメータを含むレスポンスを201HTTPステータスコードで返す • request_uri（POSTされた認可リクエストに対応するURI。single-use。） • expires_in（request URIの有効時間。5~600秒程度を設定する。） PAR エンドポイントへのpushリクエストに対するレスポンスパラメータ（⼀部抜粋） 22 HTTP/1.1 201 Created Content-Type: application/json Cache-Control: no-cache, no-store { "request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c", "expires_in": 60 }
23. Copyright OpenID Foundation Japan - All Rights Reserved. PAR パラメータ clientはrequest_uriを⽤いて認可リクエストを⾏う • clientはrequest_uriの値を⼀度だけ⽤いる(MUST) • 認可サーバーはrequest_uriの値を⼀度だけ⽤いるべきである(SHOULD)が、ユーザーによるリロー ドやリフレッシュのために重複を許容してもよい(MAY) 取得したrequest_uriを⽤いた認可リクエストのパラメータ（⼀部抜粋） 23 GET /authorize ?client_id=s6BhdRkqt3 &request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3A6esc_11ACC5b wc014ltc14eY22c HTTP/1.1 Host: as.example.com 認可サーバーは⼀連の認可リクエストを検証し成功した場合、認可コードを発⾏する
24. Copyright OpenID Foundation Japan - All Rights Reserved. ユースケース FAPI 2.0 Security Profileの要件にて、PAR対応が必須 [FAPI 2.0 Security Profile](2025/02 Final) →⾦融、医療などの領域で普及しつつある • ⾦融 ◦ みんなの銀⾏ in ⽇本[みんなの銀行] ◦ Consumer Data Standards(CDR) in オーストラリア[CDR Data Standards] • 医療 ◦ HelseID（国家医療ID基盤）inノルウェー[HelseID] • ベンダー(OpenID Foundationによる認定)[Certified FAPI 2.0 OP] ◦ Authlete ◦ Filip Skokan ◦ Luiky Vasconcelos PARを⽤いているユースケース 24
25. Copyright OpenID Foundation Japan - All Rights Reserved. PAR Consideration • 攻撃者の推測やリプレイを防ぐため、⽣成するrequest URIは⼗分なエントロ ピーかつ短いライフタイムを設定する • 認証されたclientによるredirect URIにのみリダイレクトする • Access Tokenを横取りや書き換えられないように、PKCE[RFC7636]を⽤いる Security Considerations 25
26. Copyright OpenID Foundation Japan - All Rights Reserved. • 認可サーバーメタデータ ◦ pushed_authorization_request_endpoint ▪ PARエンドポイントのURL  Clientに対し、“PARに対応していること”と“アクセスするURI”を⽰すことが可能 ◦ require_pushed_authorization_requests ▪ 認可サーバーがPAR経由でのみ認可リクエストを受け取るかを⽰すブーリアン  Clientに対し、PARの利⽤を要求する意思表⽰が可能 • Clientメタデータ ◦ require_pushed_authorization_requests ▪ clientがPARでのみ認可リクエストを受け渡すことを⽰すブーリアン  認可サーバーに対し、PARの利⽤を要求する意思表⽰が可能 認可サーバーおよびClientのMetadata(補⾜資料) 26 Metadata
27. Copyright OpenID Foundation Japan - All Rights Reserved. 4. RAR 27 1. PAR、RAR、JAR
28. Copyright OpenID Foundation Japan - All Rights Reserved. Rich Authorization Request (RAR) • OAuth2.0に対する解決したい課題 ◦ 従来のscopeは "read:doc" などの単純な文字列の羅列であり、 構造化データを扱えず表現力 が低い ◦ 詳細な権限要求 を標準的な方法で送ることができない ◦ ユーザにとって「何に・どれだけ」同意するのかが不明確 なため、セキュリティリスクや UXの低下 を招く JSON形式を用いることで、複雑な権限要求を詳細に記述するための規格 28 より細粒度で複雑な認可リクエストを、 JSONオブジェクトの配列として詳細に記述する⽅法を定義
29. Copyright OpenID Foundation Japan - All Rights Reserved. PAR + RAR フロー PAR + RAR フロー 29 1. 認可リクエストを直接POSTする ここに authorization_details を付与する 2. request_uriを⽣成し、201でレスポンス 3. 受け取ったrequest_uriを渡す 4. request_uriを⽤いてGETでアクセス 5. 認可レスポンスを⽣成し、302でclientにリダイレクト 6. clientへリダイレクト 7. 認可レスポンスを取得、後続のトークンリクエストへ
30. Copyright OpenID Foundation Japan - All Rights Reserved. RAR パラメータ（1/4） 30 従来の scope authorization_details  リクエスト時にはJSON配列をURLエンコードする read:doc write:doc { "type": "customer_information", "locations": [ "https://example.com/customers" ], "actions": [ "read", "write" ], "datatypes": [ "contacts", "photos" ] } authorization_details への移⾏のため 同⼀の認可リクエストでscope との併⽤が サポートされている ⼀⽅で、1つのAPIに対しては、 ⼀⽅の指定形式のみを使⽤することが 推奨されている RFC 9396 2.2. Common Data Fields
31. Copyright OpenID Foundation Japan - All Rights Reserved. RAR パラメータ（2/4） 31 authorization_details パラメータ • JSONの配列で詳細な権限要求を⾏う • フィールド ◦ 以下のフィールド以外もAPIの設計に合わせて独⾃のフィールドを設計‧追加できる # フィールド 必須 説明 1 type 〇 認可の詳細な種類を表す識別⼦ 2 locations リソースまたはリソースサーバの場所を表す⽂字列（通常: URI）の配列 3 actions リソースに対して実⾏される操作の種類を表す⽂字列の配列 4 datatypes リソースから取得するデータの種類を表す⽂字列の配列 5 identifier APIで利⽤可能な特定のリソースを表す⽂字列型の識別⼦ 6 privileges リソースに対して要求する権限の種類を表す⽂字列の配列
32. Copyright OpenID Foundation Japan - All Rights Reserved. RAR パラメータ（3/4） 32 authorization_details パラメータ（具体例） • 従来のscopeでは表現できなかったトランザクションベースのリクエストができる "authorization_details": [ { "type": "payment_initiation", "actions": [ "initiate", "status", "cancel" ], "locations": [ "https://example.com/payments" ], "instructedAmount": { "currency": "EUR", "amount": "123.50" }, "creditorName": "Merchant A", "creditorAccount": { "iban": "DE02100100109307118603" }, "remittanceInformationUnstructured": "Ref Number Merchant" } ] フィールド 説明 type ⽀払い処理の開始 actions 実⾏、状況の確認、キャンセル locations この権限を使⽤するAPIエンドポイント instructedAmount 123.50 EUR (⽀払う) creditorName ⽀払先：Merchant A creditorAccount ⽀払先⼝座番号：DE02100100109307118603 remittanceInformation Unstructured 送⾦時のメッセージ：Ref Number Merchant RFC 9396 7. Token Response
33. Copyright OpenID Foundation Japan - All Rights Reserved. RAR パラメータ（4/4） 33 authorization_details パラメータ（具体例） • 前述のリクエストを受け取った認可サーバは、ユーザに対して以下のような確認画⾯ を出すことができる XXX Bank Merchant A 様に 123.50 EUR を送⾦しますか （送⾦後の状況確認とキャンセル権限も付与されます） はい いいえ
34. Copyright OpenID Foundation Japan - All Rights Reserved. RAR Consideration • パラメータの⻑さ ◦ 詳細な権限要求によるデータ（ペイロード）の増⼤に対応するため、ブラウザの URL制限を回避するPARを⽤いる • セキュリティ ◦ 認可情報の改ざんを防⽌するため、リクエストの完全性を保証するJARや、直接 サーバへpushするPARを⽤いる • プライバシー ◦ 権限内容の漏えいを防⽌するため、JAR(JWE)を⽤いてリクエスト全体を暗号化 する 34
35. Copyright OpenID Foundation Japan - All Rights Reserved. • 認可サーバーメタデータ ◦ authorization_details_types_supported ▪ 認可サーバがサポートしているtypeのリスト • Clientメタデータ ◦ authorization_details_types ▪ クライアントが認可リクエストで使⽤する(予定の)typeのリスト RAR 補⾜資料 35 Metadata メタデータを⽤いることで、認可サーバーとクライアントの間で、事前 に「どのtypeを使うか」すり合わせが可能となる
36. Copyright OpenID Foundation Japan - All Rights Reserved. 36 課題 PAR RAR JAR パラメータの改ざん ◯ バックチャネル送信により、改ざん経路を物理 的に遮断する。(FAPI 2.0 Security Profile 必須 / OAuth 2.0 BCP 推奨) - ◯ 電子署名により、転送中のパラメータ改ざんを検知・拒 否し、完全性を保証する。(FAPI 1.0 Advanced 必須) 情報露出・ 個人情報漏洩 ◯ ブラウザを経由させないことで、個人情報の露 出を構造的に防ぐ。(NIST SP 800-63C / GDPR 準拠に寄与) - ◯ JWE: 認可サーバー内部での漏洩リスクすら許容でき ない極めて高い機密性が必要な場合に利用。(FAPI 1.0 Advanced 推奨) 送信元の否認 - - ◯ 電子署名により、通信経路に依存しない「真正性」と 「法的否認防止」を保証する。(FAPI 2.0 Message Signing / NIST FAL3 必須) バリデーションの遅延 ◯ ブラウザ転送前に検証を完了し、即時にエラー を返すことでUXを向上させる。(RFC 9126 Section 2.3) - - URL長の物理的制約 ◯ POST通信によりURL長制限を回避し、オプショ ンの欠落リスクを回避させる。(RFC 9396 RAR にて利用推奨 / FAPI 2.0 Security Profile 必 須) - - 表現力の不足・ 粒度不足・ 同意の不透明さ - ◯ 「支払先や金額」等の構造化データによる詳細な 権限指定。(OIDF Whitepaper / NIST SP 800-63C ) - まとめ‧OAuth 2.0の課題整理と解決策
37. Copyright OpenID Foundation Japan - All Rights Reserved. 2. パスワードレス認証 37
38. Copyright OpenID Foundation Japan - All Rights Reserved. 社会人歴＝IDエンジニア歴です。普段は大阪で自社 IDaaS サービスの開発～拡販に携わっています。 OpenID Connectが大好きです！ 担当紹介 花井 杏夏 伊藤忠テクノソリューションズ株式会社 登壇者 安部芳紀 セコム株式会社 デジタルID初⼼者です。仕様が多く把握 が⼤変な部分もありますが、少しずつ学 びながら知識を深めていきたいです。 担当者
39. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証とは 39 認証要素として知識(≒PW)を利⽤しない⼿段をパスワードレス認証として扱う 本稿では主にWebで利⽤される認証⼿段を対象として扱う 区分 認証手段 本稿での対象/対象外 パスワード パスワード認証 PINや秘密の質問含め、パスワード認証は対象外 パスワードレス ワンタイムパスワード (HOTP,TOTP,メール/SMS) パスワードとして入力は可能だが、所有や経路外として区分される 方式となり対象 FIDO/パスキー 主にデバイス側で実施する本人確認で利用するPIN等の手段を対 象とする マジックリンク 規格化されていないがパスワードレスとして対象 PKI(クライアント証明書) 公開鍵認証基盤として対象 その他 SSO OIDC,SAML等のフェデレーション仕様となり認証要素とは別定義と なるため対象外（フェデレーション先でパスワードレス認証を実装す るケースも想定） 生体認証、パターン、QR、キャプチャ、ICカードといった認証手段は対象外
40. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証が必要とされる背景 40 従来主流だった知識要素による認証（パスワード認証）には、「忘れる‧盗まれ る‧貸与されてしまう」という⽋点があった。 知識要素以外＝所有‧⽣体認証を使ったパスワードレス認証はそれらの⽋点を補 うものとして重要視されている。 欠点 知識 所有 生体 忘れる あり(PW忘れ) なし なし 失くす なし あり(デバイス紛失) なし(身体の欠損は少ない ) 盗まれる あり(フィッシング) なし(強盗は少ない) なし(身体の欠損は少ない ) 貸与 あり あり なし 変更 容易 容易 困難 一致率 100% 100% 100%ではない
41. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証の種類 • 使い捨てコード＝ワンタイムパスワードを利⽤した認証⽅式 41 ①ワンタイムパスワード(HOTP,TOTP,メール/SMS) 種類 概要 HOTP（HMAC-based One-Time Password） 秘密鍵とカウンター値から生成されるワンタイムパスワード 方式。ハードウェアトークン等。 TOTP（Time-based One-Time Password） 秘密鍵と時間情報から生成されるワンタイムパスワード方 式。一定時間毎に定期的にコードが変わる。一般的に利用 されるAuthenticatorアプリケーションはTOTP形式を採用し ていることが多い。 メール/SMS サーバーが生成した乱数コードをメール /SMSで配信する ワンタイムパスワード方式。
42. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証の種類 • 公開鍵暗号⽅式を利⽤した、秘密鍵をユーザーとサーバー間で共有しない認 証⽅式 • 秘密鍵/公開鍵ペアはドメイン毎に作成されるため、フィッシングサイト対 策に有⽤ 42 ②FIDO/パスキー FIDOサーバー 公開鍵 認証器 ①認証要求＋ チャレンジ送信 秘密鍵 ②認証要求 ③PINや生体認証 等で認証 ④秘密鍵で署名した チャレンジを送信 ⑤公開鍵で署名検証
43. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証の種類 • ログイン時に⼊⼒されたメールアドレスへログイン⽤URLを送る⽅式 • リンクをクリックするとログインが完了する 43 ③マジックリンク 43
44. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証の種類 • 端末にインストールされたクライアント証明書を利⽤した認証⽅式 • 管理者が秘密鍵で署名したクライアント証明書を、各端末に配布 • 認証時には、サーバーから送られたチャレンジに対して、端末内に保持され ている秘密鍵（証明書発⾏時に端末側で⽣成したもの）を使って署名して サーバーに返却。サーバー側は対応した公開鍵を使って署名検証 44 ④PKI(クライアント証明書)
45. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証のメリット‧デメリット 45 パスワード認証のメリット‧デメリットの逆が パスワードレス認証の総論としてのメリット‧デメリットになりうる パスワード認証のメリット • 多様な端末から⽐較的容易に認証できる、事前準備が不要（ユーザー視点） • ⽐較的容易に実装できる（事業者視点） パスワード認証のデメリット • ユーザの記憶負担 → 使いまわし → 漏洩のリスク • フィッシングのリスク • 総当たり攻撃のリスク • ユーザー側の事前準備等の利⽤コスト、事業者側の実装‧運⽤コスト
46. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証のメリット‧デメリット ①ワンタイムパスワード(HOTP,TOTP,メール/SMS)を利⽤する場合 • メリット • ワンタイムパスワードを盗まれても再利⽤されるリスクが無い • フィッシング攻撃の軽減（リアルタイムだと効果が無い） • デメリット • ⼊⼒の⼿間 • メール/SMSの場合、受信に時間がかかる場合あり • スマホ/ハードウェアトークンの場合、端末紛失/変更時の対応が必要 • 中間者攻撃には対応できない 46
47. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証のメリット‧デメリット ②FIDO/パスキーを利⽤する場合 • メリット • フィッシング耐性 • 秘密情報がデバイス内から出ない • デメリット • 導⼊コスト • ユーザー側の対応（理解） • 互換性：未対応な古いデバイス • 鍵管理：紛失/変更時の対応が必要 47
48. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証のメリット‧デメリット ③マジックリンクを利⽤する場合 • メリット • Email/SMSを利⽤：⽐較的多くの⼈が利⽤可能 • デメリット • 認証フローを開始した環境とメールを受信する環境の違いによるミス • アプリ内ブラウザとosブラウザ、別端末、等 • フィッシング対策の 怪しいメールのリンクはクリックしない という啓 蒙と、この送られてきたメールのURLをクリックするというお作法の相 性 • 迷惑メールフィルタ、スパム判定をくらう可能性有 48
49. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証のメリット‧デメリット ④クライアント証明書を利⽤する場合 • メリット • ⾃動で認証できる（TLS通信の⼀部として認証が⾏われる） • フィッシング耐性（双⽅向で認証できる） • 秘密情報がデバイス内から出ない • デメリット • サーバ側の設定が必要 • 証明書の管理コスト：発⾏、配布、更新、失効 • 鍵管理：紛失/変更時の対応が必要 49
50. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証のメリット‧デメリット 50 フィッシング耐性 総当たり攻撃耐性 パスワード × ×（実装によって緩和は可能） OTP (HOTP / TOTP, メール/SMS) △ 〇（入力上限を設ける） FIDO ◎（ドメインに紐づく） ◎ マジックリンク △ ◎（URLに付与するトークンが高エ ントロピーである前提） クライアント証明書 ◎（サーバーに紐づいた接続） ◎ ここまで個別で記載したメリット‧デメリットをポイントごとに表形式でまとめ たものが以下。主にデメリットとして⼤きいものについて、以降の設計ポイント で補⾜する。 ①セキュリティ
51. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証のメリット‧デメリット 51 ユーザ側 導入コスト 認証にかかる手間/時間 運用コスト パスワード ◎ 〇 ×（ 記憶の負担） OTP (HOTP / TOTP) △ △ △（端末の管理） OTP (メール / SMS) 〇（基本的な携帯 ・PCで対応） △ △（アドレスの管理） FIDO △ 〇 △（端末の管理） マジックリンク 〇（基本的な携帯 ・PCで対応） △ △（アドレスの管理） クライアント証明書 ×（特にB2Cでは配布 が難しい） 〇 △（端末の管理） ②ユーザー視点のコスト
52. Copyright OpenID Foundation Japan - All Rights Reserved. パスワードレス認証のメリット‧デメリット 52 管理者側 導入コスト 運用コスト パスワード 〇 ×（パスワードの管理） OTP (HOTP / TOTP) △ ×（秘密情報の管理） OTP (メール / SMS) 〇（基本的な携帯・PCで対応） △（送信装置のコスト） FIDO △ △（ユーザーサポート） マジックリンク 〇（基本的な携帯・PCで対応） △（送信装置のコスト） クライアント証明書 ×（特にB2Cでは配布が難しい） ×（証明書の管理） ③管理者視点のコスト
53. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • OTP（HOTP/TOTP メール/SMS） ◦ フィッシングサイト上で正規のOTPを⼊⼒させられるリスクはどうして も残る • マジックリンク ◦ 攻撃者にリンクを盗まれると即座にログインができてしまう ◦ 本物のマジックリンクメールとフィッシングメールの区別がつきにくい 53 ①攻撃への耐性：フィッシング OTP‧マジックリンク
54. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • OTP（HOTP/TOTP メール/SMS） ◦ OTPは桁数が少ない（6桁〜8桁） ◦ 総当たり攻撃を許してしまうと突破されるリスクが⾼い ◦ 試⾏回数制限、OTPが届かなかった場合の再送数制限、短時間に複数の OTPリクエストや検証が同時に⾏われないようにする対策を設けること が前提 54 ①攻撃への耐性：総当たり攻撃 OTP
55. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • ユーザー側 ◦ それぞれユーザー側で専⽤のアプリケーションのインストールや対応端 末の準備、証明書⾃体のインストールという作業が必要 ◦ クライアント証明書はB2Cでは利⽤が現実的ではない • 管理者側 ◦ ユーザー側と同様に各ツールの導⼊⼿順を作成することや、ユーザーか らのQA対応等に対応するコストが必要になることが多い ◦ クライアント証明書についてはユーザー毎に発⾏‧配布作業が必要とな る 55 ②導⼊コスト：TOTP‧FIDO/パスキー‧クライアント証明書
56. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • OTP（HOTP/TOTP‧メール/SMS） ◦ パスワード⼊⼒やパスキーと⽐べるとコード確認〜⼊⼒とユーザーに⼿ 間と時間がかかる場合がある • マジックリンク ◦ OTPほどではないが、メールアプリを開いてメールを探す⼿間がかかる ◦ ネットワーク状況やメーラー側のフィルタによって到達しない可能性 56 ③認証にかかる⼿間/時間（ユーザー側）
57. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • ユーザー側 ◦ FIDO/パスキー‧OTP（HOTP/TOTP）‧クライアント証明書 ⇒認証器を⼊れている端末の機種変更‧⼀時的な不携帯‧紛失時に認証 ができなくなってしまう ◦ OTP（メール‧SMS）‧マジックリンク ⇒メールや電話番号に変更があった場合に、ID基盤側も事前に変更をし ていないと認証ができなくなってしまう 57 ④運⽤コスト：共通
58. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • 管理者側 ◦ リカバリ時の対応コストについてはユーザー側と同様 ◦ OTP（メール‧SMS）‧マジックリンク ▪ メールやSMSの送信コストが別途発⽣する ▪ ⼤量送信リクエストが来た際の対処⽅法の検討 ◦ OTP（HOTP/TOTP‧メール/SMS） ▪ OTPコードの安全な管理 ◦ FIDO/パスキー ▪ 端末やブラウザによって挙動が異なるためユーザーへの利⽤⽅法ア ナウンス‧トラブルシュート対応の網羅にコストがかかる ◦ クライアント証明書 ▪ 証明書の定期的な更新や管理コスト 58 ④運⽤コスト：共通
59. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • FIDO/パスキー ◦ iCloudキーチェーンなど、現在は認証器間でキー情報を共有できる仕組 みもある ◦ ネイティブアプリの場合は利⽤OSやデバイスをある程度絞れる可能性 • TOTP ◦ Google AuthenticatorなどはGoogleアカウントと同期していれば新しい 端末に移⾏できる場合も • マジックリンク ◦ マジックリンクを発⾏したブラウザとメーラーが開くデフォルトブラウ ザが異なるとアプリの仕組みによってはセッションがないのでうまく動 作しない可能性も… 59 その他補⾜
60. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • 知識要素（パスワード）：記憶している限りは移転も紛失もしない • 所有要素：所有という性質上、故障‧紛失‧変更が発⽣しやすい＋複製がで きない • パスワードレス認証＝知識要素以外の要素で認証、とした場合、所有要素の みに依拠すると、所有の断絶が起きた場合の本⼈確認が難しくなる 60 共通：リカバリ性とセキュリティのバランス
61. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • 各認証⼿段単体での実装の場合、端末紛失/機種変更作業未実施により、リ カバリをしようとした際、別途本⼈確認の⼿段が必要となる ◦ 対⾯本⼈確認（学⽣証/社員証等の提⽰） ◦ 本⼈確認⽤属性情報の⼊⼒（⽒名‧住所‧⽣年⽉⽇‧電話番号など） ⇒なりすましの懸念、運⽤コストの増加 • 単体ではなく複数の認証⼿段を提供する？ ◦ 例：FIDO/パスキーが使えない場合は例外的にOTP（メール、SMS）を 提供するなど ▪ 代替⼿段の中にはセキュリティ強度が⼗分でないものも存在する （例：OTP（SMS）はフィッシング耐性の観点からアプリケーショ ン側で利⽤を許容できないケースがある、など） 61 リカバリ性とセキュリティのバランス
62. Copyright OpenID Foundation Japan - All Rights Reserved. 利⽤時の注意点‧設計ポイント • ①リカバリ⽤コードの発⾏ ◦ 初回登録時にリカバリ⽤コードを発⾏し、利⽤者は別途安全な場所へ保 管をしておく ⇒利⽤者への管理コストはどうしても発⽣する • ②複数端末での認証対応 ◦ FIDO/パスキー：PC‧スマートフォンなど複数登録をしておく ◦ FIDO/パスキー＋TOTP/HOTP：PCでパスキー‧スマートフォンでTOTP ⇒経路が増えるとともにリスクと管理コストも増加 • ③リカバリ時のアクセス範囲を制限 ◦ FIDO/パスキー＋SMS：SMSでリカバリした際にアプリケーション上で 実施できるアクションに制限を設ける 62 リカバリ性とセキュリティのバランス
63. Copyright OpenID Foundation Japan - All Rights Reserved. 本セクションのまとめ • パスワードレス認証を導⼊するケース ◦ パスワード管理コストを無くしたい（利⽤者‧管理者双⽅） ⇒認証運⽤コスト⾃体がゼロになるわけではないが、パスワードを管理 する、というコストからは解放される ◦ セキュリティレベルを⾼めたい ⇒特にFIDO/パスキーはフィッシングやなりすまし耐性が⾼い。導⼊‧ 運⽤コストの考慮はあるが、ユーザーの利便性向上にもつながる。 63 最後に、これからどのようにパスワードレス認証を使っていくべきか、本セク ションのまとめとして記載する
64. Copyright OpenID Foundation Japan - All Rights Reserved. 本セクションのまとめ • パスワードレス認証⽅式を選択する上での基本的な考え ◦ 導⼊コストが低いのはOTP（メール/SMS）、マジックリンク ⇒単体では攻撃耐性も同時に低いが、少なくともパスワード管理コスト を無くすことはできる ◦ FIDO/パスキーは攻撃耐性と利便性の両⽴が可能。導⼊‧運⽤コストの 考慮はあるが、パスキー同期機能等負荷を下げる仕組みも ◦ OTP（HOTP/TOTP）は中程度の攻撃耐性と利便性の両⽴が可能。FIDO/ パスキーの導⼊が難しい環境での利⽤ ◦ クライアント証明書認証は配布‧運⽤負荷が⾼く、基本的にB2E内での 利⽤中⼼ 64 最後に、これからどのようにパスワードレス認証を使っていくべきか、本セク ションのまとめとして記載する
65. Copyright OpenID Foundation Japan - All Rights Reserved. 3. デジタルアイデンティティウォレット 65
66. Copyright OpenID Foundation Japan - All Rights Reserved. まだまだ初心者ですが、この資料を見てくださる皆さんと一緒に学んでい けるとうれしいです！ 業務では大学との共同研究で VCのOSS「VC Knots」を開発していま す。よろしければ使ってみてください！ 担当紹介 安永 未来 伊藤忠テクノソリューションズ株式会社 登壇者 私自身が ID 初学者ですので、初学者なりの視点で、初学者の方に 伝わるよう説明を考えました。 同じくこれから ID を学ぶみなさま、一緒に頑張っていきましょう！ 吉村 拓眞 株式会社オプティム
67. Copyright OpenID Foundation Japan - All Rights Reserved. SoftBankIDのID基盤、認証基盤の開発(上流)を行ってます。 本WGでは、DIWとは、IHVモデルについてのパートの資料作成を担当さ せていただきました。 まだID業界の経験が浅いので、日々知識を吸収させていただいていま す！ 担当紹介 瀬在 翔太 ソフトバンク株式会社 担当者
68. Copyright OpenID Foundation Japan - All Rights Reserved. ⽬次 1. デジタルアイデンティティウォレット (DIW) とは 2. IHV モデル 3. DIW, VC に関する登場⼈物a 4. VC 利⽤の流れ 5. Presentation a. 選択的開⽰(Selective Disclosure) b. VC のうち、限られた属性のみを提⽰する⼿段 c. SD-JWT d. 「18 歳以上である」ことだけを証明する⼿段 6. OAuth, OIDC と VC の関連 a. OpenID for Verifiable Credential Issuance b. OpenID for Verifiable Presentations c. Self-Issued OpenID Provider v2 デジタルアイデンティティウォレットの概要、登場⼈物、利⽤、関連仕様について解説します。 68
69. Copyright OpenID Foundation Japan - All Rights Reserved. デジタルアイデンティティウォレット (DIW) とは デジタルアイデンティティウォレットとは • 属性情報や資格情報等をスマートフォン等に保存し、利⽤者の操作を介して 提⽰できるアプリケーション • アナログ世界の ID カードや紙の書類と同じようなフローで、デジタル化さ れた証明書の発⾏‧提⽰ができる仕組みを実現する デジタルアイデンティティウォレットと Verifiable Credentials (VC) の関連 • DIW の実現に関する技術標準の策定は各団体で⾏われている • そのうち代表的なものの⼀つが “Verifiable Credentials” である • これは、検証可能な資格情報 (Credentials) を扱うための標準仕様である 69
70. Copyright OpenID Foundation Japan - All Rights Reserved. IHV モデル • DIW, VC に関する概念は、Issuer, Holder, Verifier の 3 つの役割を定義した IHV モデルを利⽤して説明されることが多い 70 発⾏ 提⽰ Issuer Holder Verifier 資格情報を発⾏する主体 (学校、会社など) 資格情報を保持する主体 (利⽤者) 資格情報を検証する主体 (サービス提供者など)
71. Copyright OpenID Foundation Japan - All Rights Reserved. DIW, VC に関する登場⼈物 主要な登場⼈物 • Issuer: 資格情報を発⾏する主体（例: 卒業証明を学校が発⾏） • Holder: 資格情報を取得, 保持, 提⽰する主体（例: 学⽣が卒業証明を保持） • Verifier: 資格情報を検証する主体（例: 学⽣を採⽤する企業が学歴を検証） • Wallet: 資格情報の取得, 保持, 提⽰に使⽤されるアプリケーション • Subject: Claim の対象になるもの（例: 卒業を証明される学⽣） • Verifiable Data Registry (VDR): 識別⼦, スキーマ, 失効等を扱う仲介者 補⾜ • Holder と Wallet の間には「A さんの Wallet を B さんが提⽰していないか」 のような紐付けに関する観点がある • 必ずしも Subject = Holder ではない（⼦の VC を親が保持するなど） 71
72. Copyright OpenID Foundation Japan - All Rights Reserved. DIW, VC に関する登場⼈物 例：卒業証明書を発⾏し、学⽣を採⽤する企業がそれを検証する 卒業証明書 (VC) の発⾏対象 (Subject) は学⽣になり、保持者 (Holder) と同⼀ 72
73. Copyright OpenID Foundation Japan - All Rights Reserved. DIW, VC に関する登場⼈物 例：出⽣証明を発⾏し、渡航時に他国政府が検証する 証明される対象 (Subject) は⼦だが、保持者 (Holder) は親となり、別 73
74. Copyright OpenID Foundation Japan - All Rights Reserved. VC 利⽤の流れ 1. 発⾏ (Issuance) ◦ Issuer が情報 (Claim) を保証し、デジタル署名付きの VC を作成して Holder に送る ◦ Issuer が VC に署名し、公開鍵を VDR に登録する 2. 提⽰ (Presentation) ◦ Holder がサービス提供を受けるため、VC に関する情報を Verifier に提⽰する => 具体的には？ 3. 検証 (Verification) ◦ Verifier は VDR から Issuer の公開鍵を取得し、提⽰された情報を検証する 74
75. Copyright OpenID Foundation Japan - All Rights Reserved. Presentation Presentation（VC の提⽰）の形態 • Holder が Verifier に VC を直接提⽰する • Holder が Verifiable Presentation (VP) を作成し、Verifier に提⽰する • 1つ以上のVCに由来するデータを表現したもの • VC 全体を共有しなくてよいため、プライバシーを保護できる プライバシーの保護に関するキーワード • 選択的開⽰：必要な情報に限定して提⽰できること • ゼロ知識証明：実際の値を渡さずに特定の資格情報を⽰すためのメカニズム • 選択的開⽰を実現するための⼿段の⼀つ 75
76. Copyright OpenID Foundation Japan - All Rights Reserved. 「18 歳以上である」ことを証明する⼿段 パターン①：クレーム全体を共有 Issuer が発⾏する VC に、⽒名, 住所, ⽣年⽉⽇, 性別が含まれている（簡単のため、⼀部抜粋） Holder は上記の VC をそのまま Verifier に提⽰する（VP は作成しない） これにより、Verifier は Subject の⽣年⽉⽇を知ることができるので、年齢確認を⾏える 76 "credentialSubject": { "given_name": "Erika", "family_name": "Mustermann", "birthdate": "1963-08-12", "address": { "street_address": "Heidestraße 17", "locality": "Köln", "postal_code": "51147", "country": "DE" }, "sex": 2 }
77. Copyright OpenID Foundation Japan - All Rights Reserved. 「18 歳以上である」ことを証明する⼿段 パターン②：クレームのサブセットを共有 Issuer が発⾏する VC に、⽒名, 住所, ⽣年⽉⽇, 性別が含まれている（簡単のため、⼀部抜粋） Holder は birthdate だけを抜き出した VP を作成し、Verifier に提⽰する これにより、Verifier は誕⽣⽇しかわからず、⽒名などを秘匿できる 77 "credentialSubject": { "given_name": "Erika", "family_name": "Mustermann", "birthdate": "1963-08-12", "address": { "street_address": "Heidestraße 17", "locality": "Köln", "postal_code": "51147", "country": "DE" }, "sex": 2 }
78. Copyright OpenID Foundation Japan - All Rights Reserved. 「18 歳以上である」ことを証明する⼿段 パターン②の派⽣（クレームのサブセットを共有） Issuer が発⾏する VC に、⽒名, 住所, ⽣年⽉⽇, 性別に加え、age_over_18 のような属性を含める Holder は age_over_18 だけを抜き出した VP を作成し、Verifier に提⽰する これにより、Verifier は「18 歳以上である」ことしかわからず、誕⽣⽇を秘匿できる 78 "credentialSubject": { "given_name": "Erika", "family_name": "Mustermann", "birthdate": "1963-08-12", "address": { "street_address": "Heidestraße 17", "locality": "Köln", "postal_code": "51147", "country": "DE" }, "sex": 2, "age_over_18": true }
79. Copyright OpenID Foundation Japan - All Rights Reserved. 「18 歳以上である」ことを証明する⼿段 パターン③：派⽣した情報を共有 Issuer が発⾏する VC には⽒名, 住所, ⽣年⽉⽇, 性別が含まれ、age_over_18 のような属性は含まれない Holder は birthdate 属性から 18 歳以上であるかを確認できる派⽣属性を含む VP を作成する 事前に専⽤属性を定義せずとも選択的開⽰が可能 79 "credentialSubject": { ... "birthdate": "1963-08-12", ... } { "type": "VerifiablePresentation", "verifiableCredential": { "credentialSubject": { "age_over_18": true } }, "proof": ゼロ知識証明による証明 }
80. Copyright OpenID Foundation Japan - All Rights Reserved. 選択的開⽰（Selective Disclosure） • 選択的開⽰：Holder が必要な情報に限定して提⽰できること 例：酒類購⼊時に20歳以上であることを提⽰ • SD-JWT：選択的開⽰を実現するためのフォーマットのひとつ 80 ⽒名 ⽣年⽉⽇ 顔写真 XX在学etc… 学生証 酒屋 https://www.w3.org/TR/vc-data-model-2.0/ Age≧20 映画館 XX⼤学の学⽣
81. Copyright OpenID Foundation Japan - All Rights Reserved. VC のうち、限られた属性のみを提⽰する⼿段 SD-JWT というデータ形式を⽤いることで実現できる 発⾏時に、選択的開⽰を⾏える属性のハッシュを _sd に⼊れる 81 https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ { "name": "OAuthたん", "birthdate": "2018-10-01", "nationality": "Japan" } { "name": "OAuthたん", "_sd": [ "TWE9Zy1Uez_iXCVgT__lSlWiQa4PS9SyCSMk5QPx-l0", "XGs_tf9por_-dn0qjchSPPPEsoNFiVeYjy1e_t7lEC4" ], "_sd_alg": "sha-256" } 通常のJWTペイロード SD-JWTのペイロード
82. Copyright OpenID Foundation Japan - All Rights Reserved. SD-JWT 提⽰の際には JWT の最後に “Disclosure”（属性情報を含む、検証可能な⽂字列）をつけて渡す 開⽰したくない属性の Disclosure を削除することで選択的開⽰を実現 82 eyJhbGciOiJFUzI1NiJ9.eyJuYW1lIjoiT0F1dGjjgZ_jgpMi LCJfc2QiOlsiVFdFOVp5MVVlel9pWENWZ1RfX2xTbFdpUWE0U FM5U3lDU01rNVFQeC1sMCIsIlhHc190Zjlwb3JfLWRuMHFqY2 hTUFBQRXNvTkZpVmVZankxZV90N2xFQzQiXSwiX3NkX2FsZyI 6InNoYS0yNTYifQ.wNgLUi6s0mOE87XiR5j6a5ZwkV6D-KsDK FAIt66AMUVG2kitgUghGIVaKSealwP_AfbA3lIO3S1Z42VXXJ Lk9g~WyJxbkdNR1ppaGw5TzdRcU44aGFMR2tnIiwiYmlydGhk YXRlIiwiMjAxOC0xMC0wMSJd~WyJlb0ktdUlGcElTMWROdEN3 bWJQSUJBIiwibmF0aW9uYWxpdHkiLCJKYXBhbiJd~ SD-JWT { "name": "OAuthたん", "_sd": [ "TWE9Zy1Uez_iXCVgT__lSlWiQa4PS9SyCSMk5QPx-l0", "XGs_tf9por_-dn0qjchSPPPEsoNFiVeYjy1e_t7lEC4" ], "_sd_alg": "sha-256" } SD-JWTのペイロード ["qnGMGZihl9O7QqN8haLGkg"(ソルト ), "birthdate","2018-10-01"] Disclosure から計算するハッシュ 検証に利⽤する
83. Copyright OpenID Foundation Japan - All Rights Reserved. 「18 歳以上である」ことを証明する⼿段 以下のような前提を考える • VC を利⽤して年齢確認を⾏う • Issuer は Subject の基本 4 情報（⽒名, 住所, ⽣年⽉⽇, 性別）を確認し、VC を発⾏することができる VC の発⾏と提⽰のパターンには、どのようなものがあるか？ 83
84. Copyright OpenID Foundation Japan - All Rights Reserved. OAuth, OIDC と VC の関連 • VC そのものはあくまでデータモデルの定義のみ • Entity 間のデータの要求/提⽰は別で定義される • OpenID for Verifiable Credentials は以下で構成される • OpenID for Verifiable Credential Issuance (OID4VCI) • OpenID for Verifiable Presentations (OID4VP) • Self-Issued OpenID Provider v2 (SIOPv2) 84
85. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID for Verifiable Credential Issuance • Issuer から Wallet に VC を安全に発⾏するための仕様 • VC 発⾏の API を OAuth 2.0 で保護する • Issuer から Wallet への、VC 発⾏の案内となる Credential Offer を定義 85 { "credential_issuer": "https://credential-issuer.example.com", "credential_configuration_ids": [ "UniversityDegreeCredential", "org.iso.18013.5.1.mDL" ], "grants": { "urn:ietf:params:oauth:grant-type:pre-authorized_code": { "pre-authorized_code": "oaKazRN8I0IbtZ0C7JuMn5", "tx_code": { "length": 4, "input_mode": "numeric", "description": " メールで送信されたワンタイムコードを入力してください " } } } } リクエストボディの例
86. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID for Verifiable Presentations • Verifier が Wallet に VC を要求し、Wallet 提⽰するためのメカニズムを定義 • OAuth 2.0 の認可リクエスト/レスポンスを拡張してデータをやりとり • DCQL (Digital Credentials Query Language) で提⽰要求を表現 86 { "iss": "redirect_uri:https://client.example.org/cb", "aud": "https://self-issued.me/v2", "response_type": "vp_token", "client_id": "redirect_uri:https://client.example.org/cb", "redirect_uri": "https//client.example.org/cb", "dcql_query": { "credentials": [ { "id": "some_identity_credential", "format": "dc+sd-jwt", "meta": { "vct_values": ["https://credentials.example.com/identity_credential"] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]} ] } ] }, "nonce": "n-0S6_WzA2Mj" } リクエスト時のパラメータの例
87. Copyright OpenID Foundation Japan - All Rights Reserved. Self-Issued OpenID Provider v2 概要 • エンドユーザーがローカルに管理できる OpenID Provider を提供する • サードパーティプロバイダーに依存せず RP とやりとりできる OID4VP と組み合わせることで以下のような流れが実現できる 1. エンドユーザーがエンドユーザーの端末上で ID Token を発⾏ 2. エンドユーザーの端末上で Verifiable Presentation を作成 3. ID Token と VP を合わせて RP に提⽰ • => RP は ID Token と VP (VC) を紐づけることができる • => 資格証明とユーザー認証がユーザーの端末上で完結 87
88. Copyright OpenID Foundation Japan - All Rights Reserved. まとめ デジタルアイデンティティウォレットとは • 属性情報や資格情報等をスマートフォン等に保存し、利⽤者の操作を介して 提⽰できるアプリケーション デジタルアイデンティティウォレットと Verifiable Credentials (VC) の関連 • DIW の実現に関する技術標準の⼀つが “Verifiable Credentials” である • これは、検証可能な資格情報 (Credentials) を扱うための標準仕様である OpenID for Verifiable Credentials • Entity 間のデータの要求/提⽰の⽅法を OAuth/OIDC と関連づけて定義 • OID4VCI、OID4VP、SIOPv2 などの仕様がある 88
89. Copyright OpenID Foundation Japan - All Rights Reserved. 4. SSF 89
90. Copyright OpenID Foundation Japan - All Rights Reserved. 寺原 歩 フリー株式会社 普段は てらら というハンドルネームで 活動しております。 より多くの方々に自分の携わったデジタ ルIDを活用していただける世界を夢見 ています。 那須楓⾹ TOPPANエッジ 私自身初学者のため、資料作成を通 して理解を深めていきました。本資料 が皆さんのID理解の一助になれたら と思います。 私自身ID初学者で本活動を通じて勉強させていただいていま す。皆様の理解を手助けできる資料となっていれば幸いです。 担当紹介 ⽊村 圭吾 株式会社NTTデータ 登壇者 担当者
91. Copyright OpenID Foundation Japan - All Rights Reserved. 目的 ▪想定読者 OAuth2.0 / OIDC 1.0 のコアドメインについては理解しているが、「SSF」については知ら ない読者向け ▪目的 SSFの概要把握、および実務導入に向けた概念理解 ▪本書の役割 プロトコルを読み解く前のSSFのベース知識を構築する 91
92. Copyright OpenID Foundation Japan - All Rights Reserved. SSFとは • Shared Signals Frameworkの略であり、OpenID Foundationで策定されている仕様である。 • プライバシー保護された安全なWebhookを提供し、APIの効率とセキュリティを向上させる。 • セッション情報などを共有し、イベントをリアルタイムに通知をすることができる。 例 アプリにログインしたあとに、モニタリングを行い不正を検知した場合 　 共有し被害拡大を防ぐ SSFとは 出典: https://openid.net/wg/sharedsignals/ ログイン ログアウト モニタリング ショッピング アプリ② モニタリング 林檎奪われる ショッピング アプリ① 検 知 対策 購入 購入 バナナ奪われない 92 共 有
93. Copyright OpenID Foundation Japan - All Rights Reserved. 従来のOpenID ConnectなどのID連携プロトコルでは、ユーザーのログイン時点でのみOPがアクセスの有効性 を検証しており、その後発行されたセッションは長期間継続される。この長いセッション期間中に、ユーザーの アクセス制御に影響する変更が発生する可能性がある。例えばユーザーが退職してOP側のアカウントが削除 または無効化されるなど。 このような変更が生じた後、ログイン時に検証された古い情報に基づいてアクセスが継続されるという問題が 発生する。つまり、実際には権限を持たないユーザーや、侵害されたアカウントによる不正アクセスが許可され てしまう。 SSFが必要となった背景 現状の課題 出典: https://openid.net/wg/sharedsignals/ OP RP ID連携 退職による無効化 ログイン時の検証 セッション発行 （長期間有効） RP経由でのID連携要求 （連携フローは割愛） 属性変更をRPは検知できない 93
94. Copyright OpenID Foundation Japan - All Rights Reserved. SSFが必要となった背景 前述の課題を解決するため、ユーザーの属性やセキュリティ状況の変化をリアルタイムに検知し、アクセ ス制御を動的に調整する仕組みが求められるようになった。この要件に応えるためにCAEP（OpenID Continuous Access Evaluation Profile 1.0）が提案され、さらにそれを支える基盤技術としてSSF（Shared Signals Framework）の議論が開始された。 SSFのアプローチ 出典: https://openid.net/wg/sharedsignals/ OP RP ID連携 退職による無効化 ログイン時の検証 セッション発行 （長期間有効） RP操作 属性変更を検知 リアルタイム監視 アクセス制御の調整 94
95. Copyright OpenID Foundation Japan - All Rights Reserved. SSFの登場人物 ➢ Transmitter ：Shared Signal Frameworkにおいてeventを送信するエンティティ ➢ Reciever ：Shared Signal Frameworkにおいてeventを受信するエンティティ SSFの登場人物には信号を送るTransmitterと受け取るRecieverが存在する Transmitter Reciever event 例：OpenID　ConnectでID連携したシステムでセッションが破棄された場合 OP RP Session event：Session Revoked Transmitter Receiver 95 出典: https://openid.net/wg/sharedsignals/
96. Copyright OpenID Foundation Japan - All Rights Reserved. SSF、CAEP、RISCの立ち位置 CAEPとRISCはSSFでTransmitter とReceiver間で共有するイベント形式の1つ ➢ CAEP: 継続的アクセス評価プロファイル (Continuous Access Evaluation Profile)の略 ◦ ログインしたセッションの状態に影響を与えるイベントを伝達する技術 ◦ イベント例：セッション取り消し、認証情報の変更、保証レベルの変更 ➢ RISC：リスクインシデント共有と調整( Risk Incident Sharing and Coordination):の略 ◦ セキュリティインシデントやリスクに関する情報を共有するためのフレームワーク ◦ イベント例：アカウントの有効化、アカウントの無効化、識別子の変更 ➢ SSF ：TransmitterとReceiver間の非同期通信を容易にするAPI ◦ APIはOAuthなどを用いて認可を行う 出典: https://www.openid.or.jp/blog/2025/06/shared-signals-framework-iam-14.html SSF、CAEP、RISCの立ち位置 SSF CAEP RISC 96
97. Copyright OpenID Foundation Japan - All Rights Reserved. SSF、CAEP、RISCの立ち位置 ➢ Push方式：HTTPを使用したプッシュベースのセキュリティイベントトークン(SET)配信 ◦ Transmitterが能動的にReceiverに対してリクエストする ◦ 接続：Transmitter→Receiver ◦ 参考：RFC 8935 ◦ 処理：同期処理 ◦ メリット：即時性が高い ◦ デメリット：常に送受信できる状態にする必要がある ➢ ポーリング方式：HTTPを使用したポーリングベースのセキュリティイベントトークン（SET）配信 ◦ Receiverが一定間隔でTransmitterにデータの有無を確認 ◦ 接続：Receiver→Transmitter ◦ 参考：RFC 8936 ◦ 処理：非同期処理 ◦ メリット：送信の負荷が比較的に少ない ◦ デメリット：リアルタイムではないため、情報伝達に遅延が発生する可能性あり ※SETとは ◦ HTTPなどのプロトコルを使用して交換できる拡張可能なセキュリティイベントトークン ◦ 仕様はJSON Web Token（JWT）形式 ◦ 参考：RFC8417 出典: https://www.rfc-editor.org/rfc/rfc8935.html 　 https://www.rfc-editor.org/rfc/rfc8936.html 送受信の方式 97
98. Copyright OpenID Foundation Japan - All Rights Reserved. SSFユースケース(データ送受信) OPのアカウントが侵害された可能性があるため一度止めてアカウント復旧がしたい RP RP RP OP Credential Compromised Session Revoked Account disabled Recovery Activated インシデント検知 Session Revoked セッション破棄 プロセス セッション破棄 プロセス アカウント無効化 プロセス リカバリーフロー開始 プロセス Account disabled アカウント無効化 プロセス 98 赤字：RISCのメッセージ 黒字：CAEPのメッセージ
99. Copyright OpenID Foundation Japan - All Rights Reserved. ユースケース(マルチプロダクト環境) マルチプロダクト環境でのアカウント不整合 グループ企業プロダクトやマルチプロダクト製品では、ID連携を用いてプロダクト間のアカウント連携を実 装することが一般的。しかし、この従来の方式では、OP側での変更イベントが各プロダクトに自動的には 伝搬されない課題がある。マルチプロダクト環境においてもSSFを導入することで複数のプロダクトを跨い だアカウントライフサイクル全体を統一的かつリアルタイムに管理できるようになる。 99 観点 従来のID連携 SSF導入後の利点 同期タイミング 手動またはバッチ処理 リアルタイム 同期対象 ログイン時点の情報のみ ログイン+ライフサイクル全体 アカウント不整合 頻繁に発生 ほぼ消滅 セキュリティ対応速度 数時間～数日 数秒～数分 複数プロダクト管理 各々独立（煩雑） 一元管理（効率的） コンプライアンス対応 困難（ログが断片的） 容易（統一的な監査ログ） 運用の複雑性 高（各プロダクトに個別対応） 低（SSFが仲介）
100. Copyright OpenID Foundation Japan - All Rights Reserved. SSFにおける考慮点①　各サービス内での考慮事項 SSF導入を導入する各サービスが検討する項目※ １．イベント通知に関してユーザから同意取得するフローを検討する 　SETのSubjectに対して通知を行うことに関する同意を得る（主にユーザからを想定）必要がある。 ⇒標準的な同意取得スキーマはないため、サービスが独自に利用規約を設定する必要がある。 ２．各サービスで各Shared Signalに対する処理の基準を作成する 　特定のShared Signalを送信する基準や、受信した場合にどのような処理を行うかを各サービスで検討す る必要がある ⇒受信時の処理についてはSSFのスコープ外であるためサービスが独自に検討する必要がある。 ３．検知方法、基準を定める必要がある 　各信号を発する前にどんな条件が各信号に対応する事象なのか決めておく必要がある。特にRISCイベ ントをどのように検知する（検知したことにするかを決めておく必要がある） ⇒SSFには検知方法は明示されていないため、独自に考える必要がある。 10 0 ※SSF有識者Tom氏へのヒアリング内容を参考に作成
101. Copyright OpenID Foundation Japan - All Rights Reserved. SSFにおける考慮点②　サービス間での合意形成 SSFを使ってサービス同士を連携するために必要な検討事項※ １．Shared Signalの送受信に関する合意をサービス間で形成する 　Shared Signalを送りあう前に、Shared Signalを勝手に3rd partyに流さない。他の目的に使 用しないなどの合意を結ぶ必要がある。 ⇒決まった要件などはなく標準的な合意スキーマがない 10 1 ※SSF有識者Tom氏へのヒアリング内容を参考に作成
102. Copyright OpenID Foundation Japan - All Rights Reserved. SSF導入にあたっての考慮事項まとめ 10 2 SET送信についての同意 サービス サービス OAuth2.0 SET のやり取り 受信時の処理 受信時の処理 インシデント検知方法と SET送信基準 インシデント SET送信についての同意 ユーザ ユーザ SSF規定範囲 サービス間での同意 SSF導入にあたっての考慮事項全体像
103. Copyright OpenID Foundation Japan - All Rights Reserved. SSFでは、信頼のあるシステム間でアカウント侵害イベントを送受信するための標準的なインターフェース が定義されている。しかし、SSFの仕様では侵害イベントの検出やポリシー評価の方法そのものについて は定義していない。つまり、SSFは「検出された侵害情報をどのように共有するか」を定めているので あって、「侵害をどのように検出するか」は各組織や企業が独自に判断するべき領域である 。 実際にアカウント侵害を検出し、ポリシーを評価する際には、以下のような業界標準やベストプラクティス が一般的に活用されている。 • MITRE ATT&CK®フレームワーク MITRE ATT&CK®は、実際の攻撃者の行動パターンをカテゴリ化した包括的なフレームワーク。 具体例： TA0006「Credential Access（認証情報へのアクセス）」 に基づいて、短時間に大量のログイ ン失敗が検知された場合（パスワードのブルートフォース攻撃の兆候）、当該ユーザーアカウントを自 動的にロックするなどの対応が取られる。 アカウント侵害について 10 3
104. Copyright OpenID Foundation Japan - All Rights Reserved. 本ドキュメントではSSFの仕様を読み解く前の事前知識をつけてもらうことを目的として、SSFの概要と ユースケース、導入時の検討事項を説明した。 ◆SSFとは ・ID連携プロトコルで連携したシステム間でリアルタイムに状況を共有しあうためのメッセージとその送受 信方法を規定した仕様 ・送受信方法を規定したShared Signal Frameworkとメッセージを規定するCAEP、RISCの二つの仕様から 成る ・メッセージの送信者をTransmitter、受信者をRecieverと呼ぶ ◆SSFのユースケース ・アカウント侵害が検知された場合にどのような信号が送受信されるか紹介した ・SSF導入によって従来のID連携の抱える課題の改善が期待できる ◆SSF導入時の検討事項 ・SSFで規定されているのはメッセージと送受信方法のみであるため、そのほかの部分は開発者が独自 に検討を進める必要がある まとめ 10 4
105. Copyright OpenID Foundation Japan - All Rights Reserved. 4. IAL（Identity Assurance Level） 105
106. Copyright OpenID Foundation Japan - All Rights Reserved. OpenIDファウンデーション・ ジャパンの事務局員。 デジタルアイデンティティの 奥深さに惹かれて鋭意勉強中。 担当紹介 川村 和也 登壇者 これからIDを学びたい方でもわかる ようミスリードがないように資料を作 成しました。 IDに興味を持って正しく学ぶきっかけ になれば幸いです。 持⽥ 捷宏 LINEヤフー株式会社 ID連携プロジェクトをきっかけに認証・認可に興 味を持ちはじめました。これから学ばれる人が どこに気をつければよいのか参考になればと 思って関わらせてもらいました。 藏⽥ 貴之 フリー株式会社 担当者
107. Copyright OpenID Foundation Japan - All Rights Reserved. はじめに ▪想定読者 デジタルアイデンティティにおける⾝元確認とは何か、どのようなプロセスかを 知らない読者向け ▪⽬的 デジタルアイデンティティにおける⾝元確認（Identity Proofing）プロセスと 保証レベル（Identity Assurance Level）の理解 ▪本書の役割 ⽶国のガイドラインNIST SP 800 63を取り上げ、⾝元確認プロセスを整理する。 Rev3とRev4の差分については⾔及しない 107
108. Copyright OpenID Foundation Japan - All Rights Reserved. ⽬次 1. ⾝元確認（Identity Proofing）とは 2. IAL（Identity Assurance Level）ごとの要件 3. まとめてみた所感 108
109. Copyright OpenID Foundation Japan - All Rights Reserved. 参考⽂献 NIST SP 800-63 シリーズは、政府情報システムにネットワーク経由でアクセスす る利⽤者（職員、契約者、⼀般利⽤者など）を対象に、 • ⾝元確認（Identity Proofing） • 認証（Authentication） • フェデレーション（Federation） を包括的に定義するガイドラインです。 その中でも、NIST SP 800-63 A は、デジタルアイデンティティにおける⾝元確認 および登録プロセスに関する技術要件を定義しています。 109 デジタルアイデンティティの⾝元確認に関する保証レベルおよび技術要件を体系 的に定義されたNIST SP 800-63-4（最終版）を元に整理しています。 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
110. Copyright OpenID Foundation Japan - All Rights Reserved. わかりやすく説明をするために詳細をお伝えしきれていません。 参考⽂献で⽤いられている⽤語は置き換えている部分があります。 詳細を確認する際は⼀次情報をご参照ください。 注意事項 110 NIST SP 800-63 Digital Identity Guidelines https://pages.nist.gov/800-63-4/sp800-63.html
111. Copyright OpenID Foundation Japan - All Rights Reserved. 1. 身元確認（Identity Proofing）とは 111 4. IAL（Identity Assurance Level）
112. Copyright OpenID Foundation Japan - All Rights Reserved. 住⺠票発⾏のユースケース（窓⼝対応） 112 ⾝近で体験できる⾏政⼿続きの⼀つ、住⺠票発⾏がどのようなステップで⾏われ ているかを確認してみましょう。
113. Copyright OpenID Foundation Japan - All Rights Reserved. Step1：必要書類の提⽰ 113 住⺠票発⾏には、「住⺠票の写し等の交付請求‧申出書」「本⼈確認書類(⾝分 証明書)の原本」の２点を提⽰する必要があります。
114. Copyright OpenID Foundation Japan - All Rights Reserved. Step2：⾝分証明書の確認 114 職員は提⽰された「本⼈確認書類(⾝分証明書)の原本」の有効期限切れや、 偽造‧改ざん等が施された不正なものでないか確認します。 有効期限 問題なし
115. Copyright OpenID Foundation Japan - All Rights Reserved. Step3：本⼈情報との照合 115 職員は申出書に記載されている⽒名と⾝分証明書の⽒名、申し出者本⼈の顔と⾝ 分証明書に掲載されている顔写真を照合します。 氏名一致 顔も一致
116. Copyright OpenID Foundation Japan - All Rights Reserved. Step3：本⼈情報との照合 116 職員は申出書に記載されている⽒名と⾝分証明書の⽒名、申し出者本⼈の顔と⾝ 分証明書に掲載されている顔写真を照合します。 氏名一致 顔も一致 身元確認（ Identity Proofing）とは？ 以下のStepで本人であることを確認するプロセス Step1：必要書類の提示　 Step2：身分証明書の確認 Step3：本人情報との照合
117. Copyright OpenID Foundation Japan - All Rights Reserved. 住⺠票発⾏のユースケース（オンライン対応） 117 今まで窓⼝で対⾯していた⼈の実体を確認することなく⼿続きが⾏われます。 悪意のある⼈のリスクが下がり、なりすましが⾏われる可能性が⾼まる恐れがあ ります。 インター ネット 本当に 正しい人？ 郵送
118. Copyright OpenID Foundation Japan - All Rights Reserved. 住⺠票発⾏のユースケース（オンライン対応） 118 今まで窓⼝で対⾯していた⼈の実体を確認することなく⼿続きが⾏われます。 悪意のある⼈のリスクが下がり、なりすましが⾏われる可能性が⾼まる恐れがあ ります。 インター ネット 本当に 正しい人？ 郵送 NIST SP800-63が定められ、 安全に利用出来るようにルールを整備した
119. Copyright OpenID Foundation Japan - All Rights Reserved. ⾝元確認（Identity Proofing）のプロセスフロー 119 NIST SP800-63では⾝元確認（Identity Proofing）のプロセスフローとして、 「Resolution」「Validation」「Verification」のステップが記載されています。 引用元：https://pages.nist.gov/800-63-4/sp800-63a.html#process-flow
120. Copyright OpenID Foundation Japan - All Rights Reserved. Identity Proofing（⾝元確認）とは？ 120 Identity Proofing（⾝元確認）のプロセスフローを先ほどの例に照らし合わせる と以下の様になります。 インター ネット 郵送 Resolution Step.1：必要書類の提示 Validation Step2：身分証明書の確認 Verification Step3：本人情報との照合
121. Copyright OpenID Foundation Japan - All Rights Reserved. IAL（Identity Assurance Level）とは？ 121 すべてのオンライン⼿続きに必要以上の⾝元確認を⾏うと利便性が下がってしま うため、段階的なレベルを設けたものです。 IAL1 IAL2 IAL3 IAL1 の ID 検証プロセスでは、さまざまな許容可能な手法を使用して悪意のある人物によ る ID の不正な主張を検出すると同時に、ユーザーの採用を促進し、 正当なユーザーの拒 否を最小限に抑え 、アプリケーションの離脱を減らします。 IAL2 の ID 証明には、IAL1 に比べて、なりすまし攻撃やその他の ID 証明エラーをより 軽減するため の追加の証拠、検証、および検証要件が含まれています。 IAL3 は、IAL2 で必要な手順にさらなる厳しさを加え、 なりすましやその他の形式の ID 詐 欺から ID と RP をさらに保護 するために、生体認証情報の比較、収集、および保持の使 用を含む追加の特定のプロセスに従います。 引用元：Identity Proofing Requirements
122. Copyright OpenID Foundation Japan - All Rights Reserved. 2. IAL（Identity Assurance Level）の要件 122 4. IAL（Identity Assurance Level）
123. Copyright OpenID Foundation Japan - All Rights Reserved. NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html IALごとの要件概要 IAL1〜3における⾝元確認の要件を、証拠収集数、⽣体取得、真正性確認⽅法、所有確認範囲に 着⽬し概要を⽐較整理している。※証拠の強度や⾝元確認類型により詳細な要件は異なる。 123 必須要件 IAL1 IAL2 IAL3 身元確認類型 ※いずれか • 現地/対面 • 現地/非対面 • リモート/対面 • リモート/非対面 （IAL1と同様） • 現地/対面 証拠収集 ※いずれか • FAIR ×1 • STRONG ×1 • SUPERIOR ×1 • FAIR ×1, STRONG ×1 • STRONG ×2 • SUPERIOR ×1 （IAL2と同様） 属性収集 全てのコア属性 （身元確認およびサービス提供に必要最低限の属性の集合） （IAL1と同様） 全てのコア属性 および生体情報サンプル 証拠Validation ※いずれか 物理的証拠の場合 • 自動証拠検証 • 目視確認 • 物理的/触覚的検査 デジタル証拠の場合 • デジタルセキュリティ機能の検証 （IAL1と同様） ただしSUPERIORの場合は デジタル署名の検証必須 （IAL2と同様） 属性Validation ※いずれか • 権威ある、または信頼できる情報源との照合によるコア属性確認 • デジタル署名付き属性のデジタル署名検証 （IAL1と同様） （IAL2と同様） Verification ＊次のスライドで補足 ＊次のスライドで補足 ＊次のスライドで補足
124. Copyright OpenID Foundation Japan - All Rights Reserved. NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html IALごとのVerification要件概要 Verificationは、申請者が提⽰した⾝元確認証拠を真正に保有していることを確認する⼯程であ り、IALの上昇に伴い確認対象証拠の範囲や⽣体照合の活⽤、実施環境の厳格性が強化される。 124 項目 IAL1 IAL2 IAL3 確認対象 証拠 証拠のうちいずれか1点 原則すべての証拠 ※実施類型が「現地/対面」の場合は最も強度の高い証拠1点のみ 最も強度の高い証拠1点 ※STRONGまたはSUPERIOR限定 検証方法 ※いずれか • 確認コード • 銀行口座への少額取引確認 • 顔写真照合（自動） • 顔写真照合（目視） 生体情報を用いない方法 • FAIR ◦ 確認コード ◦ 顔写真照合（目視） • STRONG, SUPERIOR ◦ 確認コード（公的機関による検証済みの住所） ◦ 顔写真照合（目視）（一部PAD導入等必須化） デジタル証拠を利用する方法 • FAIR ◦ 確認コード（デジタル証拠に基づき確認された宛先。 携帯電話番号等） ◦ 銀行口座への少額取引確認 ◦ AAL2,FAL2相当での認証,ID連携 • STRONG ◦ AAL2,FAL2相当での認証,ID連携 • SUPERIOR ◦ ローカル認証と暗号的に検証可能な属性提示 生体情報を用いた方法 • 顔写真照合（自動） • 顔写真以外の生体情報の照合（自動） • デバイスまたはアプリケーションへの 認証し保護された顔写真との照合 • 顔写真照合（自動） • 顔写真照合（目視） • 顔写真以外の生体情報の照合（自 動）
125. Copyright OpenID Foundation Japan - All Rights Reserved. IAL2 実装事例紹介 - Login.gov（⽶国の事例） 125 検証プロセスについて • Resolution ◦ ⾝分証明書とセルフィー画像のアップロード ▪ 運転免許証やパスポートブックなどのStrong以上の⾝分証明書のみが許可されている ◦ 社会保障番号（SSN）の⼊⼒ ▪ SSNは⽶国市⺠や永住権保持者などに付与される番号で、⽇本のマイナンバーと類似する個⼈識別番号 である • Validation ◦ ⾝分証明書とSSNの確認 ▪ 画像が改ざんされていないか、権威ある発⾏元と照合するStrong相当のチェック（Validation） • ex） AAMVA（⽶国⾃動⾞管理者協会）, Department of State（国務省）など • Verification ◦ セルフィーと⾝分証明書の画像のStrong相当のチェック ◦ 携帯電話へワンタイムコード送信し本⼈かどうかを確認
126. Copyright OpenID Foundation Japan - All Rights Reserved. ▪リモート/⾮対⾯型 ⾝元確認の各プロセスが完全に⾃動化されており、Proofing AgentまたはTrusted Refereeとの対話を必要としない形式。⾝元確認に⽤いられる場 所およびデバイスは、CSPによって管理されていない。 ▪リモート/対⾯型 申請者が、Proofing AgentまたはTrusted Refereeとの安全なビデオセッションを通じて、⾝元確認プロセスを完了する形式。⾝元確認に⽤いられ る場所およびデバイスは、CSPによって管理されていない。 ▪現地/⾮対⾯型 個⼈が、CSPによって管理されたワークステーションまたはキオスクを操作して実施する形式。Proofing AgentまたはTrusted Refereeとの対話は不 要。プロセスは完全に⾃動化されているが、CSPが管理する物理的な場所およびデバイス上で実施される。 ▪現地/対⾯型 申請者が物理的な環境において、Proofing AgentまたはTrusted Refereeの⽴会いのもとで、⾝元確認プロセスを完了する形式。Proofing Agentまた はTrusted Refereeは、申請者と同⼀場所にいる場合もあれば、キオスクやデバイスを介して対応する場合もある。物理的な場所およびデバイス は、CSPによって管理されている。 — • Proofing Agent：⾝元確認セッションにおいて限定的なリスクベース判断を⾏うCSPのエージェント • Trusted Referee：⾝元確認の例外ケースにおいてリスクベース判断を⾏うCSP、第三者サービス、または RP のエージェント • Applicant Reference：⾝元確認プロセスにおいて申請者の代理は⾏わず、申請者の⾝元や特定属性、状況について保証する第三者 ◦ ※Applicant Referenceはこのページでは登場しませんが後続資料（Appendix）で登場するので事前に説明します。 ⾝元確認類型 ⾝元確認類型が定義されている。実施場所（リモートか現地か）と担当者介在の有無（⾮対⾯か 対⾯か）に基づき、4種類に分類される。 126 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
127. Copyright OpenID Foundation Japan - All Rights Reserved. ▪リモート/⾮対⾯型 メールアドレスを⽤いた確認コード検証を伴う新規ID登録 ▪リモート/対⾯型 ビデオ通話を伴う新規ID登録 ▪現地/⾮対⾯型 コンビニエンスストア等での複合機（専⽤機）を⽤いた住⺠票の発⾏ ▪現地/対⾯型 役所の窓⼝での住⺠票の発⾏ — • Proofing Agent：⾝元確認担当の職員 • Trusted Referee：⾝元確認に関する例外（必要書類を持っていない等）対応 を判断する職員 • Applicant Reference：保護者 ⾝元確認類型（ユースケース事例） 127
128. Copyright OpenID Foundation Japan - All Rights Reserved. ⾝元確認証拠の強度は以下によって決定される • 発⾏プロセスにおける厳格さの⽔準 • 正確性および真正性確認を含む、⼀定の信頼⽔準で検証可能であること • 1つ以上の⾝元確認（Verification）⼿法を⽀援できること ⾝元確認証拠強度 ⾝元確認で使⽤される証拠は、発⾏時の厳格性、真正性担保の⽔準、Verification⼿法の⽀援可否 に応じてFAIR‧STRONG‧SUPERIORの3段階に分類される。 128 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html 強度別分類 概要　＊それぞれ詳細な要件がありますがこの資料では割愛します FAIR 正式な発行手続きと基本的な真正性検証が可能な基礎的信頼水準 の証拠。 STRONG 公的監督下の厳格な手続きで発行され、顔画像等の生体情報を含む高い信頼性 を持つ証拠。 SUPERIOR 対面にて公的監督下の厳格な手続きで発行され、デジタル署名で真正性を検証可能な顔画像等 の生体情報を含む最高水準 の証拠。
129. Copyright OpenID Foundation Japan - All Rights Reserved. 3. まとめてみた所感 129 4. IAL（Identity Assurance Level）
130. Copyright OpenID Foundation Japan - All Rights Reserved. ▪ ⾝元確認（Identity Proofing）の構成 ⾝元確認は、以下の3要素から構成される。 • Resolution：申請者に関する情報を収集し、実在する個⼈として⼀意に識別するプロセス • Validation：提出された証拠や属性情報の真正性‧正確性を確認するプロセス • Verification：申請者が提⽰された証拠の正当な保有者であることを確認するプロセス ▪ IAL（Identity Assurance Level） NIST SP 800-63A-4 では、⾝元確認に関する保証レベル（IAL）を 1〜3の段階で定義している。 各IALにおいて、リスク⽔準に応じて以下が規定される。 • ⾝元確認類型（実施形態） • 収集すべき証拠の数および強度 • 収集すべき属性 • 証拠および属性に対するValidation要件 • 証拠に対するVerification要件 まとめ 130
131. Copyright OpenID Foundation Japan - All Rights Reserved. まとめてみた所感 131 • デジタルアイデンティティにおける⾝元確認においても、IAL3では現地‧対⾯での実施が 必須とされており、完全なオンラインのみでは完結しない点が印象的でした。 • IAL1〜3それぞれの具体的なユースケースは定義されず、各サービスにおいて想定リスク を踏まえた上で適切な⽔準を策定する必要があることを改めて理解しました。 • デジタル庁の「DS-511 ⾏政⼿続等での本⼈確認におけるデジタルアイデンティティの取扱 いに関するガイドライン」やOIDF-J KYCWGの「⺠間事業者向けデジタル本⼈確認ガイド ライン」の意義についても理解が深まりました。 • IALに依らない共通要件では「継続的な評価」が強調されており、導⼊後も継続的に⾒直す 姿勢が重要である点が印象的でした。 • エラーハンドリングの整備も求められており、初めて⾝元確認サービスを検討する際の重 要な視点が整理されていると感じました。 • 保証レベルによらず多くの共通要件が定められている点も印象的で、前提要件がどのよう な観点で構成されているのかを把握することができ、理解を深める機会となりました。
132. Copyright OpenID Foundation Japan - All Rights Reserved. # Appendix 132 4. IAL（Identity Assurance Level）
133. Copyright OpenID Foundation Japan - All Rights Reserved. 133 4. IAL（Identity Assurance Level） IALによらない共通要件 ＊必須要件に着目してまとめています
134. Copyright OpenID Foundation Japan - All Rights Reserved. IALによらない共通要件 IALによらずベースとして⾝元確認プロセスの運⽤規定の策定、不正管理、プライバシーリスク評 価、セキュリティ制御の適⽤が規定されるほか、⽣体的‧⾏動的特徴に基づく個⼈の⾃動認識の 精度基準や偽造検知、例外処理（保証⼈制度）、救済⼿段、IAL昇格に関する要件がある。 1. 運⽤⽂書：16の必須項⽬を含む運⽤規程の策定、⽂書化された⼿順の遵守、およびRPへの規程提供等が規定される。 2. 不正管理：死亡照合の実施、不正検知プログラムの品質維持、RPへの通知体制、および内部脅威対策の実施等が規定される。 3. プライバシー：リスク評価の実施、情報の最⼩化、収集⽬的の通知、明⽰的な同意取得、および職員訓練等が規定される。 4. 顧客体験：障壁の特定と緩和策の策定、評価概要のRP提供、および評価参加の強制禁⽌等が規定される。 5. セキュリティ：保護チャネルの利⽤、⾃動攻撃対策の実装、およびNIST基準に基づく適正な安全管理等が規定される。 6. 救済：問題解決のための救済窓⼝の設置、不服申し⽴て⼿段の提供、および救済メカニズムの有効性評価等が規定される。 7. 連邦機関向け：SAOP協議、SORNやPIAの公開、および外部CSP利⽤時の独⾃プライバシー影響評価等が規定される。 8. 確認コード：6桁以上の乱数⽣成、配信⼿段別の有効期限遵守、および使⽤後のコード即時無効化等が規定される。 9. 継続コード：64ビット以上の乱数⽣成、ハッシュ化保存、および⼊⼒試⾏回数の制限（スロットリング）等が規定される。 10. 通知：成功時の通知送付、実施⽇や異議申⽴⽅法の記載、および検証済みアドレスへの送信等が規定される。 11. ⽣体認識：明⽰的同意、精度基準の維持、⼈⼝統計学的偏りの外部テスト、およびテスト結果の公表等が規定される。 12. 写真⽐較：担当者の専⾨訓練と年次評価、リモート⽤の⾼画質機材提供、および訓練内容の記録‧公開等が規定される。 13. 証拠妥当性：⾃動検証の精度確保、実物の存在確認（ライブキャプチャ）、および担当者の訓練と機材配備等が規定される。 14. 注⼊防⽌：仮想カメラ等の検知、メディア改ざん分析、および操作中のランダムな指⽰（しぐさ等）の実装等が規定される。 15. 例外処理：保証⼈制度のポリシー策定、未成年者へのCOPPA準拠、および⾝元参照⼈の利⽤⼿順等が規定される。 16. IAL昇格：最⾼レベル認証後の新規証拠検証、および昇格プロセスに関する運⽤規程への明⽂化等が規定される。 134 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
135. Copyright OpenID Foundation Japan - All Rights Reserved. 運⽤⽂書に関する要件 CSPはIAL達成のための具体的な⼿順を記す「運⽤規程」を策定‧遵守しなければならない。規程 には⾝元確認⼿順の詳細だけでなくエラーケースの考慮や顧客体験の評価⽅針等16の最⼩要素を 含める義務がある。また、当該規程をRPへ提供‧共有することも必須要件である。 1. 提供するIALにおいて、申請者の⾝元確認を⾏うためにCSPが実⾏する具体的な全⼿順を含む、完全なサービス説明 2. 利⽤可能な⾝元確認プロセスの種類、IAL毎の証拠と属性の収集要件、個⼈情報の収集⽬的、および⽣体的‧⾏動的特徴の収集‧利⽤‧保持の⽬的についての、 申請者への通知に関する⽅針 3. 申請者がすべての要件を満たした後、⾝元確認プロセスを遅滞なく適時に完了させることを保証するための⽅針 4. 受理する証拠の種類、およびそれらが各IALの強度要件をどのように満たすかについての論理的根拠 5. Identity Evidence（主張されているアイデンティティが現実世界に実在することを裏付ける情報または⽂書：⾝分証明証）のValidationとVerificationの⽅針およ び⼿順、ならびに⾝元確認業務に従事する職員の訓練‧資格要件 6. 証拠のValidationとVerificationのためにCSPが使⽤する特定の技術 7. ⼗分な証拠を持たない申請者への⽀援策、および⾝元確認プロセスにおける例外やエラーへの対応に関する⽅針と⼿順 8. CSPが定めるコア属性（⾝元確認およびサービス提供に必要最低限の属性の集合）の定義、およびそれらの属性をValidationするために使⽤する権威ある情報源 や信頼できる情報源 9. データソース、統合ベンダー、⽣体認識アルゴリズム等のサービス変更をRPに通知‧管理するための⽅針 10. 不正アカウントの特定‧是正、およびRPや影響を受ける個⼈への通知に関する⽅針と⼿順を含む、不正管理に関する⽅針 11. アカウントリカバリー、アカウント放置、または規定上の再Verification要件など、利⽤者の再Verificationが必要となる具体的な条件に関する⽅針 12. 定期レビューのタイミング、および評価の更新が必要となる特定の条件を含む、プライバシーリスク評価の実施⽅針 13. テスト⼿法、定期レビューのタイミング、および予定外レビューを実施する条件を含む、顧客体験の評価⽅針 14. 事業停⽌‧合併‧譲渡時における、個⼈情報‧機密情報‧⽣体的‧⾏動的特徴の保持‧保護‧削除に関する⽅針 15. NIST SP 800-63で別途規定された、パフォーマンスメトリクス（業務指標）の報告および内容更新に関する⽅針 16. 利⽤者の死亡等による操作不能時における、アカウントへのアクセスまたはアカウント削除に関する⽅針 135 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
136. Copyright OpenID Foundation Japan - All Rights Reserved. 不正管理に関する要件 ▪ CSPにおける不正管理 • 不正の特定‧検出‧調査‧報告‧解決を⾏うための「不正管理プログラム」を確⽴し、運⽤規程に⽂書化すること。 • 実装前に、すべての不正チェックおよび不正低減技術のプライバシーリスク評価を実施すること。 • 利⽤者が⾃ら不正被害や⾝元確認プロセスへの妨害を報告できる⾃⼰報告機構と調査能⼒を確⽴すること。 • プロキシやDENYリストに登録されたIPアドレスなど、⾼リスク指標を⾒つけるためにリモート通信チャネルを分析すること。 • ⾝元確認に成功しなかった申請者が、信頼可能な権威のある情報を使って申請した属性情報の正確性を推測できないよう対策を講じること。 • 不正リスク軽減の有効性を維持するために、不正チェックおよび不正低減技術の性能を継続的に監視すること。 • 不正疑い事案、または確定した不正事案をRPへ伝達するための技術的またはプロセス的な仕組みを確⽴すること。 • 全ての⾝元確認プロセスにおいて、信頼できる情報源等を⽤いて申請者が死亡していないか死亡記録を照合し、⽣存確認をすること。 • 有⼈での⾝元確認プロセスにおいて、⾝元確認担当者に不正検知訓練の実施と、不正疑い事案をフラグ⽴てして調査‧対応するためのツールを提供すること。 • ⾝元確認プロセスや決定に直接関与または介⼊可能な担当者の共謀を防ぐため、CSPは内部脅威対策を実装して不正を検知‧防⽌すること。 • AIや機械学習をサービスに利⽤する場合、NIST SP 800-63で別途規定された関連要件を遵守すること。 ▪RPにおける不正管理 • CSPが不正データを連絡‧共有するための窓⼝を設置すること。 • CSPが導⼊している不正チェックおよび不正低減技術に対して、独⾃にプライバシーリスク評価を実施すること。 • 連邦機関 の場合は、加えてNIST SP 800-63で別途規定された要件に従い、本事項を実装すること。 • CSPの不正管理プログラムや技術の有効性について、定期的なレビューを実施すること。 • CSPが代替管理策（IALに対して規定されている標準的な管理策の代わりに⽤いられる管理策）として実装した不正チェックおよび低減技術を評価し、内部のリス ク基準に適合していることを確認した上で、連携前に当該代替策を⾃組織の DIAS（デジタルアイデンティティに関するリスク管理プロセスの結果を⽂書化したも の） に記録すること。 ▪不正検知失敗時の対応 • CSPは各不正チェックに伴う具体的なアクションを⽂書化し、RPと共有すること。 • CSPは不正チェックによって⽣じた問題を申請者が解決できるように、救済⼿順を確⽴すること。 • 無⼈での⾝元確認プロセスで失敗した申請者に対してTrusted Refereeを介在させる場合、Trusted Refereeに判断の参考として失敗理由の要約を共有すること。 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html ⾝元確認プロセスを提供するCSPだけでなく利⽤するRPにおいても不正管理に関して要件が定め られており、CSPは不正管理プログラムの確⽴、RPは対策の定期的な評価を⾏う等義務がある。 136
137. Copyright OpenID Foundation Japan - All Rights Reserved. プライバシーに関する要件 ▪ プライバシーリスク評価 • ⾝元確認や登録、で⽤いるプロセスにおいてプライバシーリスク評価を実施‧⽂書化すること。 • 少なくとも、プライバシーリスク評価では、以下に関連するリスクを評価すること。 • ⾝元確認、登録、または不正管理を⽬的とした個⼈情報の取扱い • 本規定で定められた必須要件を超えて、CSP が申請者の⾝元確認を⾏うために追加で実施する⼿続き • 法令または法的⼿続への対応を除き、⾝元確認および登録の範囲外の⽬的で⾏われる個⼈情報の取扱い • アイデンティティ記録および個⼈情報の保存期間 • 個⼈情報に該当しないが、集約またはアルゴリズム（例：AI/MLツール）による処理によって個⼈を識別し得る情報の取扱い • CSP に代わって第三者サービスが処理する個⼈情報 • プライバシーリスク評価の結果に基づき、収集‧処理する個⼈情報の機密性、完全性、可⽤性等を維持するための対策を⽂書化すること。 • 個⼈情報の処理に影響を及ぼす⾝元確認サービスの変更を⾏う際は、常にプライバシーリスクを再評価し、評価内容を更新すること。 • 運⽤規程に従い評価を定期的に⾒直し、個⼈情報の収集や処理に関する現在のリスクが正確に反映されていることを継続的に確認すること。 • RPが⾃らのプライバシーリスク評価を⾏えるような粒度で、CSPはプライバシーリスク評価の要約を、サービスを利⽤するすべてのRPに提供すること。 • 加⼊者アカウント内で管理および保持されているすべての個⼈情報の処理に対しても、個別にプライバシーリスク評価を実施すること。 ▪ 追加のプライバシー保護対策 • 個⼈情報の処理は、⾝元確認や不正緩和、認可判断等に必要最⼩限の範囲に留めること。 • 機密情報にアクセスする全担当者および外部サービスプロバイダーにプライバシー訓練を⾏うこと。 • Resolutionの際に公的機関の代理で社会保障番号を収集する場合、適切な法令に従って申請者に通知すること。 • 属性情報および個⼈情報収集時に、⽬的、必須∕任意、保存内容、未提供時の影響、記録保存要件の詳細を通知すること。 CSPはプライバシーリスク評価の実施‧更新と、RPへの要約提供等が義務付けらる。また、個⼈ 情報処理の最⼩化、機密情報にアクセスする担当者への訓練、申請者への個⼈情報等収集の⽬的 などの通知といったプライバシー保護措置の実施も義務付けられる。 137 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
138. Copyright OpenID Foundation Japan - All Rights Reserved. 顧客体験に関する要件 • 顧客体験上の課題を⽣じさせうるプロセスや技術を特定するために⾝元確認 プロセスの各要素を評価すること。 • ユーザーが直⾯する問題や⼀般的な課題を含む顧客体験評価の要約をRPへ提 供すること。 • 評価の結果に基づき、課題を軽減するための対応策を⽂書化すること。 • 定期的および顧客体験に影響のあるサービスの変更時に、顧客体験リスクの 再評価を実施すること。 • リスク評価への申請者の参加を強制しないこと。 CSPは顧客体験上の課題評価と評価結果に基づく課題の軽減策の⽂書化等が義務付けられる。ま た評価結果の要約をRPへ提供や、定期的な⾒直しも義務付けられる。なお、申請者のリスク評価 への参加強制は禁⽌されている。 138 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
139. Copyright OpenID Foundation Japan - All Rights Reserved. セキュリティに関する要件 • ⾝元確認プロセスにおけるすべてのオンライン取引を、認証された保護チャネルを 通じて実施すること。 • ボット検知や⾏動分析、WAF、ネットワーク分析等を⽤いて、⾝元確認プロセスへ の⾃動攻撃対策を実装すること。 • ⾝元確認プロセスの⼀環として収集されるすべての個⼈情報は、情報の機密性およ び完全性を維持するために保護すること。これには、保存データの暗号化や、認証 された保護チャネルを⽤いた情報の送受信も含まれる。 • NIST RMF（Risk Management Framework）に基づきリスク評価を⾏い、IALに関 わらずSP 800-53の「中」相当の管理策を適⽤すること。 • 外部サービス利⽤のリスクを評価し、NIST SP 800-161に従い管理を⾏うこと。 保護チャネルの利⽤や、⾃動攻撃対策、個⼈情報の機密性および完全性の維持、RMFによるリス ク評価が義務付けられる。またIALを問わずSP 800-53の「中」管理策を適⽤も義務付けられる。 139 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
140. Copyright OpenID Foundation Japan - All Rights Reserved. • ⾝元確認プロセスにおける失敗や遅延、難しさ、侵害されたアカウントのリ カバリなど、申請者の申⽴てや問題に対する救済⽅法を提供すること。 • 申請者が容易に⾒つけ出し、簡単に利⽤できる救済⽅法にすること。 • 申⽴てや問題の解決に向けた救済⽅法の有効性について、CSPが評価するこ と。 救済に関する要件 CSPは⾝元確認プロセスにおける失敗や侵害されたアカウントのリカバリ等に向けた、発⾒しや すく使いやすい救済⼿段の提供が義務付けられる。また、申⽴てや問題に対する救済⽅法の有効 性を評価する義務もある。 140 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
141. Copyright OpenID Foundation Japan - All Rights Reserved. SAOPと協議し、プライバシー法等の適⽤を確認すること、SORNとPIAを公開す ること、外部CSP利⽤時も独⾃のPIAを実施すること等が義務付けられている。 • SAOP（Senior Agency Official for Privacy）：機関における個⼈情報の取扱いについて、法令遵守‧リスク管理‧ 影響評価を統括するプライバシー責任者 • SORN（System of Records Notice）：連邦機関が⾃らの記録システムの内容を官報で公表するための告知⽂書 • PIA（Privacy Impact Assessment）：個⼈情報の取扱いに伴うプライバシーリスクを特定‧軽減し、法令等への適 合を確保するための評価⼿法 連邦機関に対する追加要件 連邦機関向けの追加要件も個別規定されている。 ＊この資料では概要のみの説明とさせていただきます。 141 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
142. Copyright OpenID Foundation Japan - All Rights Reserved. 確認コードに関する要件 将来の連絡のために、申請者が郵送先住所、メールアドレス、または電話番号にアクセスできる ことを確認するために利⽤される確認コードに関して、⽣成要件や提⽰要件、有効期限に関する 要件や無効化要件が定義される。 142 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html ⽬的 将来の連絡のために、申請者が郵送先住所、メールアドレス、または電話番号にアクセスできることを 確認すること。 生成要件 承認された乱数ビット生成器で生成した少なくとも 6 桁の 10 進数字（または同等のもの）を含むこと。 有効期限の最大値要件 • 米国本土内の検証済み郵送先住所に送付された場合：21 日 • 米国本土外の検証済み郵送先住所に送付された場合：30 日 • 検証済み電話番号（SMS または音声）に送付された場合：10 分 • 検証済みメールアドレスに送付された場合：24 時間 無効化要件 使用された時点で 無効化すること。
143. Copyright OpenID Foundation Japan - All Rights Reserved. 継続コードに関する要件 未完了の⾝元確認または登録プロセスと申請者との紐付けを再確⽴するために利⽤される継続 コードに関して、⽣成要件や提⽰要件、検証試⾏回数に関する要件や無効化要件が定義される。 143 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html ⽬的 未完了の身元確認または登録プロセスと申請者との紐付けを再確立すること。 生成要件 承認された乱数ビット生成器で生成した少なくとも 64 ビットを含むこと。 検証試行回数要件 検証はNIST SP-800-63に規定されたスロットリング要件の対象とすること。 保管要件 FIPS（NIST によって策定され、連邦政府の各省庁および機関による採用および使用を目的とした標 準）承認済みまたは NIST 推奨の一方向関数（計算上実質的に不可逆になる方法）を用いてハッシュ 化された形式で保存すること。 無効化要件 使用された時点で 無効化すること。 有効期限要件＊ 身元確認完了までに相当な時間を要する可能性があることから定義しないため、CSP が自らのプロセ ス等に基づいて決定する必要がある。
144. Copyright OpenID Foundation Japan - All Rights Reserved. ⾝元確認通知に関する要件 ⾝元確認通知は、申請者が⾝元確認に成功したことを通知し、当該⾝元確認イベントおよびその後の登録に関する 情報を提供するために、検証済みの連絡先に送付される。 • すべての IAL において検証済みの郵送先住所または電話番号宛に送付すること。 • ただし IAL1 においては、検証済みのメールアドレス宛に送付してもよい。 • アイデンティティサービスの名称および⾝元確認完了⽇を含む⾝元確認イベントの詳細を含めること。 • 受信者が⾝元確認イベントへの関与を否認する場合に取るべき⾏動について、連絡先情報を含む明確な指⽰を 提供すること。 • 組織または CSP が収集した情報のセキュリティおよび機密性をどのように保護しているかに関する情報を提 供すること。 • 受信者がアイデンティティサービスの利⽤者として負う責任に関する情報を提供する。 • サービス利⽤者が、当該アイデンティティサービスによって⾝元確認されたことを否認した場合、CSP または RP は、確⽴された不正管理および救済⽅針に従って対応すること。 申請者が⾝元確認に成功したことを通知し、当該⾝元確認イベントおよびその後の登録に関する 情報を提供するために、検証済みの連絡先に送付される通知において、送信先要件や内容、通知 内容を否認するための情報提供等が義務付けられる。 144 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
145. Copyright OpenID Foundation Japan - All Rights Reserved. ⽣体認識の使⽤に関する要件（1/3） ⽣体認識とは、⽣体‧⾏動的特徴に基づいて個⼈を⾃動的に認識することであ る。⾝元確認プロセスにおいては⽣体認識により、申請者が提⽰された⾝元証明 書の正当な主体であることのVerification、新たな⾝元証明書やクレデンシャルと 個⼈の結び付け、重複登録の排除を⾏うことができる。 145 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
146. Copyright OpenID Foundation Japan - All Rights Reserved. ▪⾝元確認プロセスで⽣体認識を利⽤する際の要件 • ⽣体認識のすべての利⽤について、収集される⽣体‧⾏動的情報の内容、保存および保護⽅法、適⽤される法令に整合した削除⽅法を含む、明確で⼀般公開され た情報を提供すること。 • ⽣体‧⾏動的情報を収集および利⽤するにあたり、すべての申請者から明⽰的かつ⼗分に理解された同意を取得すること。 • ⽣体認識利⽤に関する同意記録を保存し、対応するアカウントと関連付けること。 • すべての⽣体‧⾏動的情報について、⽂書化され、かつ⼀般公開された削除プロセスおよびデフォルトの保持期間を定めること。 • 保持期間は、サービスを提供する地域および業界に適⽤される法令、⽅針および規則と整合すること。 • ⽣体‧⾏動的情報の削除要求をサポートしない場合、その⽅針についての規制上、法的、またはリスクベースの正当化理由を公開⽂書として⽰すこと。 • ⽣体認識アルゴリズムおよび攻撃検知アルゴリズムについて、⼈⼝統計グループ（年齢、性別等）ごとの性能を含む性能特性を評価するため、独⽴した第三者 （認定された試験機関や研究機関など）による定期的なテストを受けること。 • 実運⽤環境およびユーザー（及び端末）と実質的に同等の条件下で、⽣体認識技術の性能および⼈⼝統計学的影響を評価すること。 • ユーザーを含む評価を⾏う場合、ユーザーの参加は任意でなければならない。 • 申告されたアイデンティティのVerificationにおいて1対1の⽐較アルゴリズムを⽤いる場合、以下の性能基準を満たすこと。 • 誤⼀致率：0.01% 以下、誤不⼀致率：1%以下。 • プライバシーリスク評価に基づいて、Resolutionまたは重複排除を⽀援する⽬的で1対多の識別を利⽤してもよい。 • 最低性能要件として誤識別率は0.1%以下を満たすこと。 • 誤識別率の試験においてテストで利⽤するデータ数は現在または予定されている運⽤規模の90％以上にすること。 • ⾃動検索結果が正しいこと、誤識別でないことを確認するための⼿動レビューを⾏わずに利⽤者の登録を拒否しないこと。 • ⽣体認識によるVerificationは、特定の⼈⼝統計グループにおける性能が、全体集団の性能より25％を超えて悪化しないこと。 • しきい値を⼈⼝統計グループごとに変更するのは実運⽤できないので固定にすること。 • ⽣体認識性能に影響を及ぼす場合には、評価において考慮すべきデモグラフィック属性として、少なくとも性別、年齢および肌の⾊を含めること。 • すべての⽣体認識性能試験は、ISO/IEC 19795-1:2021および ISO/IEC 19795-10:2024（ISO/IEC 19795：⽣体認識性能試験および報告に関する国際規格） に適合 すること。 • ⽣体認識アルゴリズムの性能試験結果および⽣体認識システムの運⽤試験結果を⼀般公開すること。 ⽣体認識の使⽤に関する要件（2/3） ⽣体‧⾏動的情報の⽤途や削除⽅針の公開と、申請者の明⽰的な同意取得‧記録が義務化され る。また、保持期間の規定や、⽣体認識アルゴリズムの性能‧⼈⼝統計学的影響に関する第三者 機関による定期テストの実施も義務付けられる。 146 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
147. Copyright OpenID Foundation Japan - All Rights Reserved. ⽣体認識の使⽤に関する要件（3/3） ▪申請者から⽣体‧⾏動的特徴を収集する際の要件 • ⽣体‧⾏動的特徴が申請者本⼈から取得されたものであることについて合理的な保証が得られる⽅法で収集す ること。 • ⽣体‧⾏動的特徴をリモートで収集‧⽐較する場合、プレゼンテーション攻撃検知（PAD）を実装し、IAPAR が0.07%未満の性能要件を満たすこと。 • プレゼンテーション攻撃：⽣体‧⾏動的情報の取得サブシステムに対して⽣体識別システムを誤作動さ せる⽬的で提⽰する攻撃 • IAPAR（Impostor Attack Presentation Accept Rate）：提⽰されたデータが、PADによって誤って「正 当」と受け⼊れられてしまう割合 • すべてのPAD試験は ISO/IEC 30107-3:2023（PADに関する国際規格） に適合すること。 • ⽣体‧⾏動的特徴を現地で収集する場合、⽣体‧⾏動的特徴源（指や顔など）について不⾃然な素材がないか をオペレーターが⽬視確認し、⾝元確認プロセスの⼀部として実施すること。 収集した⽣体‧⾏動的特徴が申請者本⼈の情報である合理的保証に加え、リモート時はPAD （IAPAR<0.07）による不正検知、現地の場合は取得元に不⾃然な素材がないかオペレーターによ る⽬視確認が義務付けられる。 147 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
148. Copyright OpenID Foundation Japan - All Rights Reserved. 顔画像の⽬視⽐較に関する要件 ▪顔画像の⽬視⽐較をVerificationオプションとして提供する際の要件 • Proofing AgentおよびTrusted Refereeは、顔画像の⽬視⽐較を実施するための訓練を受けること。 • この訓練には、顔の特徴、固有の特徴、ならびに申請者と提⽰された証拠との⼀致または不⼀致を判断 するためのその他の指標を識別するための技術および⼿法を含めること。 • Proofing AgentおよびTrusted Refereeは、顔画像の⽬視⽐較を実施する能⼒について評価されること。 • これらの担当者は年に⼀度再評価され、必要に応じて是正的な再訓練を受けること。 • 訓練は、親族、双⼦、外⾒が類似した⼈物との⽐較など、現実世界で想定される攻撃シナリオを反映し た内容で設計すること。 • リモートでの有⼈トランザクションにおいて顔画像の⽬視⽐較を実施するProofing AgentおよびTrusted Refereeに対し、⾼品質な画像フィード、⾼解像度モニター、画像解析ソフトウェアなど、正確な⽐較を⽀援 するリソースを提供すること。 • 顔画像の⽬視⽐較に関する訓練および評価⼿順を⽂書化し、要求があった場合には RP に提供すること。 • これらの要件は、⾃動化された⽣体‧⾏動的特徴⽐較が失敗（例：Resolutionまたは重複排除のために実施 される 1対多照合の失敗）した場合の⼿動レビューとして実施される顔画像の⽬視⽐較にも適⽤すること。 顔画像の⽬視⽐較を実施する者には顔等の特徴識別や双⼦等の⽐較に関する訓練と年次評価が義 務付けらる。リモート時には顔画像が適正にに⾏えるよう機器環境の提供が必須であり、⾃動照 合失敗時の⼿動確認にも本要件が適⽤される。 148 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
149. Copyright OpenID Foundation Japan - All Rights Reserved. 物理的証拠のValidationに関する要件（1/3） 物理的証拠のValidationは、光学的な取得および検査によって⾏うことも、 Proofing AgentおよびTrusted Refereeによる⽬視検査によって⾏うこともでき る。CSP は、⾝分証明証の真正性を評価するために、これらのいずれか、または 両⽅のプロセスを採⽤することができる。 このページの⼀⽂要約 149 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
150. Copyright OpenID Foundation Japan - All Rights Reserved. 物理的証拠のValidationに関する要件（2/3） ▪ 光学的取得および検査を⽤いる場合の要件 • ⾃動化された証拠検証技術は、以下の性能指標を満たすこと。 • 書類誤受⼊率（DFAR：Document false acceptance rate）が 0.1 ％以下である。 • 書類誤拒否率（DFRR：Document false rejection rate）が 0.1 ％以下である。 • 証拠に機械読取領域（MRZ）またはバーコードが含まれている場合、光学的取得および検査では、MRZデータと証拠に印 字されたデータの⼀貫性を⽐較すること。 • 検証プロセス中の書類のライブ取得を実装し、パッシブまたはアクティブ（ユーザーに対する動作要求の有無の差異）な 書類存在確認を実装すること。 • ライブ取得技術：書類が物理的に存在していること、ならびに⾝元確認セッション中に取得された画像が改ざんさ れたデジタルコピーではないことを確認する。 • 採⽤している光学的取得および検査技術の性能を、実運⽤環境およびユーザー（及び端末）によって提⽰される証拠の種 類と実質的に同等の条件下で評価すること。 • これらの試験は、CSP が光学的取得および検査による検証を許可しているすべての⾝分証明証の種類を考慮するこ と。 • 試験にユーザーの書類、個⼈情報、または画像を使⽤する場合、それは任意であり、ユーザーへの通知および同意 を得た上で⾏うこと。 • 試験結果を⼀般に公開すること。 ＊これらの要件は、物理的な⾝元確認証拠の画像を取得および検証する技術に適⽤されるものであり、証拠⾃体に組み込まれた PKI やその他の暗号技術に依存する検証⼿法には適⽤されない。 ⾃動化された証拠検証技術の精度（DFAR/DFRR≦0.1）やMRZデータと印字されたデータの⼀致 確認、物理的な存在を⽰すライブ取得の実装が義務化される。また、実運⽤環境に即したテスト 実施と結果の公開も義務化される。 150 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
151. Copyright OpenID Foundation Japan - All Rights Reserved. 物理的証拠のValidationに関する要件（3/3） ▪⽬視検査を⽤いる場合の要件 • Proofing AgentおよびTrusted Refereeは、CSP がサポートするすべての証拠形式を⽬視検査するための訓練を受け、必要 なリソースを提供されること。 • この訓練には、以下を含めること。 • 証拠の真正なレイアウトおよびタイポグラフィ（書体、サイズ等） • 物理的なセキュリティ特徴（例：浮き出し⽂字、ホログラム、マイクロプリント） • 特徴を評価するための技法（例：使⽤するツール、触覚検査が必要な箇所、特定の特徴を確認するための操 作） • 改ざんの⼀般的な兆候（例：ラミネートの損傷、画像の改変） • Proofing AgentおよびTrusted Refereeは、訓練に基づき、証拠を⽬視検査する能⼒について評価されること。 • これらの担当者は、年に⼀度、または証拠検証プロセスに対する重⼤な脅威が特定された場合に再評価され、必要 に応じて是正的な再訓練を受けること。 • Proofing AgentおよびTrusted Refereeには、⾝分証明書の種類に応じて、拡⼤鏡、紫外線ライト、バーコードリーダーな ど、⽬視検査を⽀援するための専⾨的なツールおよび機器が提供されること。 • リモートで⽬視検査を⾏うProofing AgentおよびTrusted Refereeには、提⽰された証拠を効果的に検査できる⼗分に⾼品 質な画像を提供可能なデバイスおよびインターネット接続が提供されること。 • 証拠の⽬視検査に関する訓練および評価⼿順を⽂書化し、要求があった場合には RP に提供すること。 ＊本ガイドラインは、⾝分証明書の種類および組み合わせが⾮常に多様であるという理由から、セキュリティ特徴の網羅的な⼀覧 を提⽰するものではない。⾃らが受け⼊れる⾝分証明書の種類に特化した証拠検証訓練を提供する必要がある。 物理的証拠のValidationを実施する者への偽造検知訓練と年次評価、適切なツール提供が義務づ けられる。またリモート時は⾼品質な通信環境が必須で、⼿順の⽂書化とRPへの公開も義務付け られる。 151 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
152. Copyright OpenID Foundation Japan - All Rights Reserved. デジタル注⼊防⽌および偽造メディア検知に関する要件（1/2） ▪リモートでの⾝元確認全般に適⽤される要件 • ⾝元確認プロセス中にデジタルメディアが真正なセンサーによって⽣成されているという信頼性を⾼めるため の技術的統制（例：仮想カメラ、デバイスエミュレーター、ジェイルブレイクされたデバイスの検知）を実装 すること。 • ⾝元確認プロセス中に提出されたすべてのデジタルメディアについて、改変、加⼯、改ざん、または偽造の可 能性を⽰す痕跡や指標を分析すること。 • ⾃動画像解析アルゴリズムは、性能のベースラインを確⽴し、システムによって⽣成される偽陽性率お よび偽陰性率の想定値を特定するために、利⽤可能な攻撃⽤アーティファクト（偽造‧改変された画像 および動画など）および真正なメディアを⽤いて試験されること。 • 試験に使⽤された攻撃⽤アーティファクトの種類および対応する偽陰性率は⽂書化され、要求があった 場合には RP に提供すること。 • リモートでの⾝元確認プロセス中のデータ交換において、認証された保護チャネルのみを使⽤すること。 ⽣成AI等を利⽤したデジタル注⼊攻撃に対し、仮想カメラの検知やメディアの改ざん分析の実 施、リモート環境では保護された通信経路の使⽤が義務付けられる。⾃動画像解析は攻撃データ を⽤いて試験し、その性能指標を要求があればRPへ開⽰することも義務付けられる。 152 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
153. Copyright OpenID Foundation Japan - All Rights Reserved. リモートで⼈が証拠を収集する際の要件として、担当者への⾼遅延や動画と⾳声のズレ等改変さ れたメディアの聴講検知訓練実施や、ランダムな動作指⽰を⾏う「human-in-the-loop」の導⼊ が義務付けられる。 ▪リモートでの有⼈での収集に追加で適⽤される要件 • Proofing AgentおよびTrusted Refereeに対し、改変されたメディアの兆候を 識別するための訓練を実施すること。 • 偽造または改変されたメディアが検知される可能性を⾼めるため、取得プロ セスにランダムな「⼈間介在（human-in-the-loop）（例：利⽤者に特定の 動作を求める、取得センサーと顔の間で物体を動かすよう要求する）」を組 み込むこと。 デジタル注⼊防⽌および偽造メディア検知に関する要件（2/2） 153 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
154. Copyright OpenID Foundation Japan - All Rights Reserved. 例外およびエラー処理に関する要件（1/7） ⾝元確認プロセス全体を通じて、エラーや失敗が発⽣し得るポイントは多数存在する。 （下記は⼀例） • プロセス上の失敗（例：利⽤者が必要な証拠を所持していない） • 技術的な失敗（例：連携サービスが利⽤できない） • 利⽤者エラーによる失敗（例：申請者がリモート検証ツールを⽤いて⾝元確認証拠 の鮮明な画像を取得できない） ⾝元確認サービスのアクセシビリティを向上させ、顧客体験上の課題に対応するため、 エラーへの対応および例外の取り扱いに関する運⽤プロセスを⽂書化すること。 このページの⼀⽂要約 154 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
155. Copyright OpenID Foundation Japan - All Rights Reserved. ▪ Trusted Referee に関する要件 • Trusted Refereeサービスの利⽤可否および取得⽅法について、⼀般に周知すること。 • 運⽤⽂書の⼀部として、Trusted Refereeの利⽤に関する書⾯による⽅針および⼿順を確⽴すること。 • 申請者の個別事情に基づいてリスクベースの判断を⾏い、⾝元確認を成功させることができるよう、Trusted Refereeを訓練および認定する こと。 ◦ 当該訓練には、少なくとも以下を含めること。 ▪ 書類の識別および検証（様式、セキュリティ機能、レイアウト、タイポグラフィなど） • 関連：物理的証拠のValidationに関する要件 ▪ 不正書類の兆候（損傷、改ざん、変更、捏造、偽造など） ▪ 提⽰された書類と申請者との顔画像⽐較 ▪ 申請者に⾒られるソーシャルエンジニアリングの兆候（動揺、混乱、強要など） ▪ 証拠の⽬視検査および顔画像⽐較能⼒に関する年次レビュー • Trusted Refereeが関与した⾝元確認セッションについて、利⽤理由、Trusted Refereeの⾝元、提⽰された証拠、実施されたプロセス、判 断結果および否定的判断の場合の理由を含む記録を作成すること。 • 現地での対⾯型またはリモートでの対⾯型のいずれかでTrusted Refereeサービスを提供してもよい。その場合、⾝元確認イベントのIALに 応じた⾝元確認⽅式の要件と整合していること。 例外およびエラー処理に関する要件（2/7） Trusted Referee（⾝元確認の例外ケースにおいてリスクベース判断を⾏うCSP、第三者サービ ス、または RP のエージェント）に関するサービスの利⽤可否等の公表と⽅針の⽂書化、及びリ スクベースの決定に関する訓練と認定等が義務付けられる。 155 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
156. Copyright OpenID Foundation Japan - All Rights Reserved. ▪ Trusted Referee の利⽤に関する要件 • どの種類の例外および失敗事象がTrusted Refereeの利⽤対象となるかを⽂書化すること。 • コア属性の不⼀致や、記録ソース内に申請者の情報が存在しない場合など、⾃動化された Validationプロセスの完了失敗に対しても、Trusted Refereeサービスを提供すべき。 • この⽬的でTrusted Refereeを提供する場合、以下の要件が適⽤される。 • コア属性またはその変更を裏付けるために使⽤可能な追加証拠の種類に関するポリシー を定めること。 • Trusted Refereeは、追加証拠について、その証拠の性質が許す最⼤限の範囲で真正性 を確認すること。 • 権威ある記録との間でコア属性に部分的な不⼀致がある場合、Trusted Refereeは、主 張された属性値の正当性を裏付ける証拠（最近の転居や改姓など）を確認すること。 例外およびエラー処理に関する要件（3/7） Trusted Refereeの利⽤対象となる例外等の⽂書化や、⾃動化されたValidationプロセスの失敗に 対してTrusted Refereeサービスを提供する際の、その受⼊⽅針の策定、追加証拠の真正性の確 認、および正当性を裏付ける証拠の確認が義務付けられる。 156 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
157. Copyright OpenID Foundation Japan - All Rights Reserved. ▪ Applicant References に関する要件 • Applicant Reference の利⽤可否および、Applicant Reference と申請者との関係性に関する要件について公 表すること。 • 運⽤⽂書の⼀部として、Applicant Reference の利⽤に関する書⾯のポリシーおよび⼿続きを策定すること。 • Applicant Reference について、申請者に適⽤予定のIALと同等またはそれ以上のIALで⾝元確認を実施するこ と。また、Applicant Reference の⾝元確認のために収集‧記録‧保持する情報を、別途定められたプライバ シーリスク評価に含めること。 • Applicant Reference を利⽤した事実を加⼊者アカウントに記録し、Applicant Reference の情報および申請 者との関係性の記録を保持すること。 • RPは、⾝元確認イベントにおいて Applicant Reference を除外または含めることに伴う適⽤可能性、業務要 件、および潜在的リスクを判断するため、リスク評価を実施すること。 例外およびエラー処理に関する要件（4/7） Applicant Referenceに関する利⽤可否の公表と規定の⽂書化、Applicant Reference⾃⾝への申 請者と同等以上の⾝元確認実施、及びApplicant Referenceの使⽤記録や関係性の保管が義務付け られる。 157 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
158. Copyright OpenID Foundation Japan - All Rights Reserved. ▪ Applicant References の利⽤に関する要件 • Applicant Reference の利⽤を認める場合、CSPおよびそのサービスを利⽤するRPは、Applicant Reference に関する許容されるすべての利 ⽤⽅法を、契約書または信頼された合意⽂書に⽂書化すること。 • Applicant Reference は、以下を⾏ってよい。 • 証拠および属性Validationの⼀環として、申請者が主張する1つまたは複数のコア属性について保証すること。 • ⼗分な⾝元確認証拠が存在しない場合に、申請者の⾝元を保証すること。 • ⾝元確認プロセスに関連する特定の状況または状態（ホームレス状態、災害被災状況など）について保証すること。 ＊これらの情報は、⾝元確認イベントに関連するリスク判断を⽀援することを⽬的としている。Applicant Reference の陳述を、資格や給付の適格 性を確⽴する⽬的で使⽤することは、本ガイドラインの範囲外である。 • すべての場合において、Applicant Reference がプロセス内で果たした役割の記録を作成し、適⽤される法令‧規制要件を満たすのに⼗分な 形でその⾏為を⽂書化すること。 • Applicant Reference として参加することによって⽣じ得る法的および責任上の影響について、明確かつ理解しやすい情報をApplicant Reference に提供すること。 例外およびエラー処理に関する要件（5/7） Applicant Reference の利⽤において利⽤可能なユースケース等を契約等に⽂書化し、その役割と ⾏動を記録する義務がある。また、Applicant Reference に対し、参加に伴う法的責任や影響につ いて明確な情報を提供することも義務付けられる。 158 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
159. Copyright OpenID Foundation Japan - All Rights Reserved. 例外およびエラー処理に関する要件（6/7） ▪ Applicant References との関係性確認に関する要件 多くの場合、申請者とApplicant Referenceとの関係性を確認することには、業務上、法的、または不正防⽌上の理 由が存在する。 • リスク評価の結果、そのような措置が必要と判断された場合、以下の要件が適⽤される。 • CSPおよびPRは、Applicant Reference との関係確認プロセスに関する要件を定め、契約書または信頼 された合意に⽂書化すること。 • 関係確認プロセスを開始する前に、関係性を証明するために受け⼊れ可能な証拠の⼀覧を Applicant Reference に提⽰すること。 • 申請者との関係を証明する証拠（公証済み委任状、専⾨資格証明書など）の提出を求めること。 • 申請者の⾝元確認が成功した場合、Applicant Reference と申請者との関係を確認するために使⽤した 証拠を、加⼊者アカウントに記録すること。 申請者とApplicant Referenceの関係性確認に関して、CSPとRPは要件を⽂書化し、受け⼊れ可能 な証拠リストを事前に提⽰する義務がある。また、関係性を証明する証拠の提出を求め、確認成 功時には使⽤した証拠をアカウントに記録する必要がある。 159 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
160. Copyright OpenID Foundation Japan - All Rights Reserved. ▪ 未成年者との対応に関する要件 18歳未満の者に対して⾝元確認サービスを提供するすべてのCSPには、以下の要件が適 ⽤される。 • 特定のIALにおける証拠要件を満たせない可能性がある未成年者の⾝元確認に関す る書⾯のポリシーおよび⼿続きを、運⽤⽂書の⼀部として策定すること。 • 13歳未満の者とやり取りする場合、COPPA（Children’s Online Privacy Protection Act）または未成年者保護に関するその他の適⽤法令‧規制を遵守すること。 • 18歳未満の者とやり取りする場合、Applicant Reference の利⽤をサポートするこ と。 例外およびエラー処理に関する要件（7/7） 18歳未満の者に対して⾝元確認サービスを提供する場合は、証拠不⾜への対応⽅針の策定、13歳 未満に対するCOPPA等の法令遵守、及び18歳未満に対する Applicant Reference 利⽤のサポート が義務付けられる。 160 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
161. Copyright OpenID Foundation Japan - All Rights Reserved. IALの引き上げに関する要件 CSPは、RPとのより⾼い保証の取引を可能にするため、加⼊者が⾃⾝のアカウントに関連付けられたIAL を引き上げられるようにすべきである。 • これらの機能を提供するCSPには、以下の要件が適⽤される。 ◦ 保証レベル引き上げのために承認された⼿法を、運⽤⽂書に⽂書化すること。 ◦ アップグレード⼿続きを開始する前に、加⼊者に対し、当該アカウントで利⽤可能な最も⾼ い認証保証レベル（AAL）で認証することを求めること。 ◦ より⾼いIALを達成するために必要とされる追加の証拠を収集し、Validationおよび Verificationを実施すること。 • 以前に処理済みの証拠の再収集‧再確認を避けるべきである。ただし、⻑期間のアカウント⾮利 ⽤、不正の兆候、または当初の⾝元確認以降に証拠が無効となった場合には、再実施してもよい。 IALの昇格⼿順を⽂書化し、プロセス開始前にアカウントで利⽤可能な最も⾼いAALで認証を求め ることが義務づけられる。また、上位IALの達成に必要な追加証拠の収集‧検証‧確認も義務付け られる。 161 NIST Special Publication NIST SP 800-63A-4, Digital Identity Guidelines Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63a.html
162. Copyright OpenID Foundation Japan - All Rights Reserved. ユースケース別のIALまとめ 162 4. IAL（Identity Assurance Level）
163. Copyright OpenID Foundation Japan - All Rights Reserved. IAL2 実装事例 - Login.gov ⽶国政府サービスへ1つのアカウントでログインできるSSO基盤を提供。 SSN（社会保障番号）や退役軍⼈カードといった情報を扱っており、国⺠が⾃宅から⾏政サービ スにアクセスすることを⽬的としている。 163 Login.gov が⽀える主な⾏政サービス • USAJOBS 連邦政府機関での仕事を検索し、応募するための中⼼的なプラットフォーム • my Social Security 個⼈の社会保障給付に関するオンラインポータル 社会保障番号（SSN）で年⾦記録の確認などが⾏える • VA.gov 退役軍⼈、現役軍⼈、およびその家族のための統合サービスポータル 軍務に関連する⼿当、医療、教育、住宅ローンなどの恩典を⼀括で管理
164. Copyright OpenID Foundation Japan - All Rights Reserved. IAL2 実装事例 - Login.gov 164 検証プロセスについて • Resolution ◦ ⾝分証明書とセルフィー画像のアップロード ▪ 運転免許証やパスポートブックなどのStrong以上の⾝分証明書のみが許可されている ◦ 社会保障番号（SSN）の⼊⼒ ▪ SSNは⽶国市⺠や永住権保持者などに付与される番号で、⽇本のマイナンバーと類似する個⼈識別番号 である • Validation ◦ ⾝分証明書とSSNの確認 ▪ 画像が改ざんされていないか、権威ある発⾏元と照合するStrong相当のチェック（Validation） • ex） AAMVA（⽶国⾃動⾞管理者協会）, Department of State（国務省）など • Verification ◦ セルフィーと⾝分証明書の画像のStrong相当のチェック ◦ 携帯電話へワンタイムコード送信し本⼈かどうかを確認
165. Copyright OpenID Foundation Japan - All Rights Reserved. IAL3 実装事例 - NextgenID IAL3レベルの⾝元確認技術を提供するプロバイダー キオスク端末でのリモート監視員との対⾯検証を通じて⽶国の連邦職員（PIV）、軍関係者 （CAC）等の⾼セキュリティID発⾏を⽀援している。指紋をつかった⽣体認証機能がIAL3の要件と 適合する。 165 NextgenID が⽀える主なサービス • USPS（⽶国郵便公社）へのキオスク端末導⼊ 郵便局へのIDステーション設置し、郵便局からIAL3登録を実現している • VA（退役軍⼈省）への導⼊ ⽣体認証プラットフォームの導⼊ • DoD（国防総省）への導⼊ 現役および退役軍⼈、連邦政府職員、政府請負業者、DOD の家族に共通アク セス カードや⽶国 ID カードを発⾏している Gen3 キオスク ID ステーション
166. Copyright OpenID Foundation Japan - All Rights Reserved. 信頼を⽀える仕組み - Kantara Initiative IAL2, IAL3といった「信頼」を誰が保証しているのか？ NISTは基準を策定するのに対し、⺠間のKantara Initiativeはサービス提供者を監査し、認定を付与 している。 166 IAL, AALを認定の仕組み ⽶国では⺠間の認定エコシステムが ありNISTへの準拠を保証する仕組み がある。 ※本資料作成時点（2026年3⽉9⽇） では、Rev4への対応は確認できてい ません。 認定サービス一覧
167. Copyright OpenID Foundation Japan - All Rights Reserved.