ラベル Trust Framework の投稿を表示しています。 すべての投稿を表示
ラベル Trust Framework の投稿を表示しています。 すべての投稿を表示

2024年11月28日木曜日

SIDI Hub - ベルリンレポートを読む(11)

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

少し間が開きましたが、SIDI Hubベルリンレポートを見ていきます。

前回はTrust FrameworkマッピングをOIXのDigital ID Trust Framework DNAにそって分類をした、というあたりまで触れました。

今回はその結果見えてきた”ゴールデンクレデンシャル”について触れているところから、です。

早速見ていきいましょう。

As a part of this work, they identified 5 “golden credential” types that would need to be standardized and globally adopted in order to achieve interoperability in their respective use cases:

この作業の一環として、彼らはそれぞれのユースケースにおける相互運用性を実現するために標準化され、世界的に採用される必要がある5つの「重要な資格」を特定しました。


対象は、

  • National ID Cards(国民ID)
  • Passport(パスポート)
  • Bank Accounts(銀行口座)
  • Driving Licenses(運転免許証)
  • Telco Accounts(携帯電話アカウント)
が挙げられています。まぁ、順当ですね。
数年前のEIC(だったと思う)でMartin Kuppingerもこれからは銀行と通信キャリアがデジタルIDの根幹を担うのである、なんて発言をしていたこともありますが、まぁ普通に考えればそうでしょうね。

Furthermore, these credentials are essential foundations for identification in jurisdictions that have no national identity scheme. In those cases, they have a policy model defining levels of assurance built upon inputs such as these credentials above:
さらに、これらのクレデンシャルは、国民IDのスキームを持たない管轄区域における識別のための不可欠な基盤です。そのような場合、これらの認証などの入力情報に基づいて保証レベルを定義するポリシーモデルが用意されています。

はい、まさに上に書いたMartinの話とも繋がります。国が用意した本人確認書類(Identity Document)が(一部)機能していない国(実はアメリカもそうですよね)でもオンライン・オフライン問わず身元確認をするニーズは当然存在するわけです。その際に国民ID以外のクレデンシャルを使って身元確認を行う、というのはインクルージョンの観点でも非常に重要です。ただし、その際にじゃあそのドキュメントの発行にはどのくらいの保証レベルが担保されているのか?という話ですね。


この保証レベルを算定するためのモデルをOIXで提供している、ということです。

そして次のステップについても語られています。

As next steps, the Trust Frameworks working group, in partnership with OIX, intends to:

  • Publish its findings
  • Conduct more analysis in new jurisdictions
  • Build a comparison tool
  • Propose policy criteria for metadata exchange

次のステップとして、トラストフレームワーク作業部会は、OIXとのパートナーシップのもと、以下のことを行う予定である:

  • 調査結果の公表
  • 新たな管轄区域におけるさらなる分析の実施
  • 比較ツールの構築
  • メタデータ交換に関するポリシー基準の提案 

これは先日の東京サミットでも話がありましたが、日本のDS500も含めてトラストフレームワークマッピングは一定の進行を見せていましたね。また、今後は国が提供するトラストフレームワークのみならず領域ごとにマッピングを進めていくことになると思います。本当の意味で役に立つのは領域単位で意味のあるマッピングがなされてからになりそうです。

ここで目を引くのが最後に挙げられているメタデータ交換におけるポリシー基準の話です。これは何か?についてこんな図が提示されています。


要するに中央集権型だろうが分散型だろうがフェデレーション型だろうが、トラストフレームワークをマッピングするためには当該のトラストフレームワークに関するメタデータを交換できるような仕掛けが必要になるってことですね。

こんな形で解説されています。

Whatever the mechanism, the Trust Framework mapping and analysis forms the basis for metadata exchange requirements. This is useful for jurisdictions now looking to create their own Trust Framework and in order to facilitate negotiations and, eventually, the technologies that will enable dynamic interactions on a transaction-by-transaction basis (for example: “Smart Wallets”). Interestingly, in mapping all of the actors and rule-sets that would be required in such an ecosystem, the analysis shows that much of it actually has been defined in the eIDAS 2.0 framework.

