こんにちは、富士榮です。
いよいよ9月10日（火）のワシントンD.C.会合と10月25日（金）の東京会合を経て、G20リオデジャネイロに向けて折り返そうとしているSIDI Summitのワールドツアーですが、過去の会合（ケープタウン、ベルリン）のレポートが公開されています。
https://sidi-hub.community/summits/
今回公開されたのは、ケープタウン会合のレポート（ドラフト）とベルリン会合のレポートです。
結構なボリュームなので次のワシントンD.C.会合に向けて徐々に読んでいこうと思います。
こんにちは、富士榮です。
残念ながら応募の締め切りは過ぎていますが、10月〜11月にカリフォルニア州のモバイル運転免許証のハッカソンが開催されます。
前者は名前の通り誰でも参加でき、後者は政府機関（＋ベンダ）のみが参加できるようです。
いずれにしてもmDLを利活用するシナリオを探して作ってみましょう、という取り組みですね。
https://www.dmv.ca.gov/portal/ca-dmv-wallet/mdl-for-technology-developers/hackathons-2024/
以前紹介したドイツのSPRINDの取り組みもそうですが、日本でもこのような取り組みを取り入れてコミュニティを盛り上げていけるといいですねぇ。
パスキーのデモにクレデンシャルの中身を解析する機能を追加しました。attestationObjectとかも中まで見えます。https://t.co/kWVU0flcfH pic.twitter.com/p6JDWZJkpf
— Eiji Kitamura / えーじ (@agektmr) August 28, 2024
こんにちは、富士榮です。
突然ですが、本人確認書類の電子化をする理由ってなんでしょう。
など、頑張れば色々と理由はつけられます。
 |
