G7メンバー国のデジタルアイデンティティガイドラインのマッピングが発表されています

こんにちは、富士榮です。

G7メンバー国でやっているIdentityガイドラインのマッピングエクセサイズのレポートが出ています。

https://www.oecd.org/en/publications/g7-mapping-exercise-of-digital-identity-approaches_56fd4e94-en.html

This report presents a mapping exercise to identify commonalities in digital identity approaches among G7 members that can support future interoperability efforts. These commonalities include shared concepts and definitions, the use of international technical standards and approaches to levels of assurance. The report was prepared at the request of the 2024 Italian G7 Presidency and G7 members, to inform discussions within the G7 Digital and Technology Working Group. It was launched during the G7 Digital and Technology Ministerial Meeting in Como, Italy, on 15 October 2024.

本報告書は、将来の相互運用性の取り組みを支援することができる、G7 メンバー間のデジタル ID アプローチの共通点を特定するためのマッピング作業を提示する。これらの共通点には、共有される概念および定義、国際技術標準の使用、保証レベルへのアプロ ーチなどが含まれる。この報告書は、2024 年イタリア G7 議長国および G7 メンバーの要請により、G7 デジタル・ テクノロジー作業部会での議論に情報を提供するために作成された。2024年10月15日にイタリアのコモで開催されたG7デジタル・テクノロジー閣僚会合で発表された。 

中身は順次見ていきたいと思いますが、カナダ、欧州、日本、英国、米国のそれぞれのガイドライン（例えば日本ならDS-500、米国ならNIST SP800-63-3）の比較・マッピングをしています。

これはSIDI Hubのワークストリームとも協調していくべき動きで、今後国境を跨いだコミュニケーションの中でデジタルアイデンティティがシームレスに利用できる世の中の実現に向けて非常に重要なステップですね。

NIST SP800-63-4のSecond Public Draftが出てきました

こんにちは、富士榮です。

すでにあちこちで書き込まれているので今更私が書くこともありませんが、みんな大好きNISTのデジタルアイデンティティガイドラインであるNIST SP800-63-4 SPD（Second Public Draft）がようやく出てきました。（本当はもっと前に出るって噂でしたが）

とりあえずパブリックコメント募集は10月7日までこちらで。

https://www.nist.gov/news-events/news/2024/08/nist-releases-second-public-draft-digital-identity-guidelines-final-review

そして、早速崎村さんが概略を日本語で書いていらっしゃいます。

https://www.sakimura.org/2024/08/6224/

オフィシャルには8月29日の午前1時から公開Webinarがあります。

https://nist.zoomgov.com/meeting/register/vJItcu6oqj0jH4xWLbz350jf6VeKM9bMjWc#/registration

さて、コメントに向けて準備しましょうかね。

Verifiable Credentials改めReusable Identity？何をどこまで検証すべきなのか

こんにちは、富士榮です。

先日のIdentiverseやEuropean Identity & Cloud Conferenceで目についたのが「Reusable Identity」というキーワード。

どうも話の流れを聞いていると、一般名詞としてのVerifiable Credentials（mDocやSD-JWT-VCやW3C VCDM、anonCredまで含む）の中でIdentity Verificationに使うものをReusable IdentityとかDecentralized Reusable Identityと呼ぶことに（誰かが）したらしいです。

openart.aiに描かせてみたら、なんだか資源ごみみたいになってしまった。

ちょっと検索してみると、identity.comの人のこんな記事が見つかりました。

What Is a Reusable Identity?

Reusable identity is a single set of identity credentials that allows individuals to access multiple platforms without repetitive verification. Unlike traditional centralized systems, which demand separate identity verifications for each service or platform, a reusable identity streamlines the user experience. This approach reduces the burden of multiple verifications and addresses inefficiencies and security risks linked to the repeated sharing of personal information.

再利用可能な ID とは？

再利用可能な ID とは、個人に複数のプラットフォームへのアクセスを許可する、1 セットの ID 認証情報です。従来の中央集権型システムとは異なり、各サービスやプラットフォームごとに個別の ID 認証を要求するシステムとは異なり、再利用可能な ID はユーザーエクスペリエンスを合理化します。このアプローチは、複数の認証の負担を軽減し、個人情報の繰り返し共有に伴う非効率性とセキュリティリスクに対処します。（Deeplによる機械翻訳） 

https://www.identity.com/what-is-reusable-identity/

この話とWalletのセキュリティの話がかなり密接に結びついて分類が始まってきているように思えているので、今日はその辺りの話を整理し始めようかと思います。

WalletとHolderの違い

そもそもWalletとHolderが同じものとして扱われてしまうことが多いのですが、EICのパネルでも少し話題に登った通り、IssuerはクレデンシャルをWalletに対して発行するのではなく、Holderに対して発行するんですよね。

W3C VCDM1.1のいつもの図を見てもそのように記載されています。

どうもこのHolder=Walletというイメージが先行し過ぎてしまっていることが混乱を招く一因になってしまっていると思います。

WalletとHolderとクレデンシャルのバインディング

ここでは3つの話があります。

1. Holder-クレデンシャルのバインディング
2. Wallet-クレデンシャルのバインディング
3. Holder-Walletのバインディング

まずHolder-クレデンシャスのバインディングです。

発行されたクレデンシャルがHolderとちゃんと紐づいているか（バインディング。要するにちゃんと対象者に対して発行されているか）はVerifierの視点からすると大切な点です。

例えば、特定の資格情報をVerifierが受け取った時に、提示してきた人（Holder）が他人のクレデンシャルを渡してきていたら問題になるケースも多いはずです。（もちろん全てのケースではない。これはVerifierのシナリオに依存する。このVerifier側の都合である、という点は非常に重要）

Verifiable Credentialsの場合、通常はVerifiable Presentationの発行者となるHolderのデジタル署名と、発行者の識別子とVerifiable Credential内のCredential Subjectの識別子が一致していることを持ってHolderとクレデンシャル発行対象が同一のエンティティであることを確認するわけです。

次に、Wallet-クレデンシャルのバインディングです。

前述のHolder-クレデンシャルのバインディングの前提はWalletが悪さをしない、ということになるので、特に国が発行する身分証明書などについては特定の基準を満たした（例えば鍵の管理がしっかりしているなど）Wallet出ないと困るわけです。こうなるとWalletとクレデンシャルの紐付け（バインディング）も検証する必要が出てきます。

