パスキー登録APIのオプションを読み解く

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

前回に続きパスキーです。

今回はcreate()を呼び出すときのオプションを見てみたいと思います。

const cred = await navigator.credentials.create({

publicKey: options,

});

このoptionsの部分です。

参考にするブラウザAPIのドキュメントはこちらです。

https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/create

このうちのcredential typeがpublicKeyとなっているのがパスキーです。

今回実装してみた部分だけピックアップして一覧にしてあります。

パラメータ		説明	値の例
challenge		登録情報の検証を行うためのチャレンジ（ArrayBuffer）	[114, 189, 97, 231, ...]
rp	name	RP名	test site
	id	RPのドメイン名	example.jp
user	id	ユーザ識別子（ArrayBuffer）	[251, 226, 123, 109,...]
	name	ユーザ名（登録ダイアログへの表示はこちらがされる）	テストユーザ
	displayName	ユーザの表示名（処理系によってはこちらが表示されるのかも。MacとiOSのSafari/Firefox/Chromeだと表示名は出てこなかった）	テストユーザ
pubKeyCredParam		RPがサポートしている公開鍵のアルゴリズム 上から順番に利用される {alg: -7, type:"public-key"} : ES256 {alg: -257, type:"public-key"} : RS256 {alg: -8, type:"public-key"} : Ed25519	{alg: -7, type:"public-key"}, {alg: -257, type:"public-key"}, {alg: -8, type:"public-key"}
excludeCredentials	id	登録済みのauthenticatorを除外するために利用。登録済みのauthenticatorのidを指定
	type	除外するauthrnticatorのタイプ	public-key
	transports	除外するauthenticatorのI/Fタイプ internal : 内蔵 usb : USB nfc : NFC ble : Bluetooth Low Energy smart-card : Smart Card	internal
authenticatorSelection	authenticatorAttachment	プラットフォーム組み込みか、クロスプラットフォームかの選択 platform : OS組み込み（TouchIDなど） cross-platform : クロスプラットフォーム（Yubikeyなど）	platform
	requireResidentKey	認証器にユーザ情報を登録するかどうか true false	true
	userVerification	ユーザ認証を実施するかどうか required : 必須 preferred : 可能なら実施 discouraged : 実施しない	preferred

これらのパラメータを画面からある程度指定できるようにしたので、次回以降で各種認証器を使った場合にどういう動きになるのかを確認していきたいと思います。

ちなみに、Macのブラウザで内蔵Touch IDで登録した場合はこんな感じになります。

credentialId、credentialTypeは面白くないので、transportsとflagsあたりが指定するオプションと使った認証器でどう変わるのか、がポイントになりそうです。

ちなみにflagsは7bitのスイッチになっていて、それぞれこんな意味を持ちます。

Bit	意味	説明
0	User Presence (UP)	If set (i.e., to 1), the authenticator validated that the user was present through some Test of User Presence (TUP), such as touching a button on the authenticator.
1	-	-
2	User Verification (UV)	If set, the authenticator verified the actual user through a biometric, PIN, or other method.
3	Backup Eligibility (BE)	If set, the public key credential source used by the authenticator to generate an assertion is backup-eligible. This means that it can be backed up in some fashion (for example via cloud or local network sync) and as such may become present on an authenticator other than its generating authenticator. Backup-eligible credential sources are therefore also known as multi-device credentials.
4	Backup State (BS)	If set, the public key credential source is currently backed up (see Bit 3 for context).
5	-	-
6	Attested Credential Data (AT)	If set, the attested credential data will immediately follow the first 37 bytes of this authenticatorData.
7	Extension Data (ED)	If set, extension data is present. Extension data will follow attested credential data if it is present, or will immediately follow the first 37 bytes of the authenticatorData if no attested credential data is present.

先ほどの例では、「01011101」なので下位ビットからフラグをみると以下のように読めます。

• Bit0（User Presence）：あり
• Bit1（-）：0
• Bit2（User Verification）：あり
• Bit3（Backup Eligibility）：あり
• Bit4（Backup State）：あり
• Bit5（-）：0
• Bit6（Attestation Credential Data）：あり
• Bit7（Extension Data）：なし

って感じになっています。つまり、ユーザが介在していることの確認（タップなど）がされ、整体やPINでユーザ検証が行われ、クラウドで同期されているパスキーである、ということですね。