2024年4月26日金曜日

CACTIの次世代クレデンシャルに関するレポート(1)

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

先日書いたInternet2のNext Generation Credential Working Groupのレポートについて見ていきます。

オーサーはInternet2、デトロイト大学、イリノイ州立大学の方々が名を連ねています。
CACTI Next-Generation Credentials Working Group自体のメンバーはかなり多岐に渡っていて、先ほどのオーサーが所属する大学やMITなどの大学群、Yubico(といってもJohn Bradleyですが)、日本からもNII、Wide Project、私もOpenIDファウンデーション・ジャパンの帽子で名前だけ載っています。
(実態はほとんど貢献してません)

早速見ていきましょう。

まずは、エグゼクティブ・サマリです。

2023 年 4 月、Internet2 の Trust and Identity Services 部門のアーキテクチャ ガバナンス グループである Internet2 Community Architecture for Trust and Identity (CACTI) は、研究と教育 (R&E) のアイデンティティとアクセスに関する世界的な参加を求めるオープンなワーキング グループを設立しました。 管理 (IAM) コミュニティ。R&E ミッションをサポートする新しいテクノロジーの採用の可能性を探ります。

ちょうど、IIWのタイミングでInternet2のRoyさんとMITのDmitriさんと会話したところから私も参加することになりました。

どんな目標だったのか、についてチャーターに記載されています。

電子 ID の状況は、従来のフェデレーテッド Web シングル サインオン インフラストラクチャで使用されていた強力に集中化されたモデルから、ユーザー (資格情報保持者) が、いつ、どのような ID を主張するかを選択できるモデルに移行しつつあります。 どのような信頼当事者/検証者、そしてどのような種類の情報を開示するのか。 後者のタイプのユーザー中心のアイデンティティ エコシステムは、「自己主権アイデンティティ」、「検証可能な認証情報」、「ウォレットベースの認証情報」などとしてさまざまに知られています。
研究と教育のアイデンティティとアクセス管理エコシステムが成長し、この新しい環境と一連の期待に適応する必要があるかどうか、なぜ、どのように成長する必要があるかを理解するには、これらのテクノロジーの導入のユースケースと推進要因を理解する必要があります。 CACTI メンバーが単独で、より大きなコミュニティの強力な参加なしに、意味のある、または包括的なユースケースを導き出すことは不可能です。 そのために学習者、教師、研究者、管理者、卒業生など、多様なユーザー コミュニティの視点を入れることしました。

伝統的に大学はSAMLを使ったフェデレーションを構成しているわけですが、Verifiable Credentialをどのように利活用するか?はやはりグローバルでも大きなアジェンダになっている、ということですね。
ワーキンググループの成果についてこう続きます。

ワーキング グループは、比較的短い期間で「次世代認証情報」の意味を独自に定義し、InCommon および REFEDS コミュニティからユース ケースを収集するための呼び出しを作成しました。 2023 年 9 月の Internet2 Tech Exchange 会議での発表期限までに、このグループの会議は合計 8 回ありました。最初の会議は用語の定義と理解を構築するために費やされました。 多くの参加者がこのプロセスに意見を提供しました。 ワーキンググループのメンバーは、期限までに 31 のユースケースを収集して文書化し、最初の 8 つのユースケースを詳細に分析しました。 これらのサブセットは、今後の作業への推奨のために選択されましたが、後続の作業グループは、将来の検証に備えたアーキテクチャを定義するためにユースケースを使用する前に、ユースケースをさらに解釈して改良する必要があります (コミュニティの新しい調査からの追加の可能性もあります)。


Appendixに各ユースケースの説明がありますが、本当に多くのケースが集まりました。このケースから3つのケースに絞り込んで実際の検討を行っていったわけです。

次回はナラティブあたりを見ていきます。

2024年4月25日木曜日

滅びてほしい認証系の実装の話

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

ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。