このためにはWalletプロバイダが発行するWallet自体を証明するクレデンシャルと、Issuerから発行されるクレデンシャルを紐付けてデジタル署名を施す、という方法が取られたり、Secure Element等にプロビジョニングされた「管理された」鍵を使ってHolder署名をすることによりWallet自体が管理されたものであることを検証可能にする、という方法が取られたりします。

最後に、Holder-Walletのバインディングです。

要するに、他人がWalletを勝手に使っていないか？という話です。一般にWalletを起動する時にFace IDなどのOSの生体認証機能を使ってアンロックする方法が取られます。

Verifierは何をどこまで、どうやって検証するべきなのか

先に挙げたバインディングを含め全て検証をすれば確かに固い仕組みが出来上がると思います。ただし、Verifierは全ての資格情報の種別に対してそれらの検証をしたいわけではないことに注意しないといけないと思います。

例えば、単にお店の会員カードのような資格情報だった場合に持参人（Holder）とCredential Subjectが異なっても大きな問題にならないでしょうし、ビジネス機会を考えるとある程度のクレデンシャル共有は許容すべきとの意見もあると思います。

また、全てのWalletがSecure Elementに鍵を持ち、確実にIssuer等によって管理された状態となるのは非常に難しいですしToo Muchと言えます。（現実的にSecure Elementが使える端末は限定されますし、そのためにSIMを使うのか、またはマイナンバーカードやNational IDカードのICチップやクラウドHSMなどを使うのか？など非常に無理がある話です）

こうなると、Verifierの視点で何をどこまで検証すべきなのか？についてはシナリオと資格情報の種別によって変わってきそうです。

• シナリオは、対面なのかリモートなのか
• 資格情報の種別は、身元確認（Identity Verification）に使うものなのか単なる資格確認なのか

こんな視点で分類ができると思います。

また、「検証」という言葉についても何を？という話があります。NIST SP800-63A-3的に言うと、

• Validation：エビデンスの真正性の確認
• Verification：持参人がエビデンスが指し示すエンティティと同一であることの確認

だと思います。（NIST SP800-63の中でもValidationとVerificationの使い分けは混乱が見られるので全体にこの定義が当てはまるわけではありませんが）

これらの視点で考えると、Verifierは対面（デジタル）でもリモートでも

• 受け取ったクレデンシャルのValidationは行いたい
• 持参人の検証はシナリオによる

ということが言えると思います。

また、対面かリモートかによって、Verificationの方法は若干変わります。

• 対面ならValidateされたクレデンシャル内の顔写真などと持参人を比較（Verify）する
• リモートならValidateされたクレデンシャルが指し示すエンティティと同一であることを別途本人確認（例えばeKYCを含む）した結果と比較する

おそらく、Reusable Identityの文脈においてはこのリモートにおけるVerificationも一つのクレデンシャルの中で閉じて実施する必要があるので、先に挙げた3つのバインディングにかなり気を使うことになります。（要するにパスキーのように一回の動作で多要素認証と同等のことを行う）

しかしながら、単なる資格確認であればVerificationについては他のオプション（eKYCなど）と組み合わせることで実現が可能な話なので、Walletの作り方を含めそこまで気にし過ぎなくても良いのではないか、と思います。（現に、OpenBadgeなどではバッジと持参人の紐付けの確認は検証側の仕事として整理されています）

ちょっとダラダラと書きましたが、Walletのエコシステムを拡充させるためにはApple Walletがマイナンバーカードを格納できるようになった！万歳！で思考停止せずにちゃんと考える必要がありそうです。

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（７）

こんにちは、富士榮です。

NIST SP 800-63B-3の追補版も最後のまとめ部分を残すのみです。

早速ですが本文書でどのように結論づけているのかをみていきましょう

同期可能な認証器は、認証の状況、特に多要素暗号認証子の使用における実質的な技術的変化を示すものである。暗号鍵の複製とクラウド・インフラへの保存を許可することに関連するトレードオフの 評価は、必然的に行われることになる。このことは、明確なリスク（認証鍵に対する企業管理の喪失など）をもたらすが、同時に、 一般市民や企業にとっての主要な脅威ベクトルを排除する、便利でフィッシングに強い認証機能への道筋を提供する。同期可能な認証器は、すべてのユースケースに適しているわけではない。しかし、本補足文書に含まれるガイドラインに沿った方法で導入される場合、AAL2 リスク軽減策との整合性を達成し、フィッシング耐性認証の採用をより広範に促進することができる。

企業等で利用する場合は鍵が制御外のファブリック（iCloudなど）に保存されることによるリスクがありますが、一般ユーザのシナリオではフィッシング耐性のない認証器を使うよりはマシっていうことなんでしょうねぇ。要はユースケースに応じたリスク分析をちゃんとやろうねっていうNISTのガイドラインの根本は変わらないわけで。

この文書は、既存のデジタル・アイデンティティ・ガイドラインに付随するものであり、各省庁 が十分な情報に基づきリスクベースの決定を行い、適切な場合には最新の業界イノベーション を統合するための情報を提供する。

改めて本文書は既存のガイドラインの付随文書であることを強調し、先に書いたとおりちゃんとしたリスク分析に則って対策を考えましょう、ということです。

ということでこれで一通り見てきたわけですが、私的なまとめとしては、

• 同期と共有は違うぞ
• 同期を許容する場合はバックエンドの同期ファブリックの信頼性も評価しないとだめ
• 統制レベルを上げる場合は同期を不許可にするようにMDMなどで制御することも必要
• ただ、かといってフィッシング耐性がない認証器を許容するよりはマシな場合もある
• 結局ユースケースごとにリスク評価をしましょうね
• その意味でこのガイドライン追補版では新たなタイプの認証器の特徴とリスクなどをまとめたのでちゃんと導入するように

ということくらいでしょうか。

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（６）

こんにちは、富士榮です。

少し間が開きましたがNIST SP 800-63B-3の追補版の続きです。

今回は同期と共有は違うぞ！という話のうちの共有の部分です。１回目にも書きましたがAppleの共有パスワードグループの話などもありますので、非常に重要な部分だと思います。

サイバーセキュリティ・ガイドラインは、歴史的に、ユーザ間で認証器を共有しないよう警告してきた。このガイダンスにもかかわらず、一部のユーザ・グループやアプリケーションでは、個人がデジタル・アカウントへのアクセスを共有できるようにするために、認証器とパスワードの共有が行われている。