仕組みが何であれ、トラストフレームワークのマッピングと分析はメタデータ交換要件の基礎を形成する。これは現在、独自のトラストフレームワークを構築しようとしている国・地域が、交渉や、最終的には取引ごとのダイナミックなやり取りを可能にする技術(例えば「スマートウォレット」)を促進するために有用である。興味深いことに、このようなエコシステムで必要とされるすべてのアクターとルールセットをマッピングすると、その多くがeIDAS 2.0のフレームワークで定義されていることがわかる。


 

eIDAS2.0にトラストフレームワークを重ね合わせるとこんな感じになります。Identity Assuranceに関するルール、Credentialに関するTrustルール、WalletやデジタルIDに関するアカウントTrustルール、ユースケース単位のTrustルールに分類され、これはWalletモデル以外への適用もできる、いわゆるメタなフレームワークとなっている、という整理です。

このモデルについてベルリンではグループに別れて議論が行われます。


トラストフレームワークを比較するためのツールは何をすべきか、どのように展開されるべきか、誰が使うべきものなのか、など議論は多岐に渡ります。


結果として会場からはこれらの意見が集まっています。まとめるのは非常に難しいと思いますが、今後一歩ずつ集約していけると良いと思います。

今後はTrust Framework Work Streamでは、トラストフレームワーク比較ツール、どのルールが必要なのか、などについて議論を継続していくということです。

この後、Nickが実際に比較をしてみてどのようなギャップがあったのか?についてまとめて話してくれていますが、それはまた改めて。








 


 

2024年9月4日水曜日

SIDI Hub - ケープタウンレポートを読む(3)

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

引き続きSIDI Hubケープタウン会合のイベントレポートを見ていきます。今回はトラストフレームワークのセッションに関するレポートです。


早速見ていきましょう。

Trust Framework - 報告者:Stephanie de Labriolle

次はトラストフレームワークのワークストリームです。このセッションはElizabeth GarberとOpen Identity ExchangeのNick Mothershaw(リモート参加)が担当しています。

Stephanieのレポートによると参加者の半数くらいしかトラストフレームワークについて馴染みがなかったようですが、各国の法律やルールなどはすでにトラストフレームワークの主要な要素を持っているためElizabethからその辺りは説明がされたようです。

OIXのこの辺りの資料で説明したとのことです。

セッション中ではトラストフレームワークの利点の例として以下が挙げられたとのことです。

  • As a state, I want to flawlessly recognize an individual and know they are unique so that I can offer the right access and services
    • a Trust Framework defines requirements for Identity Proofing and Levels of Assurance
  • 国家としては、個人を完璧に認識し、その人が一意であることを知って、適切なアクセスやサービスを提供できるようにしたい。
    • トラストフレームワークは、アイデンティティの証明と保証レベルの要件を定義する
  • As a user, I want to know that my private information is safe so that I can avoid scams, identity theft, and harms in the digital and physical worlds
    • a Trust Framework defines requirements for Privacy, Security, Relying Parties/Verifier Obligations, Data Management, etc.
  • ユーザーとして、私は自分の個人情報が安全であることを知りたい。そうすれば、詐欺、個人情報の盗難、デジタルおよび物理的な世界での危害を避けることができる。
    • トラストフレームワークは、プライバシー、セキュリティ、依拠当事者/検証者の義務、データ管理などの要件を定義する
  • As an Identity Issuer I want to know that the information is going to a trustworthy place so that I can protect users’ data
    • a Trust Framework defines requirements for Relying Party/Verifier Obligations, and Trust Registry protocols
  • ID 発行者として、情報が信頼できる場所に送られることを知り、ユーザのデータを保護したい。
    • トラスト・フレームワークは、依拠当事者/検証者の義務、およびトラスト・レジストリのプロトコルの要件を定義する
  • As a user, I want to know that I can safely use my credential anywhere to prove who I am, what I can do, and to access resources
    • the Trust Framework defines requirements for Credential Standards
  • ユーザとして、自分が誰であるか、何ができるかを証明し、リソースにアクセスするために、自分のクレデンシャルをどこででも安全に使用できることを知りたい。
    • トラスト・フレームワークは、クレデンシャル標準の要件を定義する