考えていると結局のところ、サービス提供側が意図していることとは全然違うことが起きている気がするので、この辺はしっかり考えて実装したいところですね。(実装ミスは問題外として)

カテゴリ滅びてほしいもの実装側がやりたいこと利用者が感じること実際に起きていること代替手法
認証CAPTCHAbot避けぐにゃぐにゃ文字が読めない
バイクと自転車の違いとは?
ユーザの離脱、カゴ落ちパスキーの利用
新しいタイプのCAPTCHA(通常は画面に出ない)
リスクベース認証との組み合わせによる抑制
認証パスワード誰でも使える認証手段の用意忘れる。複雑なパスワードをそれぞれのサービス毎に管理するのは無理パスワードの使い回し。パスワード漏洩が他サービスへ迷惑をかける(逆もしかり)パスキーの利用
認証パスワードマネージャが対応できないパスワードポリシー、input type要素の設定ミス。コピペができない、自分の設定したパスワードの確認ができない何も考えていない(単なる考慮不足)パスワードマネージャが使えないので自分でパスワード入力が必要で面倒くさい簡単なパスワードの指定パスワードマネージャを考慮した実装
認証(届かない)OTP認証強化(所持認証)SMS受信できないSIMなんだけど
なかなか届かない。すぐにログインしたいのに。
ユーザの離脱、カゴ落ちパスキーの利用
認証(音声通知のみの)OTP認証強化(所持認証)データSIMやiPadじゃ使えない
面倒臭い
ユーザの離脱、カゴ落ちパスキーの利用
認証input typeがpasswordになっているOTP(毎回記憶を促される)何も考えていない(単なる考慮不足)面倒臭いパスワードマネージャが毎回更新の確認をしてくる適切な実装
認証キャリア回線認証認証強化(所持認証)wifi切り替えが面倒(別デバイスで使えない)ユーザの離脱、カゴ落ちパスキーの利用
認証ソフトウェアキーボードキーロガー対策面倒臭いユーザの離脱、カゴ落ちパスキーなど知識認証を使わせない仕組み
(そもそもキー入力不要にする)
認証定期的なパスワード更新パスワードが漏洩していても安心面倒。仕方ないので簡単なパスワードの末尾を1,2,3とインクリメントして使い回そう簡単なパスワードの指定複雑なパスワード要件の定義によるパスワードマネージャ利用の促進と併せて定期変更の無効化
パスキーの利用
認証乱数表認証強化(所持認証)どこいった?ユーザの離脱、カゴ落ちソフトウェア認証器、パスキーの利用
認証第2パスワード認証強化(多段階)忘れる。意味は?問い合わせの増加、ユーザ離脱ソフトウェア認証器、パスキーの利用
証明書オレオレ認証局のRoot CA入れろってやつ...w第三者に頼らずに信頼できる環境を作り上げたい(JPKI・・・)面倒くさい、やり方が複雑すぎるユーザの離脱、カゴ落ちブラウザベンダとの調整
上位レイヤーでのトラスト確保
リカバリ秘密の質問パスワード忘れへのヘルプデスク対応を減らしたいどの質問にどう回答したか忘れる
出身地とかって他の人でも答えられるんじゃない?(全然秘密じゃない)
アカウント乗っ取り同期可能パスキーの利用
リカバリパスワードリマインドで平文パスワードが送られてくるパスワード忘れへのヘルプデスク対応を減らしたい不安。。ユーザの離脱、カゴ落ち同期可能パスキーの利用
識別独自ID(メールアドレスじゃない)好きなIDの利用によるロイヤリティ忘れる
好きなものが取れない
変えられない?
ユーザの離脱、カゴ落ちオートフィル
変更可能なIDの利用
本人確認eKYC(セルフィー+免許証の顔写真比較)本人確認うまくいかない券面偽造による不正登録ICチップの利用
登録偽ソーシャルログイン(メアドのverifyやパスワード登録を求めてくるやつ)属性入力の簡素化による離脱防止
認証手段は自前で用意することによるサポートの簡素化
ソーシャルログインなのになぜパスワード登録が必要なのかわからないユーザの離脱、カゴ落ち属性登録と認証手段登録の分離(UX)
認証手段としてパスキーをデフォルトにする
決済カードのCVVを入力させる決済を確実に、素早く実行できるのでカゴ落ちが減る不安。。ユーザの離脱、カゴ落ち
PCIDSSの取得が必須になりコストアップ
3Dセキュアなどに任せてしまう