表 3 に示すように、一部の同期可能な認証器の実装は、このようなユーザの行動を受け入れ、 異なるユーザ間で認証キーを共有する方法を確立している。さらに、一部の実装は、一般的なサービスにおいて、パスワード共有に代わる便利で より安全な方法として、同期可能な認証器の共有を積極的に推奨している。 

言われてますよ、Appleさん。。

企業ユースケースの場合、鍵の共有に関する懸念は、鍵が承認されたデバイスや同期 ファブリックから移動されることを制限するデバイス管理技術を使用することで、効果的に緩和することができる。しかし、公衆向けのユースケースでは、同様の緩和策は現在のところ利用できないため、 リライングパーティは、同期可能な認証プロバイダが採用する共有モデルに依存することになる。公衆向けアプリケーションの所有者は、共有認証器に関連するリスクを認識する必要がある。公衆と対話する場合、機関は、ユーザがどの特定の認証器を使用しているのかについて限られ た可視性しか持たないため、すべての同期可能な認証器が共有の対象となる可能性があることを想定する必要がある。多くの共有モデルには、リスクを最小化する実質的な制御（例えば、共有を許可するためにデバイス間の近接を要求する）があるが、他の実装はそれほど制限的ではない。

やっぱり共有を制御する方法とセットになっていることが必要なんじゃないかと思いますね。この辺りの判断をリライングパーティに全部任せちゃうのは実質不可能だと思いますし。

この新しいクラスの認証者がもたらす共有のリスクは、特別なものではない。実際には、すべての AAL2 認証タイプに適用され、中には同期可能な認証タイプより弱いものもある。AAL2 のどの認証子も、それを共有しようとするユーザによって共有される可能性がある。ユーザは、パスワード、OTP、帯域外認証子、さらにはプッシュ認証イベントを積極的に共有したり、被指名人（正式か否かを問わない）がエンドユーザに代わって認証を行うことを許可したりすることができる。

各省庁は、直面する特定のリスク、脅威、およびユーザビリティの考慮事項に基づいて、アプリ ケーションにどの認証手段を受け入れるかを決定する。同期可能な認証方式は、AAL2 までの実装を求めるアプリケーションの新しいオプションとして提供されるかもしれず、他の認証方式と同様に、この技術のトレードオフは、セキュリティ、プライバシー、公平性、およびユーザビリティに対する期待される結果に基づいて、うまくバランスをとるべきである。

そろそろこのレポートもおしまいです。

というか早くSP800-63-4の次のドラフトが出て欲しいですね。

 

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（５）

こんにちは、富士榮です。

引き続きNIST SP 800-63B-3への追補版を見ていきましょう。

今回は同期可能な認証器に関する脅威とチャレンジについてです。

Syncable Authenticator Threats and Challenges

同期可能な認証機能には、導入または展開の前に評価すべきいくつかの明確な脅威および課題がある。表3にこれらのリスクと推奨される軽減策の概要を示す。

表3. 同期可能な認証器の脅威、課題、緩和策

脅威と課題	説明	緩和策
鍵の不正使用または管理の喪失	同期可能な認証器の中には、鍵を悪用する可能性のある他のユーザが所有するデバ イスへの秘密鍵の共有をサポートするものもある。	- 同期されたキーの共有を防止するエンタープライズ・デバイス管理機能または管理されたプロファイルを強制する。 - 利用可能なすべての通知チャネルを通じて、鍵共有イベントをユーザーに通知する。 - ユーザが鍵、鍵の状態、鍵が共有されたかどうかを確認できる仕組みを提供する。 - 既存の認識およびトレーニングの仕組みを通じて、鍵の不正使用のリスクについてユー ザーを教育する。
同期ファブリックへの侵害	鍵の同期をサポートするために、ほとんどの実装は、アカウントに関連付けられた複数のデバイスに接続されたクラウドベースのサービスである「同期ファブリック」に鍵をクローンする。	- 暗号化された鍵マテリアルのみを保存する。 - 認証されたユーザ以外が秘密鍵にアクセスできないように、同期ファブリックのアクセス制御を実装する。 - クラウドサービスの基本的なセキュリティ機能（FISMA Moderate 保護または同等の保護など）を評価する。 - ハードウェア・セキュリティ・モジュールを活用し、暗号化鍵を保護する。
同期ファブリックへの不正アクセスと復旧	同期された鍵は、クラウドベースのアカウント回復プロセスを通じてアクセスできる。これらのプロセスは、認証者にとって潜在的な弱点となる。	- SP 800-63B に準拠した認証回復プロセスを導入する。 - デバイス管理またはマネージド・アカウント機能により、連邦エンタープライズ鍵の回復機能を 制限する。 - 復旧をサポートするために、AAL2 以上の複数の認証機関をバインドする。 - 同期ファブリックへのユーザ・アクセスに新しい認証者を追加する場合は、AAL2 認証を要求する。 - 連邦政府の企業シナリオでは、派生認証としてのみ使用する。 - ユーザにリカバリ活動を通知する。 - ユーザが管理する秘密鍵（シンク・ファブリック・プロバイダが知らないもの）を利用し、鍵の暗号化と回復を行う。
取消	同期可能な認証器はRP固有のキーを使用するため、そのキーに基づくアクセ スを一元的に取り消すことは困難である。たとえば、従来の PKI では、CRL を使用してアクセスを一元的に取り消すことができる。同様のプロセスは、同期可能な認証器（または FIDO WebAuthn ベースの認証器）では利用できない。	- ユーザが認証情報を管理するための中央 ID 管理（IDM）アカウントを導入し、認証情報が漏 洩したり失効したりした場合は、「所属機関」アカウントから認証情報を削除する。 - SSO およびフェデレーションを活用し、インシデント発生時に失効させる必要のある RP 固 有の鍵の数を制限する。 - ユーザが鍵の有効性と最新性を確認するよう定期的に要求するポリシーとツールを確立する。

ここにありましたね。同期と共有の違い。やっぱりMDMとかでコントロールするしかなさそうですね。

ちなみに次の章は共有に関して丸々一章を割いているのでやはり課題感は大きいんだと思います。

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（４）

こんにちは、富士榮です。

引き続きNIST SP800-63B-3の同期可能な認証器に関する追補版についてみていきましょう。