そして、Open Identity Exchange(OIX)は以下の8つのトラストフレームワークの分析を実施してきました。

日本は???
安心してください。その後OpenIDファウンデーションジャパンの有志でちゃんと進めてくれています。次の日本会合ではその辺りも発表があると思います。

なお、OIXの分析の結果、OIXが「デジタルIDトラストフレームワークのDNA」として定義している「一般的なポリシー・ルール」と「アイデンティティ保証に関するポリシー」の2つの主要テーマと、関連するサブテーマが設定されています。

ここでも小グループに分かれてディスカッションを行い、トラストフレームワークの要素を用いて各国の状況の分析を行っています。
詳細はレポートを見ていただければと思いますが、こんな感じで分析したようです。


また、トラストフレームワークのベネフィットについても議論が行われました。
結果、以下のようなまとめが行われたとのことです。
この分析のベネフィット
  • 相互運用性の推進
  • データ保護とセキュリティの促進
  • コストの削減
  • 包摂
  • デジタル経済の発展
  • 官民サービスの提供への志向
一方でチャレンジとして以下も挙げられています。
  • ポリシーをどのように運用していくか
  • デジタル化をどのように進めるか
  • 人的要因・サイロ化・リーダーシップの課題への対応
  • インフラの不足
  • スキル不足
  • 地理的な問題、規模、セキュリティ上の問題
そして、何が足りないのか?についても議論が行われ、「専門家のアドバイスの中立性をどのように担保・確認するのか?」などについても語られたようです。どうやら一部の国の政府は外部有識者へのアドバイスを求める際、公平性や中立性に課題がある、と考えるケースもあるようです。


なお、トラストフレームワークの議論についてもUNHCRとの関連で議論が行われました。
Meanwhile, non-jurisdictions focused on how to support UNHCR, which has the challenge of serving 130M current refugees that are part of the UNHCR system and under their protection. They have integrations with about 7 strategic partners including refugee origin and destination countries, and they need to have 50-60 more integrations to national civil registry systems. Some users entering the system will have documents from their origin country and the origin country system of record may be accessible to check data against and people may have mobile devices (e.g. Ukraine), while other individuals may not have mobile devices and may be stateless or originate from failed states where records are not available.

一方、非管轄当局は、UNHCRをどのように支援するかに焦点を当てた。UNHCRは、UNHCRのシステムの一部であり、その保護の下にある1億3,000万人の現在の難民にサービスを提供するという課題を抱えている。UNHCRは、難民の出身国や目的地を含む約7の戦略的パートナーと統合しており、さらに50~60の国別市民登録システムとの統合が必要である。システムに入る利用者の中には、出身国の文書を持っていて、データを照合するために出身国の記録システムにアクセスできたり、携帯端末を持っている人(ウクライナなど)がいる一方で、携帯端末を持っておらず、無国籍であったり、記録が利用できない破綻国家出身であったりする人もいる。 

数多くの難民を支援するUNHCRでは多くの国のシステムとの相互運用性を実現する必要がありそうです。しかしながら難民の状況はさまざまなので国民IDシステムへのアクセスができない場合などもあるので非常に難しい舵取りが求められている状態のようです。

またウクライナの状況を例としてUNHCRに何が求められるのか?についても議論が行われ、難民登録やデジタル技術による解決なども話題に上ったようです。


ということでトラストフレームワークのセッションも終わりです。

次回はガバナンスです。




 





2024年7月6日土曜日

ニュージーランドのデジタルID規制機関が始動

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


少し前のニュースですがニュージーランドで今月からデジタルIDに関する規制を行う機関(要は認定機関)である「Trust Framework Authority」の活動が開始されているようです。

ニュースソース

https://www.biometricupdate.com/202407/new-zealand-digital-identity-regulator-opens-doors-ushering-in-era-of-digital-id

Trust Framework Authority(ニュージーランド政府のページ)

https://www.digital.govt.nz/standards-and-guidance/identity/trust-framework/trust-framework-authority/


認定を受けるとこんなマークが発行されるみたいですね。


