PIN指定しろと怒られる。PIN指定しろと怒られる。コマンドoptions(0x07)でuvを指定する(true/false)未指定の場合falseとなるrkとは何なのか?ResidentKeyである。ついてざっくりいうと、Yubikey内の保存領域にuser情報を保存することである。userとはこれのこと。Yubikeyというデバイスの中に保存することになるので、たくさんは入れられないっぽい。今どのくらい保存されているとか、あとどのくらい保存できるとかは見れません。Verificationである。Verificationとは何なのか?「ユーザーを認証する」ということ。uv=trueで、ユーザーが本当にAuthenticatorの所有者かどうか認証する、ということ。YubikeyではPINでユーザー認証する、ということになります。したがって、uv=trueにする、ということはpinAuth(0x08)が必須、ということになります。ここまでで、rk,uvについては比較的スッキリ説明がつくのですが、ここからが仕様的に難解なところです。rkで保存したuserの取り出し方ResidentKey(rk)はauthenticatorMakeCredentialで指定します。userがYubikeyに保存されます。やって取り出すのか?authenticatorGetAssertionすると勝手に取れます。Assertionの中のpublicKeyCredentialUserEntity(0x04)がそれです。"user_DISP_gebo"}}ただし、上記のようにid,name,displayNameがすべて取れる場合と、そうでない場合があります。ここがンンン???なところ⇒詳細は後述また、rk=trueで登録した場合、authenticatorGetAssertionでallowListにクレデンシャルIDを指定する方法ではAssertionが取れなくなります。←間違いでした・・・そんなことはありません。rk=trueで登録したあと、Asssertionを取りたいのであれば、allowListは指定せずに、uv=trueとするだけでAsssertionがとれます。rkでのuser保存は同一rpで複数可能つまり、一つのrp.idに複数のuserを保存できる。保存するときのユーザーのキーはuser.id。このuser.idが違っていると別のユーザーとみなされる。複数のuserを保存する、ということですが、それぞれ別のクレデンシャル(秘密鍵)です。クレデンシャルを共有する、ということではありません。rpに対して複数のuserが登録されている場合、どのような挙動になるのか?前述のように、rk=trueで登録した場合、クレデンシャルIDを指定することはできません。まちがい~つまり、rp情報だけでAssertionをGETすることになります。間違いrpに対して複数のクレデンシャルが登録ができる、というこであれば、複数のAssertionがとれるのか?ということです。Assertionが複数個取れるのです。(0x08)コマンドというのがあるのです。id,name,displayNameがすべて取れる場合と、そうでない場合の話Assertionが1個の場合はuser.idしかとれません。h'6765626F696400'}}}これはuserが複数個あったときに画面に表示して選択させるというシナリオを想定している、と思われます。user名を表示して、どっちでログインするの?と。idだけ表示しても人間は判断できないでしょ、ってこと。バグではなく、そのように作られている、と思われます。(あるいはCTAPの仕様?)いやしかし、Assertion1個でもname,displayName返してもいいと思うけど・・・おつかれさまでした2018年末、FIDO2/WebAuthnが非常にホットですが、あえてCTAPを調べてみました。CTAP仕様はセキュリティについては徹底的に追及されています。HIDだけでなく、BLE、NFCも定義されており、幅広いシナリオ、ユースケースが想定されています。それでいて仕様は無償で全公開。YubicoもGitHubでソース全公開。ガラパゴスな日本とは大違いです。このままFIDO2が世界標準となり、各社からCTAP2のAuthenticator製品が発売され大ブレイクすることを期待します。upLoginユーザーは見つかりませんでした。