今回は実際にインプリメンテーションを行う場合の考慮事項や要求事項についてです。

Implementation Considerations and Requirements

同期可能な認証器は、W3CのWebAuthn仕様に基づいて構築されており、共通のデータ構造、チャレンジ・レスポンス暗号プロトコル、公開鍵認証情報を活用するためのAPIを提供している。この仕様は柔軟で適応性があるため、WebAuthnクレデンシャルのすべてのデプロイが連邦政府機関の実装要件を満たすとは限らない。

この仕様には一連の「フラグ」があり、依拠当事者（RP）アプリケーションは、認証イベ ントの追加コンテキストを提供し、それが RPのアクセス・ポリシーに適合するかどうかを判断す るために、認証者に要求することができる。本節では、RPとして活動する連邦機関が、NIST AAL2 脅威緩和策に適合する同期可能な認証器の実装を構築する際に理解し、問い合わせる必要がある、WebAuthn仕様の特定のフラグについて 説明する。

表2, WebAuthn Level 3 flags

フラグ	説明	要求事項と推奨事項
User Present（UP）	ユーザが認証器と対話したことを確認するための「プレゼンス」テストを示す（例：USBポートに挿入されたハードウェアトークンのタッピング）。	連邦機関は、ユーザ提示フラグが設定されていることを確認しなければならない（SHALL）。認証意図をサポートする。
User Verified（UV）	利用可能な「ユーザー検証」メソッドのいずれかを使用して、ユーザーが認証者によってローカル認証されたことを示す。	連邦機関は、UV が優先されることを示さなければならず（SHALL）、すべてのアサーションは、UV フラグの値を確認するために検査されなければならない（SHALL）。これは、認証器が多要素暗号認証器として扱えるかどうかを示す。ユーザが検証されない場合、機関は、認証イベントに RP 固有の暗記秘密を追加することで、認証器を1要素暗号認証器として扱うことができる。WebAuthn レベル 3 仕様のさらなる拡張により、機関がローカル認証イベントのコンテキストを得ようとする場合、検証方法に関する追加データが提供される。
Backup Eligibility	認証器を別のデバイスに同期できるかどうか（すなわち、鍵を別の場所に保存できるかどうか）を示す。同期可能だからといって、同期済みであることを意味しないことに注意。	連邦機関は、同期可能な認証器の使用を制限するポリシーを確立する場合、このフラグを使用してもよい。このフラグは、デバイスにバインドされる認証子と、複数のデバイスにクローンされる 認証子を区別するために必要である。
Backup State	認証器が別のデバイスに同期されたかどうかを示す。	連邦機関は、他のデバイスに同期された認証器に対する制限を確立する場合、このフラグを使用してもよい。公開アプリケーションの場合、連邦政府機関は、ユーザエクスペリエンス上の懸念から、このフラグに基づいて受諾を変更すべきではない(SHOULD NOT)。企業の判断のために、このフラグは、特定のアプリケーションのために同期可能な 認証器の制限をサポートするために使用してもよい[MAY]。

以前パスキー対応の認証機能を実装した際にも出てきたフラグですね。

https://idmlab.eidentity.jp/2024/02/api.html

同期可能かどうかの判断にはBEやBSを使うわけです。アプリによってはこのフラグを見て同期可能な認証器を受け入れるかどうかを決める、と言うことです。

 

表2に示されるフラグに加えて、機関は、実装および受け入れを選択する同期可能な認証器のオリジンおよび機能について、より詳細な情報を得ることを望むかもしれない。FIDO2 WebAuthn のコンテキストにおいて、認証者の中には、特定の認証者の能力および製造者を 判断するために使用できる認証機能をサポートしているものがある。企業ユースケースの場合、各機関は、プラットフォームプロバイダが提供する機能に基づいて、認証機能を実装するべきである(SHOULD)。好ましくは、RP が認証器に関する一意の識別情報を要求するエンタープライズ認証の形をとる。

構成証明（Attestation)は、広範な公衆向けアプリケーションに使用すべきではない（SHOULD NOT）。このような要件（すなわち、構成証明に対応していない場合、一部の一般ユーザの同期可能な認証器をブロックする要件）は、ユーザをショートメッセージサービス（SMS）のワンタイムパスワード（OTP）のような、フィッシングに脆弱な安全性の低い認証オプションに誘導する可能性がある。

この視点は面白いですね。パブリック（共有端末とかのイメージかな？）なアプリケーションで同期可能な認証器を使うとってしまうまずいので同期可能なクレデンシャルをブロックすると言うポリシーを適用すると、手軽な認証手段を実装しがちになる、という話でしょうか？（@Shiroicaさんご指摘ありがとうございます）

RP がフラグおよび認証データを要求しても、認証器は要求された情報をすべて返さないかもしれないし、リソースへのアクセスに要求される期待応答と矛盾する情報を返すかもしれない。したがって、各機関は、同期可能な認証器を使用するユースケースを評価し、返された情報に基づいて適切なアクセスポリシー決定を行うことが決定的に重要である。

こちらも現実論として全ての認証器がちゃんとフラグを返してくるということは期待してはいけない、ちゃんとリスクを含め評価をしてポリシーを決めようね、ということです。これ非常に大事だと思います。

ということでまだ続きますが、今回はここまでです。

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（３）

こんにちは、富士榮です。

前回に引き続きNIST SP800-63-3の追補版を見ていきます。

だいぶ中身に入ってきました。
早速読んでいきます。

Updates on the Allowance of Cloning Authentication Keys

SP 800-63B のセクション 5.1.8.1「多要素暗号化ソフトウェア認証機能」は、認証器があるデバイスから別のデバイスへ暗号化認証鍵を「クローン」することを制限している。具体的には、以下のとおりである：

多要素暗号化ソフトウェア認証器は、複数のデバイスへの秘密鍵のクローニングを抑制すべきであり、促進してはならない（SHALL NOT）。

同期可能な認証器は、デバイスや異なるプラットフォーム・プロバイダにまたがって、以前に 登録した認証器へのアクセスをユーザに提供するため、明示的に鍵の複製を促進する。NISTがSP 800-63B-4の初期公開草案(ipd)からこの制限を削除したことで、この現実が認識された。本文書の発行時点で、5.1.8.1 項の上記の記述は、本補足により置き換えられ、本補足に規定される要件に基 づいて導入される同期可能な認証器は、AAL2 で想定される脅威から保護するのに十分であるとみなされるものとする。