| OpenArtが書いてくれたモバイル本人確認書類。なんか変。 |
Perplexityにデジタル化の意義について聞いてみたらこんな回答が返ってきました。
質問）
免許証やマイナンバーカードなどの本人確認書類をデジタル化することによるメリットはなんですか？
回答）
デジタル化された本人確認書類には、以下のようなメリットがあります:
利便性の向上
- 携帯の容易さ
- デジタル化された本人確認書類はスマートフォンなどのデバイスに保存できるため、常に携帯することが容易になります。財布や身分証ケースを持ち歩く必要がなくなり、日常生活の利便性が向上します。
- 迅速な提示
- 必要な時にすぐに提示できるため、本人確認のプロセスが迅速化されます。デジタル形式であれば、必要な情報を素早く表示したり、関連する証明書を即座に呼び出したりすることが可能になります。
セキュリティの強化
- 偽造防止
- デジタル技術を活用することで、偽造や改ざんを防ぐ高度なセキュリティ機能を実装できます。電子署名や暗号化技術により、従来の紙の書類よりも安全性が向上します。
紛失リスクの低減
- 物理的な紛失のリスクが軽減されます。デジタル形式であれば、クラウドにバックアップを取ることができ、デバイスを紛失しても復元が容易になります。
行政手続きの効率化
- オンライン申請の促進
- デジタル化された本人確認書類があれば、さまざまな行政手続きをオンラインで完結させることが可能になります。例えば、マイナンバーカードを利用すれば、確定申告や各種証明書の取得がオンラインで行えるようになります。
データ連携の容易さ
- デジタル化により、異なる行政サービス間でのデータ連携が容易になります。これにより、複数の手続きを一度に行ったり、必要な情報を自動的に入力したりすることが可能になり、手続きの効率が大幅に向上します。
環境負荷の低減
- 物理的な書類の発行や更新が不要になるため、紙の使用量が削減され、環境負荷の低減につながります。また、郵送や窓口での対面手続きが減ることで、移動に伴うCO2排出量も抑えられます。
デジタル化された本人確認書類は、利便性、セキュリティ、行政効率、環境保護など、多岐にわたるメリットをもたらします。ただし、デジタル格差への配慮や、プライバシー保護の徹底など、課題にも適切に対応していく必要があります。
なんだか、想像通りすぎますね。特に後半はデジタル化の意味が違いますね。
追加で質問してみます。
質問）
デジタル化について、デジタイゼーションとデジタライゼーションの違いの観点から説明してください。
回答）
デジタイゼーションとデジタライゼーションは、デジタル化の異なる段階を表す概念です。以下にその違いを説明します:
デジタイゼーション
- デジタイゼーションは、デジタル化の最初の段階を指します。
- 定義
- アナログ形式の情報をデジタル形式に変換する過程です。
- 特徴
- 物理的な情報や資料をデジタルデータに変換します。
- 業務フローの一部をデジタル化することに焦点を当てます。
- 具体例
- 紙の書類や本をスキャンして電子ファイル化する
- 電子契約や電子署名の導入
- クラウドストレージやオンラインドキュメントによるファイル管理
- QRコードやバーコードの活用
デジタライゼーション
- デジタライゼーションは、デジタイゼーションの次の段階を表します。
- 定義
- ビジネスプロセス全体をデジタル化し、新たな価値を創出することです。
- 特徴
- 組織のビジネスモデル全体を一新します。
- クライアントやパートナーへのサービス提供方法を改善します。
- 特定の業務プロセス全体をデジタル化します。
- 具体例
- クラウドやAIなどのテクノロジーを導入して業務の自動化や最適化を図る
- オンラインでの販売やマーケティングを強化する
- 電子書籍の販売システムの構築
- 動画共有プラットフォームの運営
主な違い
- 対象範囲:
- デジタイゼーション: 個別の情報や業務フローの一部
- デジタライゼーション: ビジネスプロセス全体
- 目的:
- デジタイゼーション: 情報のデジタル化、業務効率化
- デジタライゼーション: ビジネスモデルの変革、新たな価値創出
- 影響度:
- デジタイゼーション: 局所的な改善
- デジタライゼーション: 組織全体の変革
デジタイゼーションとデジタライゼーションは、デジタル化の異なる段階を表す概念であり、企業のデジタルトランスフォーメーション（DX）を実現するための重要なステップとなります
こうやってみると本人確認書類のデジタル化はデジタイゼーションとデジタライゼーションが混ぜこぜで語られていそうですね。
まさに崎村さんが言うところの「西用と変法」ですな。
というか、そもそも運転免許証のデジタル化についてのメリットは「バーに入るとき免許証を全部見せる必要ないですよね。物理免許証だと選択的開示はできないけど、デジタル化すると21歳以上であることだけを示せるようになるんですよ！」ってみなさん言ってましたよね。
カリフォルニア州のモバイル運転免許証（mDL）やっているSpruceIDのWayneもBlogで語ってますよ。
TBDもそんな説明をしていましたね。。。
そして彼女がパスポートを係員に渡すと、「ああ、私たちは誕生日が同じなんですね！」とか「出身地は美しい島ですよね〜」とか言われてしまいます。
調べた結果VCは「過剰な個人データを明らかにせずに、法定飲酒年齢に達していることを証明する必要があるとします。完全な ID を提示する代わりに、ベンダーに VC を提示することもできます。販売者は資格情報を年齢証明として認識し、引き換えにアルコールを提供します。」
https://idmlab.eidentity.jp/2024/03/tbdverifiable-credentials.html
たぶん、こう言うアナログではできなかったことが、デジタル化することによってできるようになる、というのがデジタライゼーションでありイノベーションなんだろうなぁ、、と強く思います。
しかし、ちょうど先日カリフォルニア州のモバイル運転免許証がGoogle Walletに搭載できるようになった、という話も出てきていますしが、Apple WalletやGoogle Walletはスマホ搭載はするものの選択的開示はできなさそうです。
例のApple Walletにマイナンバーカードを搭載する件はどうなんでしょうか。。。うーん。
こんにちは、富士榮です。
OpenID Foundationや関係団体（Cloud Signature Consortium、GLEIF、IIF、OIX、その他関係する機関や個人）はグローバルで相互運用可能なアイデンティティ保証に関するネットワークに根ざしたエコシステムの達成を目指してGAIN（Global Assured Identity Network）の名のもと活動を行ってきました。
その結果がGAIN in 2023というホワイトペーパーとして発行されています。
もちろん先に掲げた大きな目標については一朝一夕で達成されるわけではないため、継続的な議論や技術研究が必要になるわけですが、最近OpenID Foundationから2024年の取り組みについて発表がありました。
GAIN Community Group: An Update
発表によると、2024年はOpenID for Verifiable Credential Issuanceにフォーカスしており、既にMeeco、Talao、Datevのウォレットを使ってIETF SD-JWT VCを発行できることの確認ができています。
今後はOpenID for Verifiable Presentationsへの展開、Open Identity Exchangeとの協業によるOpenID Federationとの組み合わせでのIssuerの信頼性の確立に向けた取り組みが続けられるということですので引き続き要注目ですね。
こんにちは、富士榮です。
少し前にPublic ReviewとVoteが行われていたShared SignalsのImplementer's Draftが承認されています。
https://openid.net/three-shared-signals-implementers-drafts-approved/
こちらのポストでレビューについては書きましたね。
https://idmlab.eidentity.jp/2024/06/shared-signalspublic-review.html
今回承認されたImplementer's Draftは以下の通りです。
OpenID Shared Signals Framework Specification 1.0: https://openid.net/specs/openid-sharedsignals-framework-1_0-ID3.html
OpenID Continuous Access Evaluation Profile 1.0: https://openid.net/specs/openid-caep-1_0-ID2.html
CAEP Interoperability Profile 1.0: https://openid.net/specs/openid-caep-interoperability-profile-1_0-ID1.html
なお、Shared Signals Framework（SSF）については5月に開催したOpenID TechnightのTom Satoさんの資料が素晴らしいのでぜひ見ておいてください。
こんにちは、富士榮です。
すでにあちこちで書き込まれているので今更私が書くこともありませんが、みんな大好きNISTのデジタルアイデンティティガイドラインであるNIST SP800-63-4 SPD（Second Public Draft）がようやく出てきました。（本当はもっと前に出るって噂でしたが）
とりあえずパブリックコメント募集は10月7日までこちらで。
そして、早速崎村さんが概略を日本語で書いていらっしゃいます。
https://www.sakimura.org/2024/08/6224/
オフィシャルには8月29日の午前1時から公開Webinarがあります。
https://nist.zoomgov.com/meeting/register/vJItcu6oqj0jH4xWLbz350jf6VeKM9bMjWc#/registration
さて、コメントに向けて準備しましょうかね。
こんにちは、富士榮です。
先日、大学ICT推進協議会（AXIES）の年次大会の話をしましたが、そちらに先行して（？）アイデンティティの勉強会が開催されます。
大学の認証基盤といえばSAML、Shibbolethなのですが、そろそろOpenID Connectに対応すると言われて久しいShibbolethが本当に対応するのかどうかは置いておいて、アカデミアでも使うサービスがOpenID ConnectのRelying Partyとなっているケースも増えてきており、そろそろ学術系でもOpenID Connectの勉強会をしないとね、ということでお話しさせていただこうと思います。
※そう言えばHPCIもOAuth対応しましたしね（OAuth認証になっているのはうーん、ですが）
ということでお知らせです。（申し込みサイトからの転載）
現地でお会いしましょう。
AXIES認証基盤部会では、以下の要領で2024年度 勉強会を開催いたします。会場は、学術総合センター（国立情報学研究所）とオンラインのハイブリッドで開催します。
テーマは、「フェデレーション、エコシステムとID管理」です。
NII学術情報基盤オープンフォーラムでのディスカッションを受け、学認コミュニティ拡大に向けたフェデーレション技術、エコシステムに関する勉強会を開催します。また後半では、昨年の年次大会を受け、ID管理についてディスカッションを行います。
日時：2024年9月17日（火）13:30～17:00
場所：国立情報学研究所 （オンラインのハイブリッド開催）
東京都千代田区一ツ橋２丁目１−２ 学術総合センター 3階
参加費：無料
定員：現地80名、オンライン200名
参加申込： 参加申込URL
プログラム：（敬称略）
13:30-13:35 はじめに
13:35-14:15 OpenID Connect（調整中）
富士榮 尚寛（伊藤忠テクノソリューションズ株式会社）
14:15-14:55 Gakunin Federation（調整中）
西村 健（国立情報学研究所）
14:55-15:05 休憩
15:05-15:45 アプリカタログ（調整中）
江川 淳一（エクスジェン・ネットワークス株式会社）
15:45-16:25 ID管理（調整中）
中村 誠（東京大学）
16:25-17:00 ディスカッション
こんにちは、富士榮です。
先日、IDProで紹介されていた記事を見つつ以下のポストをしました。
記事の中では同期ファブリックの安全性や互換性に関する課題が指摘され、デバイス紐付けパスキーという選択肢やUniversal Credential Exchangeによる相互運用性の実現に向けた取り組みの紹介をしました。
結果、エンタープライズでの利用の場合は同期パスキーよりもデバイス紐付けと管理などが現実的なのかな？？などのコメントを各所で頂いたりしました。
そんな中、RSAが最近こんなブログを公開しました。
Are FIDO Passkeys Ready for Enterprise Use?
https://www.rsa.com/ja/resources/blog/passwordless/are-fido-passkeys-ready-for-enterprise-use/
 |