他にもあればぜひご意見ください。



2024年4月24日水曜日

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 が完成すると、この補足は廃止されます。


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

2024年4月23日火曜日

Digital Credential Consortiumが公開しているVerifiable Credentials関連サービスを試す

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

Digital Credential Consortiumが公開しているOSSのVerifiable CredentialsのIssuer/Walletを試してみました。
Adminダッシュボード
Learner Wallet

何をするツールなのか、というと学修歴(に限りませんが)をVerifiable Credentialとして発行する管理ツール(ダッシュボード)とそれを受け取るための学習者向けのWalletの組み合わせになっており、管理者が定義したVCを学習者に対して発行することができます。

導入方法は非常に簡単で、
に書かれている通り、dockerイメージを落としてきて実行するだけです。

ただ、本ツールは基本的にメールでクレデンシャル発行要求を飛ばすところから始まる前提となっているので(要所要所にOpenBadge系の匂いがします)、メールサーバの設定をしてあげる必要があります。
そのためには、手順にある
curl https://raw.githubusercontent.com/digitalcredentials/docs/jc-compose-files/deployment-guide/docker-compose-files/admin-dashboard-compose.yaml | docker compose -f - up

ではなく、 

https://raw.githubusercontent.com/digitalcredentials/docs/jc-compose-files/deployment-guide/docker-compose-files/admin-dashboard-compose.yaml

をダウンロードしてきてメールサーバに関する記述を変更した上で、docker-compose.ymlにリネーム、docker-compose -up -dをする方がベターです。

変更対象は

      - SMTP_HOST=sandbox.smtp.mailtrap.io

      - SMTP_USER=myusername

      - SMTP_PASS=mypassword

の3行です。私はテスト用にmailtrapを使ったので必要なSMTPホストやユーザID、パスワードはmailtrapのサンドボックスの値を使いました。

これでdockerイメージから起動すると、http://localhost:3000で管理画面へアクセスできます。初回は管理ユーザを作成するところから始まります。
最初の画面です。
まだ何もありません。
使い方としては、まず最初にCredential Templatesから発行するVCの定義を行います。
タイトルやテンプレートとなるJSONを記載してきます。
ちなみに
にサンプルのJSONテンプレートがあるのでそのまま使いました。
定義ができました。
次がEmail Templatesです。先ほど書いた通り、メールでVC発行をユーザへ通知する仕組みなのでそのメールの本文を定義します。
これも先ほどのドキュメントにテンプレートのサンプルがあるので、そのまま設定します。
これで設定はおしまいです。
非常に簡単です。

あとは、実際にVCを発行することになりますが、最初のIssuance OverviewのページからUpload and Prepare BatchをクリックしてVCの発行を行います。
基本は先ほどのCredential Templatesの定義とEmail Templatesの定義を指定し、CSVファイルに記載した宛先に対してメールを飛ばす仕組みになっています。

必要なフィールドを入れたCSVファイルを用意してアップロードします。
準備ができるとこんな感じで送信確認を行います。

実際に送信するとメールが届くのでメールのリンクをクリックします。
先述の通りmailtrapを使っているのでサンドボックスからメールの確認ができます。
このリンクを実行するとVC発行のQRコードが出てきます。

これを先ほどのLearner Walletで読み込みます。
すると、、、、エラーがでます。



作者のDmitriに聞いてみましたが、どうやらバグっぽいので治るのを待ちましょう。
しばらくしたらまた試してみたいと思います。