そうです、元々のSP 800-63Bでは秘密鍵のクローニングを制限していたわけです。今回の更新でこの点について緩和が行われたわけです。

ただ、そのために満たすべき要件を以下の通り定義しています。

同期可能な認証器のすべての使用に関する一般要件：

• すべての鍵は、承認された暗号技術を用いて生成されなければならない。
• デバイスからクローンまたはエクスポートされた秘密鍵は、暗号化された形式でのみ保存されるものとする。
• すべての認証トランザクションは、デバイス上で生成された、または同期ファブリック（クラウドストレージ など）から復元された暗号鍵を使用して、ローカル・デバイス上で秘密鍵操作を実行しなければならな い。
• クラウドベースのアカウントに保存された秘密鍵は、認証されたユーザのみがシンクファブリック内の秘密鍵にアクセスできるよう、アクセス制御メカニズムによって保護されなければならない。
• 同期ファブリック内の秘密鍵へのユーザ・アクセスは、同期された鍵を使用する認証プロトコルの完全性を保持するために、AAL2相当のMFAによって保護されなければならない。
• これらの一般的要件および同期可能な認証器の使用に関するその他の機関固有の要件は、文書化し、公開ウェブサイトおよびデジタル・サービス・ポリシー（該当する場合）を含め、周知されるも のとする。

ちゃんと認定された暗号技術を使うこと、同期された鍵を使って認証に必要な操作を行う場合はローカルで操作を行うこと（要するにリモート署名なんかはNGってことですね）、秘密鍵へのアクセス制御を行うこと、具体的にはAAL2相当の認証強度で保護されていること、同期可能な認証器を使っていることをポリシーとして公開・周知すること、が記載されています。要は、同期してもいいけどちゃんと認められた方法で管理し、その旨を周知せよ、ということですね。

また、追加要件として以下のについても定義されています。 

連邦企業が同期可能な認証器を使用するための追加要件： 

• 連邦企業の秘密鍵（すなわち、連邦鍵）は、FISMA Moderateの保護または同等の保護を達成した同期ファブリックに保管しなければならない。
• 連邦企業の秘密鍵を含む認証器を生成、保管、同期するデバイス（携帯電話、ノート型パソコン、タブレットなど）は、モバイル・デバイス管理ソフトウェアまたはその他のデバイス・コンフィギュレーショ ン・コントロールによって保護され、権限のないデバイスまたは同期ファブリックへの鍵の同期または共有を防止しなければならない。
• 同期ファブリックへのアクセスは、省庁が管理するアカウント（例えば、中央アイデンティティ・アクセス管理ソリューションまたはプラットフォーム・ベースの管理アカウント）によって制御され、 秘密鍵のライフ・サイクルに対する企業管理を維持するものとする。
• 秘密鍵を生成する認証器は、認証器の能力およびソースを検証するために使用できる認証機能（例えば、エンタープライズ認証）をサポートすべきである（SHOULD）。

これらの管理は、特に同期をサポートし、FIPS 140 の検証を含む、既存の多要素ソフトウ ェア暗号認証の要件および AAL2 の要件に追加するものとみなされるものとする。

秘密鍵の同期に使うファブリック（要するにクラウドストレージやiCloudやGoogle Platformなど）の保護レベルはFISMA（米国連邦政府のセキュリティ基準）のModerate（平均レベル）もしくは同等が求められています。

また、同期ファブリックへのアクセス制御についてはIAMなどによりしっかり管理されている必要がある、ということなので共有パスワードグループはこの辺りに引っかかるんじゃないかな、、と思います。多分、企業などでiOSやmacOSを使う場合はMDMなどで共有パスワードグループを制御する（できるかどうかは知りませんが）ことが必要になりそうです。

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（２）

こんにちは、富士榮です。

引き続きNIST SP800-63-3の追補版を見ていきます。

前回はイントロ、文書の目的について読みましたが今回はAAL2の要件と同期可能な認証器の関係性について見ていきます。

では早速。

Syncable Authenticators Achieve AAL2

NIST の認証機関保証レベルは、主に、認証プロセスに対する特定の脅威から保護する認証機 関の能力を中心に構成されている。AAL2 では、ユーザが 2 つの 1 要素認証子、またはユーザ・アカウントにバインドされた多要素 認証子を所持しているという高い信頼性を提供することが意図されている。表 1 は、SP800-63-3 から要求される脅威の緩和と、適切に構成された同期可能な認証子がこれらの 脅威からどのように保護されるかを示している。

SP 800-63-3 による必要な脅威の緩和（表 4-1） 