| RSA社のブログ |
ベンダのブログなので若干バイアスがかかる可能性は否定しませんが、まさにエンタープライズでパスキーを使えるのかどうか気になっている人は必見だと思います。
ということで簡単に見ていきましょう。
まずはデバイス紐付きのパスキーと同期パスキーについて解説されています。この辺りはご存知の方が殆どだと思いますがおさらいしておきましょう。
Device-bound passkeys are generally hosted on specific ‘security key’ devices. On a device-bound passkey, key pairs are generated and stored on a single device; moreover, the key material itself never leaves that device.
With synced passkeys, the key material is saved via a so-called remote sync fabric, and the key material can then be restored on any other devices owned by the same user. The current major sync fabrics are Microsoft, Google and Apple. This means that if you were to register your Android phone as a passkey, then the corresponding key material would be available on all your other Android devices shortly after.
Synced passkeys are—in addition to the support of widely used services such as WhatsApp or Facebook—a main reason for the sharp increase in the general use of passkeys. It’s easy to see why: one user with a lot of accounts and a lot of devices can use the same synced passkey between all of them.
デバイスに紐づけられたパスキーは、通常、特定の「セキュリティキー」デバイスにホストされています。デバイスに紐づけられたパスキーでは、キーペアが生成され、単一のデバイスに保存されます。さらに、キー素材自体はデバイスから決して離れることはありません。
同期パスキーでは、鍵情報はリモート同期ファブリックと呼ばれる仕組みを介して保存され、同じユーザーが所有する他のデバイスにも復元することができます。現在、主な同期ファブリックとしては、Microsoft、Google、Appleが挙げられます。つまり、Androidフォンをパスキーとして登録すると、その後すぐに、他のすべてのAndroidデバイスでも対応する鍵情報を利用できるようになるということです。
同期されたパスキーは、WhatsAppやFacebookなどの広く使用されているサービスのサポートに加えて、パスキーの一般的な使用が急激に増加している主な理由です。その理由は簡単です。多くのアカウントとデバイスを持つユーザーは、それらすべてに同じ同期されたパスキーを使用することができます。
ユーザが直接サインアップして使うコンシューマ向けサービスではユーザビリティの向上を目標として同期パスキーが使われることで急激にパスキー自体の普及率が上がっている、ということですね。
パスキーの利点についてもおさらいされています。
Passkeys are an excellent MFA method: safe, fast, convenient, and users are already familiar with them. But the passkey benefit that’s beginning to get a lot of attention is that they’re phishing-resistant.
Passkeys can help organizations stop traditional phishing in its tracks: if there’s no password being used, then there’s no password to steal. And while that’s true for other passwordless MFA methods, passkeys have an added level of security provided by that synched key/service domain match.
In the U.S., phishing resistance is a major driver for government agencies. Executive Order 14028 requires phishing-resistant, passwordless authentication to secure critical infrastructure.
パスキーは優れた多要素認証の方法です。安全で、高速で、便利であり、ユーザーもすでに慣れ親しんでいます。しかし、現在注目を集め始めているパスキーの利点は、フィッシング対策に有効であるという点です。
パスキーは、従来のフィッシングを阻止するのに役立ちます。パスワードが使用されていなければ、盗むべきパスワードも存在しないからです。これはパスワード不要の他の多要素認証方法にも当てはまりますが、パスキーには、同期されたキー/サービスドメインの一致による追加のセキュリティレベルが備わっています。
米国では、フィッシング対策は政府機関にとって重要な推進要因となっています。大統領令14028では、重要なインフラストラクチャを保護するために、フィッシング対策のパスワード不要の認証が義務付けられています。
パスキーの一番の利点としてフィッシング耐性があることに触れられています。米国では大統領令でもフィッシングについての記載があるんですね。
ここからパスキーの課題について触れられています。
While passkeys provide significant advantages, they also come with a few significant challenges and problems.
For a solution that has grown up in the consumer environment, user guidance and the user experience can sometimes be a challenge.
Dialogs that ask the user to insert the passkey into the USB port or enter the PIN, for example, look different depending on the operating system and browser. Those prompts will likely make it more difficult to train users and minimize support calls.
Why not just change the prompts you ask? Because third-party service providers like RSA can’t: those prompts are set by the browser or OS vendor themselves in their own vendor (for instance, Apple sets their prompt for iOS, Google for Chrome, etc). There’s some good reason for this: if vendors could change the prompt, then so could attackers, using an updated form to spy on users. Keeping those log-in prompts locked is an important security measure, but it can make for a one-size-fits-all approach.
The high level of phishing resistance is a clear advantage, but it can also be a distraction. Anyone who thinks that the use of passkeys suddenly makes them immune to social engineering attacks is very much mistaken. Passkeys help against one type of social engineering attack: phishing. Unfortunately, there are other variants. The attacks on MGM Resorts or Caesars Palace in Las Vegas had a social engineering component: exploiting the help desk to allow the attacker to register an MFA authenticator himself.
Attackers adapt as a matter of course. The proliferation of MFA has made phishing much less attractive, so it’s only natural that vulnerabilities around the MFA system are exploited. Such as the way users register. Anyone who thinks passkeys solve these problems is very wrong.
パスキーには大きな利点がある一方で、いくつかの重大な課題や問題も伴います。
消費者環境で成長してきたソリューションでは、ユーザーへのガイダンスやユーザーエクスペリエンスが課題となることがあります。
たとえば、パスキーをUSBポートに挿入するようユーザーに求めるダイアログやPINの入力などは、オペレーティングシステムやブラウザによって表示が異なります。このようなプロンプトは、ユーザーのトレーニングを難しくし、サポートコールを最小限に抑えることが難しくなるでしょう。
では、求めるプロンプトを変更すればよいのでしょうか?RSAのようなサードパーティのサービスプロバイダーにはできないからです。これらのプロンプトは、ブラウザやOSのベンダー自身が、それぞれのベンダーで設定しています(例えば、AppleはiOS、GoogleはChromeなど)。これにはいくつかの理由があります。もしベンダーがプロンプトを変更できるのであれば、攻撃者も同様に変更でき、最新のフォームを使用してユーザーをスパイすることが可能になります。ログインプロンプトをロックすることは重要なセキュリティ対策ですが、画一的なアプローチになりかねません。
フィッシングに対する高い耐性は明らかな利点ですが、かえって邪魔になることもあります。パスキーの使用によって、ソーシャルエンジニアリング攻撃に対する耐性が突然得られると考える人は、大きな誤解をしています。パスキーは、ソーシャルエンジニアリング攻撃の一種であるフィッシングに対する防御策となります。残念ながら、それ以外にもさまざまな種類があります。ラスベガスのMGMリゾートやシーザーズパレスに対する攻撃にはソーシャルエンジニアリングの要素がありました。ヘルプデスクを悪用して、攻撃者が多要素認証の認証装置を自分で登録できるようにしたのです。
攻撃者は当然のように適応していきます。多要素認証の普及により、フィッシングはあまり魅力的ではなくなりました。そのため、多要素認証システム周辺の脆弱性が悪用されるのは当然です。例えば、ユーザーによる登録方法などです。パスキーがこれらの問題を解決すると考える人は、大きな誤りを犯しています。
1つはUI（プロンプト）がプラットフォームによって異なる（かつサードパーティのソフトウェアでは変更ができない）ことが挙げられています。OSベンダがプロンプトを変更させないのはセキュリティの観点から見ると合理的ではありますが、OSごとにプロンプトが異なるのはユーザから見ると混乱を招く一因となっていると思います。
また、フィッシング耐性がある、というキーワードがかえって誤解を与えてしまう懸念についても記載されています。そもそもフィッシングはソーシャルエンジニアリングの一部であることを理解しないと、ソーシャルエンジニアリング全般に対する対策となっている、という誤解を招く、と指摘されています。
同じく、システムへの多要素認証手段の登録機能自体がパスキーでセキュアになる、という誤解もあるようですね。
これも以前紹介した記事にも記載があった、同期ファブリックのセキュリティの話です。
They say that when you have a hammer, everything can look like a nail. Turing a solution—even a great solution—that was originally intended for consumer use into an enterprise application can introduce significant risk.
While reading this article, you may have had a queasy feeling at the mention of ‘sync fabric’. Your gut was right.
The fact that passkeys appear as if by magic on all devices on which the user is logged in via Apple or Google is a major red flag in the corporate environment and should raise some significant questions:
Should users be allowed to use several (possibly also privately used) devices for authentication at all? If so… How many?
Synced passkeys make restoring a “lost” passkey possible with the account recovery processes of e.g. Google or Apple. That’s great… but are these processes secure enough for you?
The Apple feature that allows users to share Passkey with friends or family is quite nice… but does this also apply to Passkeys that are used to log in to enterprise applications?
When using synced passkeys, the security of your company suddenly depends largely on the technical and organizational security of Apple and Google. Sure, there is a certain dependency anyway due to the use of iOS and Android—but synced passkeys increase this dependency considerably.
This isn’t a theoretical vulnerability, either. Last year Retool discussed how threat actors had used it to gain access to its systems: Retool wrote that the functionality means that “if your Google account is compromised, so now are your MFA codes.”
ハンマーを持っていれば、すべてが釘に見えるという。もともとコンシューマー向けに意図されたソリューション、たとえそれが優れたソリューションであったとしても、それをエンタープライズアプリケーションに転用することは、重大なリスクを伴う可能性がある。
この記事をお読みになっている方の中には、「同期ファブリック」という言葉に不安を覚えた方もいらっしゃるかもしれません。その直感は正しいです。
パスキーが、Apple や Google 経由でログインしたすべてのデバイス上に魔法のように現れるという事実は、企業環境においては重大な問題であり、次のような重要な疑問が生じます。
ユーザーは、認証のために複数の(場合によっては個人用も含む)デバイスを使用することが許されるべきでしょうか? もし許されるのであれば、何台まででしょうか?
同期されたパスキーは、Google や Apple のアカウント復旧プロセスによって「紛失した」パスキーの復元を可能にします。素晴らしいことですが、これらのプロセスは十分に安全でしょうか?
友人や家族とパスキーを共有できるAppleの機能は素晴らしいですが、これは企業アプリケーションへのログインに使用するパスキーにも適用されるのでしょうか?
同期されたパスキーを使用する場合、企業のセキュリティは突如としてAppleとGoogleの技術的および組織的なセキュリティに大きく依存することになります。もちろん、iOSやAndroidを使用しているため、ある程度の依存関係は存在しますが、同期されたパスキーは、この依存関係を大幅に高めます。
これは理論上の脆弱性でもありません。昨年、Retoolは、脅威の主体がこの機能を利用してシステムにアクセスした方法について論じています。Retoolは、この機能により「Googleアカウントが侵害された場合、MFAコードも侵害される」と書いています。
想像通り、ですがAppleやGoogleがホストする同期ファブリックを介して個人の所有物を含むデバイス間でクレデンシャルが同期されていたり、家族とクレデンシャルが共有されている環境下で企業アプリケーションを利用するのは管理者から見ると悪夢となりそうです。簡単に言うとコントロールをAppleやGoogleに握られている状態（依存している状態）は企業にとって必ずしも良い状態ではない、ということですね。
結局パスキーはエンタープライズで使える状態なのか？という話です。
Whether Passkeys should be used in the company cannot be answered in a general way. Every organization is different and must balance its unique security and operational priorities.
Moreover, whether to use passkeys shouldn’t be a yes/no question. The introduction of passkeys or passwordless login in general should be used to fundamentally review an organization’s entire MFA processes. What has been good for hardware OTP tokens for 15 years is probably no longer entirely true for passkeys or other MFA methods today.
RSA believes that passkeys can be deployed for enterprise use if they align with organizational strategy and if organizations think through their answers to the following questions. We’ve seen organizations use passkeys successfully using RSA® ID Plus, our comprehensive identity and access management (IAM) platform that provides a range of passwordless options.
Because we’re a security-first organization and use Secure by Design / Secure by Default principles, we prevent using synced passkeys by default. Only device-bound passkeys are available by default in RSA environments to provide the maximum level of security out-out-the-box, and without any extra work required by admins.
パスキーを企業で使用すべきかどうかは、一概に答えられるものではありません。 組織はそれぞれ異なり、独自のセキュリティと運用上の優先事項のバランスを取る必要があります。
さらに、パスキーを使用すべきかどうかは、イエス・ノーで答えられる質問ではありません。 パスキーやパスワード不要のログインを導入することは、組織のMFAプロセス全体を根本的に見直すために使用すべきです。15年間ハードウェアOTPトークンにとって有効であったことが、パスキーやその他の多要素認証方法ではもはや完全に当てはまらない可能性が高いのです。
RSAは、パスキーを企業で使用するには、組織の戦略と一致し、組織が以下の質問に対する答えを十分に検討することが必要だと考えています。RSAは、パスワード不要のさまざまなオプションを提供する包括的なアイデンティティおよびアクセス管理(IAM)プラットフォームであるRSA® ID Plusを使用して、パスキーを成功裏に使用している組織をいくつも見てきました。
当社はセキュリティを最優先する企業であり、「Secure by Design / Secure by Default」の原則を採用しているため、同期型パスキーのデフォルトでの使用は防止しています。RSA環境では、デフォルトではデバイスに紐づいたパスキーのみが利用可能であり、管理者による追加作業を必要とせずに、最大限のセキュリティをすぐに利用できます。
まぁ、この辺りはポジショントークが入ってきていますが、Yes/No問題ではない、という点は真理だと思います。結局のところパスキーの登場をきっかけに企業における認証戦略を見直すことが重要ってことです。
まぁ、最後は当然のことながら自社サービスへの誘導ですね。とは言え、企業が自問すべきことについて触れられているのでここはみなさんちゃんと考えてみましょう。
When assessing whether to introduce passkeys, organizations should ask: How are our authenticators registered? Are there processes that safely handle the ‘I lost my authenticator’ scenario? What about the classification of users, applications and data?
Passkeys are one MFA method among many. Yes, their phishing resistance is fantastic, but can users log in with it on their remote desktops?
For these reasons and many others, it’s important that your MFA system isn’t just technically up to date, but that it also supports a wide variety of MFA methods, such as QR codes, biometrics, OTP, push messages and FIDO passkeys.
It is also important that the processes around MFA are adapted to new threats. This goes far beyond the actual MFA system: Is your help desk also safe from social engineering attacks?
If passkeys make sense to you, then we want to help. Contact us to learn more or start a free, 45-day trial of ID Plus.
パスキーを導入すべきかどうかを評価する際、組織は次のような質問を自問すべきです。「当社の認証情報はどのように登録されているか?」「認証情報を紛失した」というシナリオを安全に処理するプロセスはあるか?」「ユーザー、アプリケーション、データの分類についてはどうなっているか?」
パスキーは、数ある多要素認証(MFA)の方法のひとつです。 確かにフィッシング対策としては素晴らしいですが、ユーザーはリモートデスクトップ上でこれを使ってログインできるのでしょうか?
こうした理由やその他の理由から、MFAシステムは単に技術的に最新であるだけでなく、QRコード、生体認証、OTP、プッシュ通知、FIDOパスキーなど、多様なMFA方式をサポートしていることが重要です。
また、MFAに関連するプロセスが新たな脅威に対応していることも重要です。これは実際のMFAシステムをはるかに超えるものです。ヘルプデスクもソーシャルエンジニアリング攻撃から安全であるか?
パスキーが適切だとお考えであれば、ぜひご相談ください。詳細についてはお問い合わせいただくか、ID Plusの45日間無料トライアルをお試しください。
確かにパスキーは多要素認証の方法の一つ、として捉えて認証戦略について考えることは大切ですね。
ということでベンダのブログではありますが、結構書いてあることは重要だと思います。
日本企業・組織においてもパスキーを前向きに捉えて導入するためにもしっかりとシナリオを設計して導入を進めてほしいところです。
こんにちは、富士榮です。
大学ICT推進協議会（AXIES・アクシーズ）の参加申し込みなどが始まっていますね。
https://axies.secretari.jp/conf2024/
いやぁ、奈良すぎる。ということで今年は奈良ですね。（去年は名古屋だった）
アイデンティティとの絡みで言うと、AXIESの中の認証基盤部会が毎年学術機関におけるデジタルアイデンティティについてのトレンドやあり方について発表しています。
Currently, this research area is expanding, and there is still room for improvement for all the defined categories of methods for selective disclosure. There is no clear winner and the “best” universal solution. We encourage researchers to improve on the existing methods, consider new methods or revisit older ones, and even consider methods that are quantum-resistant for the future. The focus should be on finding methods that satisfy all requirements for selective disclosure schemes and specific regulations.In the future, standardizing credentials will result in interoperable solutions and improve the development of methods for achieving selective disclosure. With this paper, our goal was to create a starting point for researchers interested in achieving selective disclosure in the digital credential world.
現在、この研究分野は拡大しており、選択的開示のための定義された方法のすべてのカテゴリーにおいて、まだ改善の余地がある。明確な勝者や「最善」の普遍的なソリューションは存在しない。研究者には、既存の方法を改善し、新しい方法を検討したり、古い方法を再検討したり、さらには将来的な量子耐性のある方法も検討することを推奨する。選択的開示スキームのすべての要件および特定の規制を満たす方法を見つけることに焦点を当てるべきである。
将来的には、クレデンシャルの標準化により相互運用可能なソリューションが実現し、選択的開示を実現するための方法の開発が改善されるでしょう。本論文の目的は、デジタルクレデンシャル世界における選択的開示の実現に関心を持つ研究者の出発点となることでした。
将来に向け、継続的な技術開発が望まれますね。
こんにちは、富士榮です。
Entra Verified IDのFace check機能の正式リリースについて先月書きましたが、アナウンス的にはEntra Suiteが正式リリースでFace check自体はPublic Previewの状態だったみたいです。
https://idmlab.eidentity.jp/2024/07/entra-verified-id.html
ということで、（こんどこそ）正式リリースになったようです。
 |