導入の背景として行政サービス等のデジタル化があるようです。日本を含む他の国々と同じく、身分証明書のデジタル化(スマホ搭載等)によりオンラインでの身元確認ができるように、という話ですね。mDL(モバイル運転免許証)の導入も視野に入っているようです。

実際、日本においても身元確認書類(例えば免許証やマイナンバーカード)をスマホに搭載する話が進んでいますし、先日AppleもWalletにマイナンバーカードを搭載できるようにする、という発表が行われましたが、EUが一歩先でやっているように政府機関がある程度Walletプロバイダやサービスを認定できる状態にしておかないと、勝手にマイナンバーカードの券面読み取りAPIなどを使って「マイナンバーカードのコピー」をスマホに搭載してあたかも「公的な身分証明書」のように誤認されてしまう状態が大量に出来上がる、ということが懸念されます。(個人的な意見ですが)

そういう意味ではこのような認定機関をちゃんと作って運営をしていくことが日本にも求められてくると思います。


Trust Framework Authorityのページを見るとこの機関の責任は以下のように定義されています。

機関の責任
  • プロバイダーを認定する
  • 認定プロバイダーが信頼フレームワークの法律、規則、規制を常に遵守していることを確認する
  • 認定された提供者またはサービスに関する苦情を評価し、調査する
  • デジタル ID サービス信頼フレームワークの認定マークを管理する


まだ7月1日に走り始めたばかりで公開されている情報も少ないですが少し追いかけてみたいと思います。




2024年3月21日木曜日

RPは外部IdPをどこまで信頼するべきなのか

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

先日、「外部IdP利用時にRP側"でも"多要素認証を行うべきか」というポストをしました。

結局は”Relying Party”というくらいなのでIdentity Providerに依存する存在にはなるのですが、単に「認証機能を作るのが面倒くさいので外部IdPを使えば運用面・コスト面で楽になるよね」という文脈で語られることも多いのではないかと思います。

前回はacr/amrというツールの観点で少しだけ話をしましたが、本質的にRelying Partyは何をIdentity Providerに”頼って”いるのだろうか・・・ということを考えていく必要があるのではないかと思います。

今日はそんな話です。


Relying Partyとは何なのか?

まず、Relying Partyの定義を見ていきましょう。いつものISO 24760-1:2019のTerminologyを見るとこのように書かれています。

System that relies on other party (identity provider) to provide identity information. Relying party (also known as "service provider") usually relies on identity provider to authenticate the user, and relay the information to the relying party. Relying party has no access to credentials (e.g. passwords), it only knows that the authentication was successful. Identity provider may transfer identity attributes and additional information (such as authorization decisions) to the relying party. Relying party usually has a trust relationship with identity provider.

ID 情報の提供を他者(ID プロバイダ)に依存するシステム。依拠当事者(「サービス・プロバイダ」とも呼ばれる)は通常、ID プロバイダがユー ザを認証し、その情報を依拠当事者に中継することに依存している。依拠当事者はクレデンシャル(パスワードなど)にはアクセスできず、 認証が成功したことだけを知っている。ID プロバイダは、ID 属性と追加情報(認可決定など)を依拠当事者に転送する。依拠当事者は通常、ID プロバイダと信頼関係を持つ。(Deeplで機械翻訳)

これを見ると、

  • ユーザ認証の結果
  • ID属性
  • 追加情報(認可決定など)
といったID情報をIdPからもらって動作するシステムを指すようです。
そして、最後の一文が一番大切な文言です。
依拠当事者は通常、ID プロバイダと信頼関係を持つ。

「信頼関係」が構築されていることが前提ということですね。

信頼関係とは

もちろん単純にクライアント登録、redirect_uriの登録って話ではありません。それは信頼関係が構築された結果であり、それ登録があるから信頼関係がある、という話ではないわけです。(システム構築だけを見ていて、この辺は勘違いされているケースを多々見てきました・・・)

信頼関係を構築する上ではまずはお互いのことを知ることが必要となります。

RPからIdPを見ると、

  • どのようなID情報(属性など)を管理・提供しているのか
  • ID情報がどのような精度・鮮度で登録されているのか(いわゆるIAL)
  • 登録されたID情報は適切に管理されているのか(運用体制など)
  • ユーザ認証はどのような強度で実施されているのか
  • サービスレベル(可用性など)はどのようなレベルなのか
  • どのような技術仕様(プロトコルなど)をサポートしているのか