要求事項	AAL2	同期可能な認証器（パスキーなど）
Man in the Middleに対する耐性	必須	達成 適切に構成された同期可能な認証器は、認証され保護されたチャネルによって、すべての認証デー タを交換する。
Verifierに関するなりすまし耐性	必須ではない	達成 適切に設定された同期可能な認証器は、一意の公開鍵または秘密鍵のペアを作成し、そのペアの使用は、作成されたドメインに限定される(つまり、鍵は特定のウェブサイトまたはRelying Partyでのみ使用できる）。これにより、改ざんされたウェブ・ページが認証子の出力をキャプチャして再利用することを防ぐことができる。
Verifierに関する侵害耐性	必須ではない	達成 適切に設定された同期可能な認証器は、検証者側にのみ公開鍵を保存する。これらの鍵は、ユーザ認証には使用できない。同期ファブリックによって保存される秘密鍵は、承認された暗号化技術を使用して暗号化された形でのみ保存される。アクセス制御により、認証されたユーザー以外が保存された鍵にアクセスすることはできない。
リプレイ耐性	必須	達成 同期可能な認証器は、各認証トランザクションに組み込まれたランダムなノンスを使用する ことで、リプレイ耐性（すなわち、将来のトランザクションでの再利用防止）を防ぐ。
認証の意図	推奨	達成 同期可能な認証器は、暗号化認証プロトコルを開始するために、ユーザがアクティ ベーション・シークレットを入力することを要求する。これは、ユーザの積極的な参加なしにはイベントが進行しないため、認証の意図として機能する。

セクション5では、同期可能な認証器の設定に関する追加的な考慮事項について論じる。

AAL2 要件を満たすために、同期可能な認証器は、ローカルに保存された鍵をアンロックするた めにローカル認証イベントを利用しなければならない[SHALL]。あるいは、ローカル認証の仕組みが 利用できない場合は、別の認証手段(たとえば、ユーザが選択したパスワード)と併用しなければ ならない[SHALL]。FIDO2 Web認証(WebAuthn)コンテキストでは、W3C Web認証仕様の認証子データで利用可能な User Verificationフラグの値によって示される。FIDO2 WebAuthn 認証データフラグの詳細については、セクション5を参照のこと。

ポイントは最後の一文で、やはり同期クレデンシャル「だけ」ではダメで、ちゃんとローカル認証イベント（たとえば端末アンロックの利用など）を使う必要がある、ということに触れたところでしょうか。

次回も引き続き読んでいきたいと思います。

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（１）

こんにちは、富士榮です。

先日紹介した通り、NIST SP800-63-3の追補版という形で同期可能なクレデンシャルの取り扱いに関する文書がリリースされました。

今回から中身を少し見ていこうと思います。

しかし、ちょうど最近iOSやmacOSの共有パスワードグループでAirDrop環境外でもパスワードに加えてパスキーまで共有ができるようになった、というアナウンスが界隈では話題に上りました。なんだか単純な同期の話だけでは済まなくなってきてしまった気もしますが、この機能がこのガイドラインにどのような影響を与えるのかは継続ウォッチということで、まずはガイドライン（追補版）を見ていきましょう。

参考）共有パスワードグループ

　　https://support.apple.com/ja-jp/guide/iphone/iphe6b2b7043/ios

とりあえずイントロです。例によってDeeplで機械翻訳です。

Introduction

NIST デジタル ID ガイドラインは、ID 証明、認証、およびフェデレーションを 含む、デジタル ID のプロセスと技術要件を規定している。NIST 特別刊行物（SP）800-63B（SP 800-63-3 に関連する第 B 巻）は、認証およびライフサイクル管理 の要件を特に取り上げている。改訂 3 は、このガイドラインの最新の大幅な改訂であり、2017 年 6 月に発行された。シリーズ全体の更新が進行中であり、改訂 4 で完結する予定であるが、技術のペースは NIST の典型的な文書開発およびレビューのプロセスよりも速いため、この補足的な更新が正当化される。

SP 800-63B で扱われるこのような認証タイプは、多要素暗号認証である。通常、この認証タイプは、ハードウェアまたはソフトウェアで暗号鍵を保護し、第 2 の認証要素（記憶された秘密またはバイオメトリック特性のいずれか）による起動を必要とする。秘密鍵を不正な暴露から保護することは、多要素暗号認証機のセキュリティ・モデルの基本である。これには従来、秘密鍵がエクスポートまたはクローン可能でないことを保証することが含まれる。しかし、このパラダイムは変わり始めている。特に、新しい一連の認証プロトコルと仕様により、同期可能な認証子（一般に「パスキー」と呼ばれる）が急速に採用されるようになり、ユーザが異なるデバイス間で秘密鍵を同期（つまり、 複製）できるようになった。

SP 800-63-3 が 2017 年に発行されたとき、2 つの重要なサポート仕様である Fast Identity Online (FIDO) Client to Authenticator Protocol (CTAP) と W3C の Web Authentication（一緒に使用される場合は FIDO2 として知られる）は存在せず、実装の強固でよく理解されたエコシステムもなかった。当時利用可能であった暗号認証の種類に基づき、2017年のガイドラインは、多要素暗号認証が他のデバイスに鍵を「クローン」する能力を制限した。しかし、この2年間でエコシステムは急速に加速し、現在ではほとんどの主要なプラットフォーム・プロバイダが、スケーラブルで同期可能な認証機能を実装している。これらの認証機能は、耐フィッシング性のサポート、特定の依拠当事者にバインドする機能、パスワー ドを送信する必要性の排除、認証機能のリカバリの簡素化、保存された秘密鍵に付随する第 2 要素とし ての多様なデバイス固有の生体認証および PIN の使用など、多くの利点を提供する。また、ますますマルチデバイス、マルチプラットフォーム化する世界に適合する利便性も提供する。どのような新しい技術もそうであるように、技術革新の約束には、探求し理解しなければならない新たな脅威と課題が伴う。そのため、この補遺では、連邦機関が同期可能な認証機能を実装するかどうか、またどのように実装す るかを決定する際に、現代の脅威を含めて考慮すべき事項の概要を示す。

まぁ、先日のポストにも書いた通り、時代が変わったのでver.4を待たずに追補版で同期可能なパスキーに関してちゃんと分析して考慮をしよう、という話です。

次に文書の目的です。

Purpose

この文書の目的は、変化する認証およびクレデンシャルの市場を反映するために、現行の NIST ガイドラインを適合させることである。この補足では、SP 800-63-3 で確立された認証保証レベルと一致する方法で、同期可能な認証機能がどのように脅威を軽減するかを説明し、SP 800-63-3 認証保証レベル 2（AAL2）を達成するために活用できる同期可能な認証機能の理解を連邦機関に提供する。また、SP 800-63B の第 5.1.8 節で説明されているソフトウェア暗号化認証子の使用に関する最新情報、 特に、鍵が別のデバイスに複製（例えば、「クローン」または「同期」）された場合でも、当該認証子が AAL2 認証要件をサポートする能力についても提供する。最後に、本文書は、公衆向けアプリケーション（すなわち、OMB Memorandum M-19-17 に記 載されているように、公衆 ID と相互作用する連邦情報システム）と連邦エンタープライズ・ アプリケーション（すなわち、OMB Memorandum M19-17 に記載されているように、主に連邦エ ンタープライズ ID と相互作用する連邦情報システム）という 2 つのユースケースに基づ いて、実装に関するいくつかの考慮事項を示す。この文書は、SP 800-63-3 にある既存のガイダンスを補足するものであり、SP 800-63B-4 の最終版に取って代わられる。

記載の通りですが、同期可能であってもAAL2を達成できることを説明するための資料になっているってことですね。また、当然ですが最終的にはver.4へ統合されていく文書というわけです。

ということで、ちょっと長めのシリーズになりそうですが徐々に見ていきたいと思いますので、今回はここまでです。

NIST SP800-63Bへの同期可能な認証器に関する補足文書がリリースされています

こんにちは、富士榮です。

パスキーを使う際に、AppleやGoogle、Microsoftなどのクラウドプラットフォームを通じたデバイス間で鍵の同期を行うSyned Passkeysをどう扱うか？、つまりそもそもFIDO認証の良いところはデバイスとの紐付けが強固であることだったはず、一方で鍵のリカバリが認証強度の弱点となりクレデンシャルの盗難や不正利用のきっかけになってしまう、その意味で鍵の同期は必要なのである、といった論争もひと段落してきたわけですが、その意味でパスキーを念頭においた各種ガイドラインについても更新される時期が来ているのかもしれません。

今回、NISTからSP800-63Bに関する同期可能な認証器に関する補足文書が公開されています。

アナウンス原文はこちら）

https://www.nist.gov/blogs/cybersecurity-insights/giving-nist-digital-identity-guidelines-boost-supplement-incorporating

 公開された文書はこちら）

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf

 

アナウンスに概要が記載されているので紹介しておきます。（Google Webページ翻訳）

補足文書とは何か？

補足は、既存の NIST Special Publication (SP) を強化、拡張、または詳しく説明することを目的とした特定の文書タイプです。これにより、SP 全体を更新するプロセスを経ることなく、対象を絞った更新や変更が可能になります。これらは、NIST がテクノロジーとリスク環境の変化により迅速に適応するためのメカニズムを提供します (たとえば、同期可能な認証システムのような新しい認証システム タイプの要件を提供します)。 

同期可能な認証器とはなにか？

同期可能な認証システムは、秘密キーを複製して認証システムとは別に保存して、異なるデバイス間でのその鍵の使用 (同期など) をサポートできる暗号化認証システムです。実際には、これらは通常、FIDO Allianceによって「パスキー」と呼ばれるもので、Client-to-Authenticator Protocol や World Wide Web Consortium (W3C) の Web Authentication (WebAuthn) などの複数の標準およびプロトコルを利用します。 

正しく実装されると、シンプルなリカバリ、クロスデバイスのサポート、消費者に優しいプラットフォーム認証サポート (ネイティブ生体認証など) など、多くの利点を備えたフィッシング耐性のある認証システムが提供されます。このような認証システムは、デジタル ID ガイドラインのコンテキストでは非準拠とみなされ、補足では、認証保証レベル 2 (AAL2) での使用を許可するための追加の要件と考慮事項が規定されています。 

ガイドライン（SP800-63-3）が発行されてからの世の中の変化は？

多くのことが変わりました。ガイドラインが最初に開発および発行された時点では、同期可能な認証システムをサポートするための標準と仕様は開発されていませんでした。それ以来、標準は成熟し、ほとんどの主要な消費者プラットフォームが同期可能な認証システムのサポートを導入しました。  FIDO Alliance はこれまでのところ、80 億を超えるユーザー アカウントが認証にパスキーを使用するオプションを備えていると推定しています。まだどこにでも普及しているわけではありませんが、日に日に一般的になってきています。 

鍵の複製に関するリスクは？

そう、リスクは常に存在するのです。補足の要件は、キーの保存、送信、保護の方法を含め、これらの要件にできるだけ多く対処することを目的としています。同期可能なオーセンティケーターには特有のリスクが伴います。特に、一部の技術実装におけるユーザーが自分の認証キーを他の個人と共有する機能です。認証子を共有する機能は同期可能なキーに固有のものではなく、ほぼすべての AAL2 認証子を共有できます。しかし、長年のセキュリティ ポリシーに反して、一部の実装では、多くの消費者シナリオでパスワード共有の安全な代替手段として同期可能な認証子の共有を推進しています。 

すべてのインスタンスと同様に、組織は、提供するあらゆるタイプの認証システムを評価し、実装する前にそれに伴うメリットとリスクを比較検討する必要があります。同期可能なオーセンティケータは、すべてのアプリケーションやサービスに適しているわけではありませんが、エンドユーザーと信頼当事者の両方に多くのメリットをもたらす、新たな AAL2認証器オプションとなります。

パブリックコメント期間は設けられるのか？

この更新文書には適していません 。 SP 800-63-4 に関する最初のパブリック コメント期間からのフィードバックがこの補足資料に組み込まれました。同期可能な認証システムと補足の全体的な内容に関する追加のコメントは、リビジョン 4 の今後の第 2 回パブリック コメント期間を通じて提出できます。これは今年後半に行われる予定です。 

SP800-63-4を待たないのか？

上で述べたように、デジタル ID ガイドラインの規範文に厳密に従っている政府機関は、同期可能な認証システムを使用することを許可されません。この補足では、連邦ゼロトラスト戦略をサポートする強力で使いやすく、フィッシング耐性のある認証を提供する新しいセキュリティ技術の使用方法についての指示を提供することで、多くの政府機関の当面のニーズに対応しています。リビジョン 4 が完成すると、この補足は廃止されます。

技術や状況は日々変わってきているので柔軟にガイドラインも対応していく必要がありますね。

eKYCとOpenID Connectに関する最近のアクティビティ

こんにちは、富士榮です。

年明けから異常な忙しさでほぼ4か月ぶりの投稿になってしまいました。

今日はOpenID Foundationが今年から本格的に仕様化を進めているeKYC、ID保証に関する新しい仕様である「OpenID Connect for Identity Assurance」について紹介したいと思います。
ワーキンググループが始まったころは、ここまでリモートワークや非対面が重要になる、という局面を誰も予測していませんでしたが、ここに来てオンラインでのID保証、eKYCに関するニーズが本格化しているのは恐ろしい偶然としか言いようがありません。

尚、この「OpenID Connect for Identity Assurance」は、ちょうど1年程前から私もOpenIDファウンデーションジャパンのKYCワーキンググループをリードさせていただいている関係で共同議長を務めさせていただいている、米国OpenID FoundationのeKYC and Identity Assurance Working Groupで仕様策定が進められています。

ID保証（Identity Assurance）とは？

アイデンティティ管理に必ず付いて回るのが、デジタル・アイデンティティの精度や鮮度をはじめとする「信頼性」の課題です。

例えば、エンタープライズのシナリオでは、そのアカウントの持ち主はまだ在籍しているのか、権限付与に使っている役職は正確なのか？などといった「アイデンティティ・ライフサイクル」を管理するためにMicrosoft Identity ManagerやLDAP Managerなどの製品を使って効率的かつ正確なアイデンティティ管理を行います。

また、コンシューマのシナリオではいわゆる「KYC：Know Your Customer」といわれるID保証に関する課題を常に抱えています。これは例えば、サービスの利用を開始する際に登録する氏名や住所、年齢などの属性が本当に正しいのか？という「本人確認」や「身元確認」と言われる課題で、サービスの種類によっては利用者が一定の年齢を超えていることが法令で決められていたり、サービスの利用を許可するために必要な収入や本人到達性などの要件を満たす必要があったりするケースにおいては非常に重要なID保証のユースケースの一つです。例えば、金融機関におけるAML（Anti Money Laundering：マネーロンダリング防止）やオンラインゲーム等における年齢制限などがユースケースとして該当しますね。


ちなみにIDに関する保証レベルを綺麗に体系化しているのが「NIST（米国国立標準技術研究所）」が発行しているセキュリティに関するガイドラインシリーズ（SP/Special Publications）の800-63です。※通称NIST SP800-63
尚、NIST SP800-63は連邦政府内の情報保護の要件を規定している「NIST SP800-53」の中のデジタル・アイデンティティに関するガイドラインとして位置付けられていますが、連邦政府と取引をする民間企業を対象としてNIST SP800-53から抜き出す形で定義された「NIST SP800-171」にも同様に適用されることなどから、実質的にデジタル・アイデンティティの保証に関するデファクトスタンダードとなっています。

脱線を続けますが、NIST SP800-63では以下の3つの区分でID保証に関する規定をしています。

• Identity Assurance Level（IAL）：NIST SP800-63A
• ID登録を行う時の本人確認・身元確認の強度（自己申告＜非対面＜対面など）
• Authenticator Assurance Level（AAL）：NIST SP800-63B
• 認証器の強度（単要素＜ソフトウェアベースの多要素＜ハードウェアベース多要素など）
• Federation Assurance Level（FAL）：NIST SP800-63C
• アサーション保護の強度（Bearer＋署名＜Bearer＋署名＋暗号化＜HoK＋署名＋暗号化など）

各ガイドラインの日本語訳をOpenIDファウンデーション・ジャパンが公開しているので、興味のある方は参考にしてください。
https://openid-foundation-japan.github.io/800-63-3-final/index.ja.html


このように単にアイデンティティに関する「保証」といっても多岐にわたって考慮すべき点があります。

OpenIDファウンデーションジャパンにおける活動

冒頭で述べた通り、OpenIDファウンデーションジャパンにおいても先に述べた「KYC」に関するワーキンググループを2019年1月より設置し活動をしています。

このワーキンググループではOpenID Connectの仕様の拡張などといった単純に技術にフォーカスしたワーキングではなく、日本国内の各種業界（金融、テレコム、古物など）におけるID保証、本人確認に関する現状の調査、および現在業界毎に分断されている本人確認に関する要件の共通化に向けた課題の洗い出しなどポリシー面からの整理や、OpenID Connect for Identity Assuranceの仕様への国内事情のインプット、分散台帳を活用したアイデンティティの保証として注目されている「DID：Decentralized Identifier」や「VC：Verifiable Credentials」といった新しい技術の調査も、NFCリーダを使った公的証明書のICチップ読み取りや画像認識などeKYCに関連する技術に関しても網羅的に調査を行っています。

現在、ワーキンググループは第1シーズンの活動を終え、第2シーズンの活動を開始したところですので、興味のある方はこの機会にOpenIDファウンデーションジャパンへの入会とワーキンググループへの参画をご検討ください。

尚、第1シーズンの活動実績と成果物については2020年1月に開催された「OpenID Summit Tokyo」の中で発表させていただきましたので、詳しくは発表資料・成果物をご覧ください。

• KYC WGの活動報告（OpenID Summit Tokyoでの発表資料）
• サービス事業者のための本人確認手続き（KYC）に関する調査レポート（WG成果物）

米OpenID Foundationにおける活動

ようやくOpenID Connectの仕様の話です。米OpenID Foundationでは2020年1月より「eKYC and Identity Assurance Working Group」という新しいワーキンググループを立ち上げ、ID保証に関するOpenID Connectの新しい仕様である「OpenID Connect for Identity Assurance（通称OIDC4IDA）」の策定を進めています。尚、先に述べた通り、OpenIDファウンデーションジャパンでKYCワーキンググループをリードさせていただいている縁もあり、こちらのワーキンググループでは議長であるDr. Torste Lodderstedtの元、Mark Haine, Anthony Nadalinと共に共同議長を務めさせていただいております。

どのような仕様か

Abstractに記載されているとおり、本仕様は「OpenID Providerがエンドユーザに関する検証済みの属性をRelying Partyに対して提供するためのOpenID Connectの拡張」であり、「特定の法律に基づき自然人のアイデンティティを検証するために利用されることを意図して」定義されています。

This specification defines an extension of OpenID Connect for providing Relying Parties with verified Claims about End-Users. This extension is intended to be used to verify the identity of a natural person in compliance with a certain law.

簡単に言うと、OpenID Providerに登録されているアイデンティティが何に基づき、どのように検証されたものか？というメタデータを含めてRelying Partyに対して提供することにより、アプリケーション側が安心してサービスを提供することが出来るようにすることを目指しています。

例えば、ial_exmample_goldというトラストフレームワークに則って確認済みのgiven_nameとfamily_name属性の値である、ということをRelying Partyに伝達する時、id_tokenやuserInfoエンドポイントから以下のような形でverified_claimsとしてJSONが返却されます。

{
   "verified_claims":{
      "verification":{
         "trust_framework":"ial_example_gold"
      },
      "claims":{
         "given_name":"Max",
         "family_name":"Meier"
      }
   }
}

細かい技術面での解説はAuthleteの川崎さんが解説してくれていますし、少し前のDraftですが仕様の日本語化もされていますので、そちらをご覧いただければと思います。

• Authlete川崎さんのQiita
• OpenIDファウンデーションジャパンによる翻訳

仕様の現状

現在、本仕様は2nd Implementer's draftのレビュー期間が終わり、仕様の承認に関する投票が開始されています。
https://openid.net/2020/04/27/notice-of-vote-for-second-implementers-draft-of-openid-connect-for-identity-assurance-specification/

こちらも興味があれば米国OpenID Foundationの会員（個人でもなれます）として加入していただき、仕様策定にコントリビュートしていただければと思います。
（意外と日本人もいますよ！）