はじめに

Passkeys（パスキー）は、パスワードに代わる認証手段として急速に普及しています。公開鍵暗号方式をベースに、フィッシング耐性と利便性を両立する仕組みです。

Passkeys を支える技術仕様は大きく 2層構造 になっています。

WebAuthn（Web Authentication API）— ブラウザと Web アプリケーション間の API 仕様（W3C 策定）
CTAP（Client to Authenticator Protocol）— ブラウザ/OS と認証器間の通信プロトコル（FIDO Alliance 策定）

この2つを合わせたものが FIDO2 と呼ばれるフレームワークです。

2026年1月に WebAuthn Level 3 が W3C Candidate Recommendation となり、2025年2月には CTAP 2.2 が公開されました。この記事では、これらの最新仕様のポイントと関連 RFC を整理し、JavaScript での実装例とともに解説します。

Passkeys を支える仕様群

Passkeys のエコシステムを構成する主要仕様を整理します。

仕様	策定組織	最新バージョン	ステータス	URL
Web Authentication	W3C	Level 3	Candidate Recommendation（2026年1月）	WebAuthn Level 3
CTAP	FIDO Alliance	2.2	Proposed Standard（2025年2月）	CTAP 2.2
CBOR	IETF	RFC 8949	Internet Standard	RFC 8949
COSE Structures	IETF	RFC 9052	Internet Standard	RFC 9052
COSE Algorithms	IETF	RFC 9053	Internet Standard	RFC 9053
COSE/JOSE for WebAuthn	IETF	RFC 8812	Standards Track	RFC 8812

WebAuthn がブラウザ側の API を定義し、CTAP が認証器との通信を定義します。認証データのシリアライゼーションには CBOR（Concise Binary Object Representation）が使われ、署名・検証には COSE（CBOR Object Signing and Encryption）のアルゴリズムが使われます。

WebAuthn Level 3 の主要な変更点

WebAuthn Level 3 は、2026年1月13日に W3C Candidate Recommendation Snapshot として公開されました。Level 2 からの主要な変更点を解説します。

Conditional UI（条件付き UI）

Passkeys をブラウザのオートフィル UI に統合する仕組みです。ユーザーがフォームにフォーカスしたタイミングで、利用可能なパスキーの候補が自動的に表示されます。

仕様上は mediation: "conditional" を navigator.credentials.get() に渡すことで有効になります。これにより、専用のモーダルを表示せずにパスキー認証を開始できるため、UX が大幅に向上します。

Hybrid Transport（クロスデバイス認証）

スマートフォンを認証器として使い、PC 上のブラウザで認証を完了する仕組みです。QR コードの表示と Bluetooth による近接検証を組み合わせ、caBLE（cloud-assisted BLE）トンネルを確立します。

ユーザーは PC 画面に表示された QR コードをスマートフォンで読み取り、スマートフォンの生体認証で本人確認を行います。

Credential Backup State

クレデンシャルがクラウドにバックアップ（同期）されているかどうかを RP（Relying Party）に通知するフラグです。authenticatorData 内の BE（Backup Eligibility）と BS（Backup State）の2ビットで表現されます。

BE	BS	意味
0	0	シングルデバイスクレデンシャル（同期不可）
1	0	マルチデバイスクレデンシャル（同期可、未同期）
1	1	マルチデバイスクレデンシャル（同期済み）

RP はこのフラグを使って、同期パスキーとデバイス固定パスキーを区別したポリシーを適用できます。

Supplemental Public Keys

認証器がメインのクレデンシャルに加えて、デバイス固有の補助公開鍵を提供する拡張機能です。同期パスキーであっても、特定のデバイスからのアクセスであることを検証できます。

PRF Extension（疑似ランダム関数拡張）

認証器内部の秘密鍵を使った疑似ランダム関数（PRF）の出力を取得できる拡張機能です。この出力をデータの暗号化鍵の導出に使用することで、認証と暗号化を組み合わせたユースケースに対応できます。

Signal API

RP がクレデンシャルのライフサイクルイベントをクレデンシャルプロバイダーに通知する仕組みです。Chrome 132 以降で利用可能です。