が気になる点の一例です。

また、同様にIdPからRPを見ても、

  • 提供したID情報を適切に扱われるのか(情報漏洩などへの対策など)
  • どのようなサービスに利用されるのか(反社会的勢力はもちろん、提供したID情報を用いて不適切だったり、責任を負いきれないほどの超重要なシステムに使われていたりしないか、など)
  • どのような技術仕様(プロトコルなど)をサポートしているのか
  • ブランディングを毀損しないかどうか

などが気になります。

信頼「関係」というからには単純に片方向だけでは関係は成立しないわけで、相互に信頼をする必要があります。

また、同様に接続をする断面だけでなく、継続的に信頼し続けるためにはどのくらいのインターバルで何を確認するのか?を確認しておく必要があります。

この辺りを定めたのがトラストフレームワークで、通常は接続するための前提事項や規則などに加えて継続的に誰が何を確認するのか、などの運用についても定義されています。

例えば、国立情報学研究所が定めている学認のフェデレーションに参加する機関に求めるルールが学認技術運用基準として定められています。

https://www.gakunin.jp/document/80

この辺りのトラストフレームワークはOpen Identity Exchange(OIX)が出している「Trust Frameworks for Smart Digital ID」が有名です。

https://openidentityexchange.org/a-guide-to-trust-frameworks-for-smart-digital-id


ソーシャルログインではどうなっているのか

FacebookログインやYahoo! ID連携など広範に使われるソーシャルID基盤ではRPと接続をする都度トラストフレームワークの取り決めをしたり運用の取り決めをするのは不可能に近いので、一般的にRPに開発・接続に関する規約を公開し遵守を求めています。

結果、IdPに非常に優位な状態が出来上がります。。(仕方ありませんが)

例えば、facebookの規約を見てみましょう。

https://www.facebook.com/legal/commercial_terms

4. Limits on Liability: In addition to and without limiting the scope of the “Limits on liability” section in our Terms, you agree that we are not responsible for the actions, services, content, or data of third parties and you release us, our directors, officers, employees, and agents from any claims and damages, known or unknown, arising out of or in any way connected with any claim you have against any such third parties.

4. 責任の制限: 利用規約の「責任の制限」セクションの範囲に加え、またその範囲を制限することなく、利用者は、当社が第三者の行為、サービス、コンテンツ、またはデータに対して責任を負わないことに同意し、利用者がかかる第三者に対して有する請求に起因する、またはかかる請求に何らかの形で関連する、既知または未知のいかなる請求および損害からも、当社、当社の取締役、役員、従業員、および代理人を免除するものとします。

結局何の責任も負いませんよ、と言うことですね。


日本企業はどうでしょうか?Yahoo! JAPANのID連携の規約を見てみましょう。

https://developer.yahoo.co.jp/yconnect/v2/guideline_20220401.html

例えば免責事項の3番目にこのような記載があります。IDに関する属性保証や認証結果に関する保証もないよ、と言うことですね。

利用者が予定している目的への適合性、有用性(有益性)、セキュリティ、権原、非侵害性および正確性等について当社が一切保証しないこと


上記を踏まえてRPはどうするべきなのか

ユースケース次第、としか言えないのですがそれだと思考停止するので、ID保証(IAL)、認証強度(AAL)を含めRP側でもちゃんと考えて対策を打つ必要があるのではないでしょうか?

つまり、何をIdPに頼って、何を頼らないのか、を考えることにもつながるわけですが、上記の通りソーシャルログインについてはほぼ何も保証はされないという前提で考えると、ユーザがRPの提供するサービスへ登録する際のハードルを下げる「離脱防止」という観点での依存を基本ラインとして、IDの保証が必要なサービスであれば追加の属性確認(KYCなど)をRP側でも実装することは考えないといけません。また認証強度が必要なのであれば先日のAuth0の例ではありませんが、RP側でも多要素認証などを個別で実装するなどしないと安全には使えない状態となるはずです。