| MicrosoftのBlogより |
ということでHappy face check lifeを！
こんにちは、富士榮です。
引き続き選択的開示に関する調査論文を読んでいきます。
Selective disclosure in digital credentials: A review
https://www.sciencedirect.com/science/article/pii/S2405959524000614
今回は研究と実装の間に、、、という話です。
論文中には研究の対象となっている選択的開示技術と社会実装における各種規制などとのギャップについて記載があります。
例えばGDPRとCRPA（記載時点ではCCPA）などを鑑みると選択的情報開示の実装には以下の要件が求められると書かれています。
こんにちは、富士榮です。
毎回、IIW（Internet Identity Workshop）などのイベントと併せて開催されるOpenID Foundation Hybrid Workshopですが、次回のIIW（2024/10/29〜10/31）でも開催されます。
今回はCISCOのメンローパークのオフィスが会場です。
（前回はGoogleで開催でした。レビューはこちら）
ということでアナウンスです。
https://openid.net/registration-oidf-workshop-cisco-october-28-2024/
Thank you kindly to Cisco for hosting this hybrid workshop on Monday, October 28, 2024 12:30-3:45pm PT prior to IIW Fall 2024.
Cisco Campus
Bldg. 10 - Menlo Park
300 E Tasman Dr
San Jose, CA 95134
まだアジェンダなどは出てきていませんが、OpenID Foundationの各ワーキンググループの最新のアクティビティの確認ができるのでぜひ登録してみてください。
 |
