ritouです。
idcon の Yahoo! JAPAN の人の資料と動画を見たメモです。
2画面のログインUX
2画面か一回でやるかの話は、個人的にこだわっているスキャンの話もありますね。 Y!JはFederation(RP側)をやっていませんが、マネフォのようにパスワード認証/FederationがあるところにWebAuthnを追加する場合にどうすべきか、みたいなのは別途どこかで整理したい気がしています。
推測
Platform Authenticator だけはなく YubikeyとかのRoaming Authenticatorに対応してる場合、リセットした場合も同じことが起こりそう。 そもそもFIDOはブラウザ - 認証器と多段の処理になっているのでブラウザレイヤーでの完全なコントロールってのも難しそう。 例えば、AndroidのChrome -> Firefoxと使っていくとCookieなどではFIDO使った形跡がないけど認証器は使えるみたいな場合があることは知られている。
BackupState
複数登録させないと問題については、この値があるCredentialIdは一つでいいけど、ないやつは複数登録させたいみたいな気持ちにはなりそう。
そういえば、FIDOアライアンスが出してたこの動画にある、AndroidでcaBLE使ってログインした後にWindows側のpasskey作るみたいなUXについて、passkeyがここまでやってくれるみたいなのとこれまでのFIDO認証のプラクティス(Platform Authenticatorのある環境なら登録させちゃう)と干渉してしまう部分はありそうなので、これが更新されてどうなるのかにも注目しています。
Conditional UI 万能？
これ便利そうで注目しているものの、なんとなくですが、こいつを認証方式の分岐の主役として使うのは思うよりも難しいのかなーと思ったりします。 非対応のブラウザもあるし、Roaming Authenticatorの扱いは難しい。となるとやはりショートカットやユーザーが他の認証方式を選択した後にWebAuthnに戻ってくる経路として使う感じがいいのかなと思ったりします。
Conditional UIの課題
サービス側で削除しても、認証器側ではまだ有効っぽく振る舞われる問題に関して、ユーザー識別を先にやるパターンでは excludeCredentials が使えるかもしれません。
ベターなUX
この辺、Y!Jのような最短経路を提供しようと思うとなかなか困難なところはあると思います。
- まずはベタベタなユーザー選択式のUXを用意、とにかく詰まらないように網羅的な経路を用意
- Cookieとか前回のなんとかで推測がいけない訳ではなく、Conditional UIみたいなのはショートカットとして使っていく
- 推測失敗やユーザーの選択ミスでこの方式が使えないみたいな残念体験は一定数存在すると想定し、そこからフォールバックの経路をしっかり用意する
ぐらいでどこまで精度を上げていけるかなのかなーと言うところですね。
こう言うのをまとめてpasskey対応とか言うのをヘルプとかで説明するの大変問題 がある。
質問 : クレデンシャル共有
合法、違法問わずパスワードでも公開鍵暗号方式でも共有されている世の中なので使われそうな気はするがサービス側の扱いは変わらなそう。
質問 : 乗っ取りリスク
これはFederationでも通ってきた道だとは思うが、ポリシー判断の際はこれまでのFIDOよりは扱いが下がるかもしれない。 金融機関で使いたい時にプラットフォーム側にAAL2以上を要求、みたいな話は難しそう。
(追記ここから) ↑をちょっと補足すると
ここ雑にかきましたが、
— 👹秋田の猫🐱 (@ritou) 2022年10月16日
既存のFIDO認証がNISTのどこにあたるかを参照しつつ、デバイス単位からユーザー単位に管理が移るにあたってプラットフォーマーのAALをあげたらエエやんと言っても、そんなにうまく行かんと思う
ぐらいまで書けば良かったですね。あとで追記しておきます。
(追記ここまで)
他にもあった気がするけど一旦ここまで。
個人的にはもうちょっと Discoverable Credentialsについての細けぇ議論があったら面白いかなと思いました。displayName変えられないとかポツポツあったけど。
ではまた。