この辺りは最悪のケース(IdP側のインシデントなど)が発生したとしても、RPが独立性を保った上でサービス提供を継続できるかという観点でサービス設計をしていくことが大切だと思います。



2024年3月18日月曜日

外部IdP利用時にRP側"でも"多要素認証を行うべきか

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

今回は多要素認証の話です。
ソーシャルIDなどの外部IdPと連携をする際、外部IdP側がパスキーに対応している場合もあり、基本的にRP側はIdPの認証結果を信じて何もしないという文字通り「Relying」な感じで構成されることが多いと思います。

しかしながら、本当にそれでいいの?とうケースも存在すると思うので、少し深掘りしてみましょう。
中々難しい話だと思いますが、IdP側(例えばGoogle)で認証を強化するか、RP側(例えばECサイト)で認証を強化するか、もしくは両方か、についてユーザ体験の妥当性を含めて考えていかないといけないところです。
IdPもRPもそれぞれ責任範囲が異なるので基本的に自分の責任範囲を守る目的で多要素認証を要求していますが、ユーザから見るとなぜ別々に、、という形に見えてしまうことも事実です。

この問題を根本的なところは先に書いた通り責任範囲の話を理解する必要があるのですが、ツール(技術面)とルール(契約を含め責任論)を合わせてみていかないといけません。この辺りをトラストフレームワークと言われるもので表現をしていくことになります。

まずは技術的な話

まずは簡単な話として、技術の話をしていきましょう。(本来はルールの話をした上で技術の話をするのが良いのですが、読者層を考えるとまずは目に見えるところから入るのが良いと思っています)

本来はIdPがacrやamrで認証手段(例えばパスキーで認証したよ)という情報を渡してあげればRP側はその結果を見て追加でパスキーを要求するべきかどうかの判断をしていくのが良いと思います。ただRPを作ったことがある方はわかると思いますが、
  • IdPによって返すacr/amrが異なる
  • IdPによっては返ってこないこともある
などの事情があるので、特に複数のIdPとのID連携を行う場合は中々面倒臭いことになります。

例えば、GoogleのOpenID Connectのサポート状況を見るとドキュメントを見る限りacr/amrに関する記載はありません。


Entra IDは一応amrの値を返しますが"pwd", "mfa"の2種類しか返せないのでパスキーで認証されても、OTPで認証されても"mfa"になると思います。

Oktaの例は56さんが試してくれていますがEntraよりは少しマシな程度っぽいですね。

ということで外部IdPの認証手段までを厳密かつ標準的に取得して利用するのは現時点では結構ハードルが高そうです。
この辺りは学術認証フェデレーションでは議論が進んでいるのですが、ある程度閉じたコミュニティの中だからできる議論でもあるので、パブリックなIdPだと難しいと思います。


そもそも論として、なぜ外部IdPと連携するのか?

また、そもそも論として各IdPをどこまで信じるのか?というか何のために外部IdPを使うのか?というところに遡ってしまいます。
単に、利便性(プロフィール入力の手間の削減、パスワード登録をさせない)を提供することでドロップ率を下げましょう、という場合もありますし、本気で外部IdPの認証結果に依拠しましょう、という場合もあります。

登録時にプロフィール入力を自動化してドロップ率を下げましょう、という話だけなら認証まで外部に依存する必要は本来ないと思います。パスワード登録をRP側でさせることでドロップ率が〜〜〜という話であればパスキーを使うなりなんなりしてパスワードに依存しない認証手段を用意すれば良いと思います。
(認証まで外部IdPに依存することでログインの都度外部IdPにリダイレクトされるとなると外部IdPが落ちていた場合に発生する機会損失などのリスクもありますし)

認証手段をRPが自前で持つことがリスクという考え方をする方もいるのは事実なので、その場合は外部IdPに頼ってしまうこととのリスクとの天秤で考えるしかないと思います。
(外部IdP側でアカウント侵害が起きたらどうするの?とか)


というあたりで外部IdPとの責任問題の話になってきたところで今回は終わりです。
ある程度答えは見えていると思いますが、次回以降で主要なIdPがどこまで責任を取ってくれるつもりなのか?について少しずつ調べてメモしていこうと思います。