// RP 側でクレデンシャルが削除されたことを通知
if (PublicKeyCredential.signalUnknownCredential) {
  await PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: base64urlCredentialId,
  });
}

// 表示名の更新を通知
if (PublicKeyCredential.signalCurrentUserDetails) {
  await PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: base64urlUserId,
    name: "new-username",
    displayName: "New Display Name",
  });
}

これにより、RP 側で削除されたパスキーがクレデンシャルマネージャーに残り続ける問題を解消できます。

CTAP 2.2 の主要な変更点

CTAP 2.2 は、2025年2月28日に FIDO Alliance の Proposed Standard として公開されました。

Persistent PIN/UV Auth Tokens（PPUAT）

従来の PIN/UV Auth Token はセッションごとに発行され、短時間で失効していました。CTAP 2.2 では、読み取り専用のクレデンシャル管理操作（enumerateRPs、enumerateCredentials、getCredentialMetadata）に対して、より長寿命なトークンを発行できるようになりました。

パスワードマネージャーやエンタープライズ管理ツールが、ユーザーに何度も PIN 入力を求めることなくクレデンシャル一覧を取得できるようになります。

PIN Complexity Policies

認証器レベルで PIN の複雑さを強制する仕組みです。最小文字数に加え、文字種の要件（数字・英字の混在など）をポリシーとして設定できます。

authenticatorGetInfo レスポンスに pinComplexityPolicy フィールドが追加され、クライアントは認証器の要件に合わせた PIN 入力 UI を提供できます。

Third-Party Payment Extension

PSD2（EU 決済サービス指令）などの規制に対応するため、あるオリジンで登録されたクレデンシャルを別のオリジンのコンテキストで使用できる拡張機能です。たとえば、銀行で登録したパスキーを EC サイトの決済認証に使用するケースに対応します。

authenticatorGetInfo の拡張

認証器の情報を返す authenticatorGetInfo レスポンスに、以下のフィールドが追加されました。

フィールド	説明
`uvCountSinceLastPinEntry`	最後の PIN 入力からの UV 実行回数
`attestationFormats`	サポートする Attestation 形式の一覧
`pinComplexityPolicy`	PIN 複雑さポリシー
`maxPinLength`	最大 PIN 長

関連 RFC

Passkeys の認証データは CBOR でエンコードされ、署名は COSE アルゴリズムで処理されます。関連する RFC を整理します。

RFC 8949 — CBOR

RFC 8949 は、Concise Binary Object Representation（CBOR）を定義する仕様です。JSON に似たデータモデルを持ちながら、バイナリ形式でコンパクトにエンコードできます。

WebAuthn では、attestationObject や authenticatorData のシリアライゼーションに CBOR が使われます。

RFC 9052 / RFC 9053 — COSE

RFC 9052 は COSE のデータ構造（署名・暗号化・MAC のメッセージ形式）を、RFC 9053 は初期アルゴリズムセット（ES256、EdDSA など）を定義します。

WebAuthn のクレデンシャル公開鍵は COSE Key 形式で表現され、Attestation Statement の署名検証にも COSE が使われます。

RFC 8812 — WebAuthn 向け COSE/JOSE 登録

RFC 8812 は、WebAuthn で使用される追加のアルゴリズム（RSASSA-PKCS1-v1_5 の SHA-256/384/512、secp256k1 を使った ECDSA）を COSE と JOSE のレジストリに登録する仕様です。

同期パスキーとデバイス固定パスキー

Passkeys には 同期パスキー（Synced Passkeys）と デバイス固定パスキー（Device-Bound Passkeys）の2種類があります。

	同期パスキー	デバイス固定パスキー
保存場所	クラウド（iCloud Keychain, Google Password Manager 等）	単一デバイス内
マルチデバイス	複数デバイスで利用可能	登録デバイスのみ
利便性	高い（デバイス紛失時も復旧可能）	低い（バックアップ手段が必要）
セキュリティ	クラウドプロバイダーへの信頼が必要	高い（秘密鍵がデバイス外に出ない）
WebAuthn フラグ	BE=1	BE=0