しかし、こう言うツールがOSSで出てくるのは非常にいいですね。うまくコントリビューションしていければと思います。




2024年4月22日月曜日

自民党web3PTの2024年版ホワイトペーパーのテーマの一つはDID/VC

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

先日リリースされた自民党のweb3PT(プロジェクトチーム)のホワイトペーパーのテーマの一つとしてDID/VCが取り上げられていますね。ブロックチェーン、DAO一筋だったころに比べると社会実装に向けて現実的な路線も取り入れられてきていて成熟してきた感があります。


新たなテクノロジーが社会基盤となる時代へweb3PTが「ホワイトペーパー2024」を策定

https://www.jimin.jp/news/information/208018.html


発行されたホワイトペーパーの要旨にはこんな感じで「VC及びDIDの利活用促進、DIWに関する検討」がテーマとして記載されています。実はこのDID→VCではなく「VC及びDID」となっているところが個人的には注目です。これまでのweb3ではDIDが全面に出てきていましたが、ようやく本質はVCだということが理解されてきたようです。事務局のみなさん本当にお疲れ様です。



ちなみに、平井卓也さんのInstagramに会合の様子が掲載されています。この会は私もお邪魔してVCとブロックチェーンの関係性の話を少しお話してきました。(あんなに細かい話をして良かったのかどうかは置いておいて)


ちなみにホワイトペーパーは平将明さんのページにダウンロードリンクが紹介されています。

https://www.taira-m.jp/2024/04/web3-3.html


2024年4月21日日曜日

Interopカンファレンスは今年もトラストで!

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

昨年はパネリストでおよびいただいておりましたが、今年はプログラム委員を拝命いたしましたInteropカンファレンスがいよいよ6月に迫ってきています。申し込みも開始されたようなのでぜひお越しください。


さて、私の担当プログラムは例によってトラストが中心です。

  1. Trusted Web(1) デジタル空間におけるトラストをいかにして実現するか?
    • こちらはクロサカさん、鈴木先生と一緒にTrusted Webの進捗を語りたいと思います。ちょうどホワイトペーパーもv3.0が昨年度発行され、いろいろな取り組みが表に出てき始めていますが、まだEUのように社会実装にまでは至ってはいません。この辺りについての観測と今後の展望についてお話しできるといいのではないかと思います。
    • https://f2ff.jp/introduction/8830?event_id=conf-2024-06
  2. Trusted Web(2) 実社会での本格利用に向けて動き始めた分散型IDとデジタルIDウォレット
    • こちらはDataSignの太田さん、DNPの岡本さん、高市さんをお招きして実際に開発をされている方々のご意見を伺ってみたいと思います。両社ともTrusted Webの実証事業者としてウォレットや分散型IDに関する基盤開発に関わってきていらっしゃる事業者の方なので、開発の実際や今後の展開における課題などを聞いていきたいと思います。
    • https://f2ff.jp/introduction/8831?event_id=conf-2024-06



もちろん、これ以外にも数多くの興味深いセッションがありますので、ぜひ参加登録をしてください。

2024年4月20日土曜日

OpenID Technight #21を開催します。今回はShared SignalとIIWの振り返りです

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

半年ぶりくらいになるでしょうか?OpenID Technight #21を開催します。
今回は対面+オンラインのハイブリッド開催です。

気になるテーマはマニアックに「Shared Signal Framework」です。まさにID基盤を裏から支える縁の下の力持ちのフレームワークで、主にリスクイベントやアイデンティティ・ライフサイクル上で発生する様々なイベントを裏側でIdP同士やIdPからクライアントへ伝達するためのシグナリングのための仕組みです。

また、時期的にもInternet Identity Workshop(IIW)の前後でありましたOpenID Foundation Workshopを含むIIWでの最新情報などについても、OpenIDファウンデーションジャパンの最新動向と合わせてお話できると思います。

ということでぜひ重し込みください。

お会いできるのを楽しみにしています。