| OpenArtに「Digital Credential, National ID」と入れたら生成された画像 |
Gartner's latest Privacy Hype Cycle has a controversial take on Zero-Knowledge Proofs; they are now obsolete.
— Nigel Smart (@SmartCryptology) August 6, 2024
I wonder what the ZK community think of this? @AnnaRRose, @OmerShlomovits, @EliBenSasson, @SuccinctJT pic.twitter.com/qhDgExNtry
幻滅期： 実験や実装で成果が出ないため、関心は薄れます。テクノロジの創造者らは再編されるか失敗します。生き残ったプロバイダーが早期採用者の満足のいくように自社製品を改善した場合に限り、投資は継続します
と定義されています。
（出典：ガートナー・ハイプ・サイクル）
つまり、キーワードだけで過剰に投資が集まる時期（過度な期待の時期）が過ぎて、より現実を見つめる時期に入ってきている、ということですね。
この時期に入った今こそ、ちゃんとPSF（Problem Solution Fit）を達成できる状態を作り、PMF（Product Market Fit）まで持っていけるように助走をつけないと本当に廃れちゃいますね・・・
こんにちは、富士榮です。
先日のMyData JapanカンファレンスではDataSignさんが提供されているOWND Walletへの入場証の発行が可能なことが現地では話題になっていました。
当日のセッションでも代表の太田さんからはオープンソースであるOWND Walletのコードを使ったVESSさんのVESS Walletも紹介され、両方のアプリをインストールした方も多いのではないでしょうか？
しかし、当日実際に両方のウォレットアプリがインストールされている状態だとうまく意図したウォレットに入場証明書が入らない、という課題が発生していました。
これはiOSを少しだけ知っている人なら推測がつくと思いますが、OWND WalletとVESS Walletが同じカスタムURLスキーム（openid-credential-offer://など）を使っていることから「後から」インストールしたアプリが優先されてしまう、というiOSの仕様によって発生します。
OWND WalletかVESS Walletか、くらいの話なら気をつければ特に問題はありませんが、今後ウォレットが乱立してきて「悪意のある」ウォレットが出てきたり、「一見ウォレットに見えない」アプリが出てきた場合に思わぬ事態を招きかねない、という問題を内包しています。
この話は以前紹介したOpenID for Verifiable Credentials関連仕様のフォーマルセキュリティ分析のレポートでも指摘された課題です。
https://idmlab.eidentity.jp/2024/01/openid-for-verifiable-credentials.html
ということで、ちょっと嫌な方法ではあるのですが、各アプリケーションがどんなカスタムURLスキームを使っているのかを調べてみます。
少し古いのとMacにアプリをインストールする必要があるので個人的にはすごく嫌だったんですが、人柱になりました。
このURLを参考にしています。
https://blog.thetheorier.com/entry/extract-url-scheme
https://www.imobie.jp/iphone-tips/extract-ipa-files-from-iphone.htm
ざっくりいうと、
をMacに入れてあげる必要があります。（さらにいうと自分のAppleアカウントでAnyTransにサインインする必要もあるのでもっと嫌です・・・）
まずはAnyTransで対象としたいアプリをダウンロードしてMacに転送します。個人的にカスタムURLスキームが被っているのを知っているのは先に触れたOWND Wallet / VESS Wallet、あとはxIDアプリとMicrosoft Authenticatorです。
こんな感じで各アプリがどんなURLスキームを登録しているか見えます。
この例だとMicrosoft AuthenticatorとxIDアプリがopenid-vcというURLスキームを重複登録していることがわかりますね。
引き続き要ウォッチですね！
こんにちは、富士榮です。
引き続き選択的開示に関する調査論文を読んでいきます。
Selective disclosure in digital credentials: A review
https://www.sciencedirect.com/science/article/pii/S2405959524000614
で、結局はどうなのよ、という話です。
ここまで、
投稿
すべてのコメント