2025年7月に公開された NIST SP 800-63-4 では、同期パスキーが正式に AAL2（Authenticator Assurance Level 2）準拠として認められました。これにより、政府機関や規制産業でも同期パスキーの採用が進む見込みです。

主要なクレデンシャルプロバイダーは以下のとおりです。

Apple iCloud Keychain — Apple デバイス間で同期
Google Password Manager — Android / Chrome 間で同期
サードパーティ — 1Password、Bitwarden、Dashlane 等が対応

実装例: JavaScript での Passkeys 登録・認証

登録（Registration）

ユーザーの新しいパスキーを作成する流れです。サーバーから取得したチャレンジを使い、navigator.credentials.create() を呼び出します。

// サーバーから取得した登録オプション
const publicKeyCredentialCreationOptions = {
  challenge: new Uint8Array([/* サーバーが生成したランダムバイト列 */]),
  rp: {
    name: "Example Corp",
    id: "example.com",
  },
  user: {
    id: new Uint8Array([/* ユーザー固有のID */]),
    name: "user@example.com",
    displayName: "Example User",
  },
  pubKeyCredParams: [
    { alg: -7, type: "public-key" },   // ES256 (推奨)
    { alg: -257, type: "public-key" }, // RS256 (フォールバック)
  ],
  authenticatorSelection: {
    authenticatorAttachment: "platform",
    residentKey: "required",
    userVerification: "required",
  },
  timeout: 60000,
};

const credential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions,
});

// サーバーに送信するレスポンスデータ
const registrationResponse = {
  id: credential.id,
  rawId: credential.rawId,
  response: {
    attestationObject: credential.response.attestationObject,
    clientDataJSON: credential.response.clientDataJSON,
  },
  type: credential.type,
};

pubKeyCredParams の alg: -7 は COSE アルゴリズム ES256（ECDSA w/ SHA-256、RFC 9053 で定義）に対応します。authenticatorSelection.residentKey: "required" を指定することで、Discoverable Credential（パスキー）として登録されます。

認証（Authentication）

登録済みのパスキーで認証する流れです。

const publicKeyCredentialRequestOptions = {
  challenge: new Uint8Array([/* サーバーが生成したランダムバイト列 */]),
  rpId: "example.com",
  timeout: 60000,
  userVerification: "required",
};

const assertion = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions,
});

// サーバーに送信するレスポンスデータ
const authenticationResponse = {
  id: assertion.id,
  rawId: assertion.rawId,
  response: {
    authenticatorData: assertion.response.authenticatorData,
    clientDataJSON: assertion.response.clientDataJSON,
    signature: assertion.response.signature,
    userHandle: assertion.response.userHandle,
  },
  type: assertion.type,
};

Conditional UI（オートフィル統合）

Conditional UI を使うと、ユーザーが入力フィールドにフォーカスした際にパスキーの候補がオートフィルとして表示されます。

<input type="text" name="username" autocomplete="username webauthn">

// Conditional UI の対応チェック
const isConditionalMediationAvailable =
  await PublicKeyCredential.isConditionalMediationAvailable();

if (isConditionalMediationAvailable) {
  const assertion = await navigator.credentials.get({
    publicKey: {
      challenge: new Uint8Array([/* チャレンジ */]),
      rpId: "example.com",
    },
    mediation: "conditional", // Conditional UI を有効化
  });
}

autocomplete 属性に webauthn を含めることで、ブラウザはパスキーの候補をオートフィルに表示します。mediation: "conditional" と組み合わせて使用します。

ブラウザ・OS 対応状況

2026年4月時点の主要ブラウザの対応状況です。

機能	Chrome	Safari	Firefox	Edge
WebAuthn Level 3 基本 API	対応	対応	対応	対応
Conditional UI	対応	対応	対応	対応
Hybrid Transport	対応	対応	一部対応	対応
PRF Extension	対応	対応	未対応	対応
Signal API	対応（132+）	未対応	未対応	対応

OS	クレデンシャルプロバイダー	同期
macOS / iOS	iCloud Keychain	Apple デバイス間
Android	Google Password Manager	Google アカウント間
Windows	Windows Hello	Microsoft アカウント間

参考