デジタル認証情報とパスキー：その連携と相違点

• 🔑 パスキー：安全なログインのため。 あなたが「誰」であるか（認証）を証明し、フィッシングと効果的に戦います。
• 📄 デジタル認証情報：検証可能な証明のため。 あなたに関する「事実」（ID、スキルなどのアテステーション）を証明し、共有する内容を自分でコントロールできます。
• 🤝 連携点： どちらも強力な暗号技術を使用し、パスワードに比べてセキュリティとユーザー体験を向上させます。
• 🎯 相違点： パスキーは主にサービスへの「アクセス」に使われます。デジタル認証情報は、あなたに関する「検証済み情報を提供」するために使われます。

デジタルの世界は急速に変化しています。この変化は、従来のパスワードや共有秘密鍵が機能しなくなり続けているだけでなく、フィッシングやAIによるディープフェイクのような攻撃がはるかに巧妙になり、見破るのが難しくなっているために起きています。これらの高度な脅威は、注意深いユーザーでさえも騙し、古い本人確認方法を信頼できないものにしてしまいます。このことは、デジタルな暗号学的証明が、誰であるかを確認する唯一の真に安全な方法であることを明確に示しています。この厳しい状況において、私たちはより安全で、ユーザーフレンドリーで、「暗号学的に検証可能」なオンラインでのやり取りの方法を緊急に必要としています。このニーズにより、すでに広く使われているパスキーと、まだ始まったばかりのデジタル認証情報という2つの重要な技術が重要になりました。これらの技術は、ますます偽造が容易になっている人間がチェックする主張に頼るのではなく、機械で検証可能な暗号学的証明を用いて真の信頼を築きます。

パスキーは、Apple、Google、Microsoftといった大手企業やFIDOアライアンスからの強力な支持のおかげで、2023年から2025年にかけて利用が大幅に増加しました。堅牢なW3C WebAuthn標準に基づき、パスキーは脆弱な共有秘密鍵からの基本的な転換です。パスワードの代わりに、公開鍵暗号方式を使用します。ここでは、ユーザーのデバイスに安全に保存された秘密鍵が、リライングパーティ（RP）からのチャレンジに署名します。これにより、ユーザーは鍵そのものを見せることなく、鍵を持っていることを証明します。

この暗号技術により、パスキーはフィッシングが非常に困難になります。これは、フィッシング攻撃が巧妙化し、時にはディープフェイクを使ってより本物らしく見せかける中で、大きな利点です。パスキーは作成された特定のウェブサイトやアプリに紐づけられているため、ユーザーが誤って偽サイトで使ってしまうことはありません。これは、このような高度な手口に脆弱な古いログイン方法では一般的な問題です。パスキーはまた、パスワードの使い回しや、データ侵害後のクレデンシャルスタッフィングの危険も防ぎます。セキュリティだけでなく、パスキーはログイン体験を大幅に向上させます。多くの場合、Face IDや指紋認証のような生体認証スキャンだけで済むため、ユーザーは長いパスワードを覚えたり入力したりする必要がありません。このセキュリティ向上と使いやすさの組み合わせが、急速な普及につながりました。

同時に、デジタルアイデンティティウォレットに保管されることが多いデジタル認証情報も、はるかに話題に上るようになりました。EUデジタルアイデンティティウォレット（EUDI Wallet）は、このトレンドの良い例です。

主に「認証」（秘密鍵を管理していることを示して「誰」であるかを証明する）のためのパスキーとは異なり、デジタル認証情報（W3C Verifiable Credentials (VCs)やISO mdocsなどの標準に基づく）は、「暗号学的に検証可能なアテステーション」（デジタル署名された主張であなたについて「何」が真実であるかを証明する）に関するものです。これらの主張を強力に検証できることは、特にディープフェイクが従来の証拠の説得力のある偽物を作成できるようになった現在、重要です。暗号学的なチェックがなければ、専門家でさえ本物を見分けるのが難しい場合があります。これにより、人々は名前、生年月日、運転免許証、学歴、職務経歴書などの検証済み情報を、暗号学的に安全で、プライバシーを尊重し（ユーザーが必要なものだけを共有できるようにする）、機械でチェックできる方法でデジタルに携帯し、提示することができます。

これら両技術の台頭は偶然ではありません。これは、業界が中央集権的でパスワードベースのアイデンティティシステムから、暗号学的信頼に基づいた、より分散化されたユーザー中心のモデルへと移行していることを示しています。パスワードはオンラインセキュリティの既知の弱点です。アイデンティティ情報を共有する古い方法は、しばしば扱いにくく、安全でなく、または過剰なデータを共有し、ユーザーのプライバシーを損ないます。パスキーは認証の弱点を直接修正します。デジタル認証情報は、属性の共有を安全かつユーザーの管理下で行うことに対応します。どちらも同様の暗号技術を使用し、プラットフォームの統合とセキュアハードウェアへの依存度が高まっており、私たちのデジタルアイデンティティシステムを大幅に改善するための共同の取り組みを示しています。

パスキーが「ログイン」を、デジタル認証情報が「属性の証明」を扱う一方で、これらは同様の暗号学的基礎を使用し、信頼できるデジタルインタラクションを確立する上で補完的な役割を果たします。これは、巧妙なフィッシングやディープフェイクのような現在の脅威が、古くて暗号学的でない本人確認方法を安全でなくしているため、私たちが本当に必要としているものです。これにより、中心的な問いが浮かび上がります：パスキーとデジタル認証情報はどのように関連し、日常的なユーザーの状況でどのように連携できるのでしょうか？

この記事では、この相乗効果を探ります。私たちは、それらの違いと類似点、それらを可能にするプロトコル、セキュアハードウェアへの共通の依存、そしてユーザーオンボーディング、ステップアップ認証付きログイン、デバイス移行などのシナリオでどのように連携できるかを検証します。また、Digital Credentials APIのような新しいブラウザ標準が、これらの世界をどのように橋渡ししようとしているかにも触れます。この記事は、これらの技術間の「相互作用」に特に焦点を当てており、すでに利用可能なDigital Credentials APIのより詳細な技術的探求を補完するものです。

パスキーとデジタル認証情報がどのように連携できるかを理解するためには、まずそれらの明確な特徴と、それらを支える技術的な層を把握することが不可欠です。

以下の表は、高レベルの比較を提供します。

この比較は、両者が信頼のために暗号技術を活用している一方で、その主な機能と典型的な使用パターンが大きく異なることを浮き彫りにしています。パスキーは頻繁で安全な認証に最適化されており、デジタル認証情報はユーザーの同意を得て検証可能な属性を提供することに優れています。

パスキーは、いくつかの主要な標準の相互作用によって実現されます。

• WebAuthn (Web Authentication): このW3C標準は、ウェブアプリケーションが認証システムと対話し、パスキーを登録（navigator.credentials.create()）および認証（navigator.credentials.get()）するために使用するJavaScript APIを定義します。これは、リライングパーティのウェブアプリケーションとユーザーのブラウザまたはオペレーティングシステムとの間の橋渡し役として機能します。WebAuthnは、W3Cの一般的なCredential Management APIを拡張したものです。

• CTAP (Client to Authenticator Protocol): FIDOアライアンスによって定義されたCTAPは、クライアント（ブラウザまたはOS）が認証システムデバイスと通信する方法を規定します。これは、デバイスに組み込まれたプラットフォーム認証システム（TPMやSecure Enclaveなどのセキュアハードウェアを使用）や、USBセキュリティキーのようなローミング認証システム、あるいは別のデバイスの認証システムとして機能する電話である可能性があります。CTAP2はFIDO2とパスキーに整合したバージョンであり、USB、NFC、Bluetooth Low Energy (BLE)などの様々なトランスポートをサポートしています。

• 高度な信頼シグナルとデバイスバインディング（同期型パスキーに関する考慮事項）： パスキーがデバイス間で同期可能（「マルチデバイスクレデンシャル」）に進化するにつれて、リライングパーティ（RP）はリスク評価のために認証中に使用された特定の物理デバイスを識別する必要が時々生じました。devicePubKeyやsupplementalPubKeys拡張機能のような初期のアイデアは、この問題を解決しようとしましたが、後に廃止されました。FIDOアライアンスの信頼シグナルワーキンググループが現在、代替案を開発しています。ここでの主な考え方は、同期型パスキーを持つ認証システムが、デバイスに紐づけられた2つ目の鍵ペアを「追加で」作成し使用できるというものです。認証中、認証システムはメインの同期キーとこの2つ目のデバイスバインドキーの両方からの署名を提供できます。これにより、RPは特定の信頼できるデバイスを認識できます。これは、メインのパスキーが多くのデバイスで同期されていても、摩擦を減らす（例：追加のチャレンジをスキップする）ことを意味し、同期型パスキーの主な利点であるデバイス間での使いやすさを損なうことはありません。これに関する最終的な標準はまだありませんが、このような機能は、高い保証を必要とするRPの主要なニーズを満たし、新しいデバイスの使用をより良く検知したり、内部の強力な顧客認証（SCA）規則を満たしたりすることを可能にします。

同様に、デジタル認証情報エコシステムは、機能するために一連のプロトコルと新しいAPIに依存しています。

• Digital Credentials API: これは、ウェブアプリケーションがユーザーのデジタルウォレットから標準化された方法でVerifiable Credentialsを要求できるように、navigator.credentials.get() APIを拡張することを目指す新しいW3Cの仕様策定の取り組みです。WebAuthnと同様の目的を果たしますが、パスキーの代わりにVCに焦点を当てています。
• OpenID for Verifiable Presentations (OpenID4VP): これは、検証者（認証情報を要求するRP）が保有者のウォレットからVCを要求する方法について、OAuth 2.0上に構築されたプロトコルを定義します。主要な要素には、presentation_definition（要求される認証情報とクレームを指定）、認可サーバーとして機能するウォレット、そしてVerifiable Presentationを検証者に戻すvp_tokenが含まれます。
• OpenID for Verifiable Credential Issuance (OpenID4VCI): OpenID4VPを補完するこの標準は、発行者が保有者のウォレットにVCを配信する方法を、再びOAuth 2.0メカニズムを使用して標準化します。これには、Credential Offers、事前認可または認可コードフロー、専用のクレデンシャルエンドポイントなどの概念が含まれます。
• ISO標準（例：ISO/IEC 18013-7, ISO/IEC 23220）： これらの国際標準は、モバイル運転免許証（mDL）やその他のタイプのモバイル文書（mdoc）にとって特に重要です。ISO 18013-5は、コアmDLデータ構造とオフライン提示（NFC、BLE）を定義し、ISO 18013-7と23220は、REST APIやOpenID4VPとの統合プロファイル（18013-7の附属書B）を含むオンライン提示メカニズムを規定しています。GoogleウォレットやAppleウォレットのようなプラットフォームは、これらのISO標準を活用しています。

目的やプロトコルは異なりますが、パスキーとデジタル認証情報は基本的な構成要素を共有しています。

• 非対称暗号： どちらも公開鍵と秘密鍵のペアに大きく依存しています。パスキーは認証時に所有を証明するために秘密鍵を使用します。デジタル認証情報は、発行者の秘密鍵を使用して認証情報に署名し、その真正性と完全性を保証します。また、保有者は自分の秘密鍵を使用して認証情報を含む提示情報に署名することがあります。
• セキュアハードウェア： 秘密鍵の保護は最重要です。両方の技術は、現代のデバイスに統合されたセキュアハードウェアコンポーネントから大きな恩恵を受けています。
  • TPM (Trusted Platform Module): ラップトップやデスクトップによく見られる専用チップで、安全な鍵生成、ストレージ、暗号操作を提供します。Windows Helloのようなプラットフォーム認証システムで一般的に使用されます。
  • Secure Enclave: Appleのハードウェアベースのキーマネージャーで、iPhone、iPad、Macのメインプロセッサから隔離されており、パスキーの秘密鍵を含む機密データを保護するために使用されます。
  • Android Keystore System / StrongBox Keymaster: Androidは、専用のセキュアプロセッサ（StrongBox Keymaster）を使用して実装されることが多いハードウェアバックのキーストアを提供し、Androidデバイス上の暗号鍵を強力に保護します。一部のパスワードマネージャーは「Strongbox」という名前を使用していますが、OSが提供する基盤となるセキュアハードウェア要素がここでの重要な実現要因です。

パスキー操作と、デジタルウォレット内の秘密鍵を保護するために、「同じ」セキュアハードウェア要素（TPM、Secure Enclave、Androidのハードウェアバックのキーストア）を使用することは、大きな相乗効果を生み出します。プラットフォームは、各機能のために別々のセキュアチップを必要としません。代わりに、単一の強力なハードウェア基盤と関連するオペレーティングシステムAPI（AndroidキーストアやAppleのSecure Enclave用のものなど）を使用して、認証クレデンシャル（パスキー）とアテステーションクレデンシャル（VC）の両方を強力に保護できます。これにより、開発が容易になり、セキュリティの一貫性が向上し、既存のプラットフォームへの投資が有効に活用されます。

さらに、ブラウザのCredential Management API（navigator.credentials）は重要な整理レイヤーです。最初にパスキーのためにWebAuthnによって拡張され、現在はVCのためにDigital Credentials APIによってさらに拡張されています。これは明確な計画を示しています：RPに異なるクレデンシャルを要求するための主要な方法を1つ提供し、ユーザーにそれらを選択するための馴染みのある方法（Androidのクレデンシャルマネージャーや内蔵ブラウザのパスワードマネージャーなど）を提供することです。これにより、CTAP、OID4VP、ISOなどの複雑な技術的詳細が隠され、開発者とユーザーにとって物事が簡単になります。

リライングパーティ（RP）の視点から、パスキーとデジタル認証情報を効果的に統合し活用する方法を理解することは、セキュリティの強化、ユーザー体験の向上、および規制要件の遵守にとって極めて重要です。このセクションでは、RPが一般的なさまざまなシナリオやエコシステムでこれらの技術をどのように展開できるかを分析します。

パスキーとデジタル認証情報の最適な統合戦略は、特定のユースケースとその関連するリスクプロファイルおよび要件によって大きく異なります。以下の表は、一般的なシナリオ間の高レベルの比較を提供します。

エコシステムシナリオの比較

凡例：

• VCの役割 🆔： 「主なインタラクション」中の役割を記述し、VCが多くのシナリオで初期のオンボーディング/KYCに使用されることを認識しています。
• デバイスバインディング？ 🔗： 標準的なパスキーのオリジンバインディングを超えた、明示的なデバイスバインディングの必要性を指し、特に同期型パスキーに関連します。
• EU EUDIウォレット義務：このシナリオは、今後のeIDAS 2規則（おそらく2020年代後半に最終実施法が施行されてから約36ヶ月後に適用される見込み）の下での要件を反映しています。

この比較は簡単な概要を提供します。以下のセクションでは、RPの統合の観点から各シナリオの詳細を掘り下げます。

• 目標： 良好なベースラインセキュリティを備えた、高速で低摩擦なアクセス。
• 想定されるフロー：
  • 主要認証： パスキーが主流になります。そのフィッシング耐性とシームレスなUX（多くの場合、生体認証/PINのみ）は、頻繁なログインシナリオでパスワードを置き換えるのに理想的です。
  • デジタル認証情報の役割： コアログインでは最小限。VCは、ログイン後の特定の操作（例：制限商品の購入時の年齢確認）、検証済み属性に基づくパーソナライゼーション（例：ロイヤルティステータス）、または初期サインアップ時の迅速なプロファイル完成のために「任意で」使用される可能性があります。
• 相互作用： パスキーがコアログインを処理し、VCは任意で属性ベースのインタラクションのために予約されます。

• 目標： 高い保証のログインと、必要に応じて検証済みの本人アサーション。
• 想定されるフロー：
  • 自己完結型の2FA/MFAとしてのパスキー： パスキーは、ログインセレモニー中にユーザー検証（PIN/生体認証）が行われる場合、本質的に二要素認証の要件を満たします。これらは以下を組み合わせます：
    • 所有： 秘密鍵の管理の証明。
    • 知識/固有性： PINまたは生体認証によるユーザー検証。これにより、パスキーログイン自体が強力でフィッシングに強いMFAメソッドとなり、多くの高保証シナリオで2FAを達成するためだけに別のセカンドステップを必要とせずに十分です。
  • 本人確認のためのステップアップ（一回限り）： デジタル認証情報による追加ステップの主な必要性は、サービスが単に再訪ユーザーを認証するだけでなく、「明示的に本人確認」する必要がある場合に生じます。この種の強力な暗号学的チェックは、ディープフェイクが視覚的または文書ベースのIDを説得力を持って偽造できる場合に不可欠です。信頼できる情報源からのデジタル暗号学的証明だけが、属性を確実に確認できます。これは次のような場合に必要になるかもしれません：
    • 初期オンボーディング中。
    • 確認済みの本人属性を必要とする特定の高リスク操作。これらの場合、RPはパスキーログイン後に、ユーザーのウォレットから特定のVerifiable Credential（例：PID、国民IDクレデンシャル）の提示を要求します。
  • 回復のための本人確認： ユーザーの本人確認が強力に検証された後（例：VC提示のステップアップ経由）、この検証済み本人確認情報は、安全なアカウント回復フローで活用される可能性があります。例えば、ユーザーがすべてのパスキー認証システムを失った場合、高保証の本人確認クレデンシャルを提示することが、アクセスを回復し新しいパスキーを登録するプロセスの一部となる可能性があります。
• 相互作用： パスキーは、認証のために堅牢で自己完結型の2FA/MFAを提供します。VCは、必要な場合に明示的な本人確認のために戦略的に使用され、この検証済み本人確認は安全なアカウント回復メカニズムもサポートできます。

• 目標： ユーザーの摩擦を最小限に抑えた、合理化された安全なチェックアウトまたは決済開始。
• 想定されるフロー：
  • 決済のための認証： パスキーは、ユーザーを決済サービスプロバイダー（PSP）アカウント（例：PayPal）に認証するため、またはマーチャントのチェックアウトフロー内で直接認証するのに理想的です。これにより、パスワードが置き換えられ、決済を開始するための迅速で安全な確認が提供されます。
  • オンボーディング/KYC： VCは、PSPまたはマーチャントとの「オンボーディング」またはアカウント設定段階で依然として重要であり、決済機能を有効にするために必要な検証済み本人確認情報（KYC/AMLチェック）を提供します。
  • 取引の摩擦に関する懸念： コアの決済承認フロー中に、別のVerifiable Credential提示ステップ（デジタルアイデンティティウォレットとの対話を必要とする）を導入すると、シームレスなパスキー確認ステップと比較して大幅な摩擦が加わります。このユーザー体験の中断は、コンバージョン率に悪影響を及ぼす可能性が高く、したがって典型的な低摩擦の決済シナリオには不向きです。
• 相互作用： パスキーは決済行為自体の認証を保護します。VCは、決済アカウントを確立するために必要な、多くの場合一度きりの本人確認/KYCを処理しますが、重要で摩擦に敏感な決済確認ステップからは除外されます。（デジタル認証情報を直接「決済手段として」使用するという複雑なトピック、異なるウォレットタイプや新しいブラウザAPIがそのような決済固有のVCをどのように有効にするか、または相互作用するかについては、近日公開予定の補完記事「デジタル認証情報と決済」で詳しく探ります。）

• 目標： レガシーな認証方法からアップグレードすることで、特にフィッシング関連の不正を大幅に削減し、安全な銀行アクセスを実現する。
• 想定されるフロー：
  • レガシーMFAの置き換え： 多くの金融機関は現在、パスワードとSMS OTPのようなフィッシング可能な第二要素の組み合わせに依存しています。パスキーは、単一のユーザー操作で本質的にフィッシングに強い強力な認証を提供する、はるかに優れた代替手段を提供します。
  • パスキーによる主要ログイン： 主要ログインにパスキーを採用すると、そのフィッシング耐性によりセキュリティが即座に向上します。パスキーの暗号学的性質は、従来の認証情報が悩まされる最も一般的な攻撃ベクトルを軽減します。
  • リスクベースのステップアップ - デバイスシグナルの慎重な検討： より高リスクの操作（例：高額送金、連絡先情報の変更）に対して、金融機関はステップアップ検証を検討するかもしれません。パスキーに関連するデバイスバインディングシグナルは選択肢の一つですが、その必要性は慎重に評価されるべきです。主要なパスキー認証自体のフィッシング耐性が、多くのリスクを大幅に軽減します。
  • 結果ベースのセキュリティと不正削減： パスキーによって達成されるフィッシングリスクの大幅な削減は、重要な要素です。認証方法の強度とフィッシング耐性に焦点を当てた結果ベースのセキュリティアプローチは、大幅な不正削減につながる可能性があります。パスキーのようなフィッシング耐性のある要素の重みは、より多くのフィッシング可能な要素を追加するよりもかなり高いです。これは、古い方法から移行する際の金融機関の戦略の中心でなければなりません。
  • オンボーディング/本人確認のためのVC： 他のシナリオと同様に、VCは堅牢な初期KYC/AML、および検証済み情報を使用して顧客の本人確認属性を安全に更新し、銀行関係の信頼できる基盤を確立するために不可欠です。
• 相互作用： パスキーは強力でフィッシングに強い主要認証方法として機能し、レガシーシステムからの不正リスクを劇的に削減します。ステップアップのためのデバイスシグナルは戦術的な選択肢です。パスキーの固有の強度は、リスクベースのセキュリティ体制を形成する上で考慮されるべきであり、追加の、よりフィッシング耐性の低い要素への過度の依存を減らす可能性があります。VCは、基盤となる本人確認の保証を提供します。

• 目標： 特定のリライングパーティ（公的機関、規制分野の大手民間企業、VLOP）によるEUデジタルアイデンティティウォレットの受け入れを義務付けるeIDAS 2規則（第5f条）に準拠し、プライバシーを保護する匿名ログインと、法的に必要な場合の高保証の本人/属性確認の両方を可能にする。
• 想定されるフロー：
  • 匿名ログイン（デフォルト）： ユーザーがログインを開始します。RPはEUDIウォレット経由で認証を要求します。ウォレットは、内蔵の「匿名キー」（デバイスの認定セキュアエレメント（WSCD）に保存された、ハードウェアにバインドされたRPスコープのWebAuthnレジデントキー）を使用してユーザーを認証します。これにより、強力でSCA準拠の認証（所有 + ユーザー検証）を提供しつつ、デフォルトでユーザーの市民IDを匿名に保ちます。
  • 本人/属性のためのステップアップ（法的に必要な場合）： RPがEUまたは国内法（例：PSD2、AML、通信登録）に基づき、本人確認または特定の属性を要求する特定の法的根拠を持つ場合に限り、第2のステップを開始します。RPは、ウォレットから必要な個人識別データ（PID）または適格属性証明（QAA）の提示（OpenID4VP経由）を要求します。ユーザーは、この識別されたデータを共有することに明示的に同意する必要があります。
  • ウォレットとRPの認証： このフローには相互認証が含まれます。RPはウォレットに対して自身を認証し（公式登録に基づく）、ウォレットはRPに対してその真正性とクレデンシャルの有効性を証明し、セキュアハードウェア（WSCD）と関連する認証インフラを活用します。
• 相互作用： EUDIウォレットは統一された認証システムとして機能します。その統合されたWebAuthnパスキー（匿名キー）が標準的なログインを処理し、強力でプライバシーを保護する認証を提供します。ウォレットのVC機能は、明示的で法的に義務付けられた本人確認または属性開示のために選択的に呼び出され、デフォルトでデータ最小化を保証します。

この進化する状況を乗り切るには、戦略的な計画が必要です。以下は、リライングパーティ（RP）のための主要な考慮事項です。

RPにとって、今日の主な行動は、認証のためのパスキー利用を有効にし、奨励することです。パスキーは標準化されており、プラットフォームで広くサポートされており、セキュリティ（フィッシング耐性）とユーザー体験（より速く、簡単なログイン）において即時かつ大きな利益をもたらします。これは、パスワードやSMS OTPのような安全でないMFA方法への依存を減らすことを意味します。また、パスワードリセットやアカウント回復からのサポートコストを削減することもできます。広範なパスキー利用を目指すことは、ユーザー認証のための現代的で安全な基盤を築きます。採用は最初は遅いかもしれませんが、事前にユーザーに利点を教え、サインアップを簡単にすることで、彼らが始めるのを助けることができます。

パスキー自体は堅牢な認証に向けて大きな一歩であり、強力な顧客認証（SCA）要件を満たすことができますが、一部の組織では、特に同期型パスキーに関して、さらに厳しい解釈や特定の懸念を持つ内部コンプライアンスフレームワークがあるかもしれません。コンプライアンス部門がさらなる保証を求めるようなシナリオに直面しているリライングパーティ（RP）にとって、パスキーの展開を補完する追加の措置が利用可能であることを知っておくと便利です。これらは、認識されているSCAのギャップを埋めたり、それらの高められた内部要件を満たすのに役立ちます。一般的な戦略の1つは、PayPalのようなサービスが採用しているアプローチである、デバイストラストシグナルを活用することです。

例えば、PayPalは、ヘルプページで説明されているように、ユーザーがデバイスを「記憶済み」としてマークすることを許可しています：

これは、ユーザーが記憶済みのデバイス（持っているもの）からパスワード（知っているもの）でログインした場合、PayPalは多くの場合、これをSCAに十分であると見なす可能性があることを意味します。しかし、彼らはまた、「アカウントが安全であることを確認するために、別の確認を求める場合があるかもしれません」とも述べています。これには、SMS経由でワンタイムパスコードを送信したり、PayPalアプリ経由で確認を促したりすることが含まれる可能性があります。

このアプローチにより、信頼できるデバイスでのユーザー体験がスムーズになり、リスクが高い場合や規制が要求する場合にはステップアップ認証のメカニズムも提供されます。RPは、主要な認証（パスキーなど）とデバイストラスト（必要であればWebAuthnの直接的なメカニズムの外で管理される可能性がある）の組み合わせがSCAコンプライアンスのギャップを埋めるのに役立つ、同様のモデルを検討できます。しかし、WebAuthnフレームワーク自体の中でデバイス固有のトラストシグナルに対するより統合され標準化されたアプローチについては、その分野での進行中の開発に注目が集まります。

より強力なデバイストラストのためのWebAuthn統合アプローチに関して、高セキュリティ環境のRPは、その歴史と将来の方向性を理解する必要があります。devicePubKeyやsupplementalPubKeysのような過去のWebAuthn拡張機能の提案は、これらのデバイス固有のトラストシグナルを提供することを目的としていました。これらは、同期型パスキーのセキュリティ上の考慮事項に対処する試みでした。同期型パスキーは、大量採用に不可欠な使いやすさを提供する一方で、デバイスバインドキーと比較して異なるリスクプロファイル（例：クラウドアカウントの回復への依存）をもたらします。このような拡張機能の背後にある考えは、RPが使用されている物理デバイスに特別にバインドされたキーからの署名をチェックすることで、追加の保証層を得られるようにすることでした。「たとえメインのパスキー自体が同期されていても」です。

これらの特定の拡張機能（devicePubKeyとsupplementalPubKeys）は廃止されましたが、同期型パスキーのためのより強力なデバイスバインディングシグナルを取得するという課題は依然として残っています。したがって、RPはこの分野での「後継ソリューション」の開発と標準化を監視する必要があります。このようなソリューションは、RPがリスクをより良く判断する（例：既知の信頼できるデバイスからのログインと新しく同期されたデバイスからのログインを区別する）のに役立ち、すべてのユーザーに利便性の低いデバイスバインドパスキーの使用を強制することなく実現できる可能性があります。この文脈は、RPに「同期型 vs デバイスバインド」という単純な選択以上の、より複雑な選択を提示します。同期型パスキー（通常はAAL2準拠）は、最も利便性が高く、採用の可能性が最も高いため、消費者向けアプリにとって不可欠です。デバイスバインドパスキー（おそらくAAL3）は、最高の保証を提供しますが、使いにくい場合があります。廃止された拡張機能の目標は、中間的な方法を見つけることでした—デバイス固有のトラストシグナルを再び追加することで、同期キーのセキュリティを向上させることです。これは、同期の利便性をすべて失うことなく、クラウド同期が侵害された場合の一部のリスクを軽減するのに役立つ可能性があります。したがって、RPはこれを行うことを目指す「後継ソリューション」を探すべきです。最善の戦略は、RPの特定のリスク許容度、ユーザーベース、および新しい標準がどれだけ成熟するかによって異なります。

デバイストラストのためのWebAuthn内の特定のメカニズムを超えて、一部のリライングパーティ（RP）—特に銀行、保険、決済サービスなどのセクター—は、デジタル認証情報（Verifiable Credentials、またはVC）を、彼らのアイデンティティおよびセキュリティ戦略における補完的、あるいは次の一歩となるコンポーネントとして評価し始めています。

この関心を高める重要な要因は、特に安全なデジタルアイデンティティウォレット内で管理される場合に、デジタル認証情報にしばしば関連付けられる堅牢なデバイスバインディングです。これらのウォレットは、ハードウェアバックのセキュリティ（Secure EnclaveやTPMなど）を活用して、認証情報とそれを提示するために使用される秘密鍵を保護できます。発行者とウォレットプロバイダーは、特定の高価値の認証情報を本質的にデバイスバインドにするポリシーを強制することもでき、高保証シナリオにとって魅力的なレベルの制御を提供します。

この強化されたデバイスバインディング機能がこれらのRPにとって魅力的な特徴である一方で、デジタル認証情報の「主な目的」（属性とクレームのアテステーション）は、パスキーのそれ（ユーザー認証）とは異なることを認識することが重要です。パスキーはユーザーが「誰」であるかを確認し、デジタル認証情報はユーザーについて「何が真実であるか」を確認します。この目的の根本的な違いにもかかわらず、ウォレットに保持されたVCの強力なセキュリティ特性は、追加の保証を重ねようとするRPにとって活発な検討領域となっています。これは自然に、これらのデジタルアイデンティティウォレットのプロバイダーと、そのような認証情報の発行、保存、提示を可能にするエコシステムへと議論を導きます。

パスキーが直接的な認証を提供する一方で、デジタル認証情報（VC）はデジタルアイデンティティウォレットを通じて管理され、リライングパーティに提示されます。これらのウォレットは、ネイティブプラットフォームソリューション（Apple Wallet、Google Walletなど）であれ、サードパーティアプリケーション（EUDI Walletなど）であれ、よりスムーズなオンライン本人確認（例：年齢確認、デジタルID属性の共有）のために、Digital Credentials APIのような新しいブラウザ標準を使用するように進化しています。

異なるウォレットタイプの詳細な仕組み、VC統合のための特定のプラットフォーム戦略（Appleのブラウザインタラクション向けのmDoc重視対AndroidのCredential Managerを介した広範なOpenID4VPサポート）、これらのウォレットが属性アテステーションをどのように促進するか、そして決済機能に関する全く別の考慮事項は複雑なトピックです。これらは、近日公開予定の補完記事「デジタル認証情報と決済」で詳しく探ります。

この記事は、認証のためのパスキーと、属性を証明するためのデジタル認証情報の一般的な役割との間の基本的な相互作用に焦点を当て続けます。

パスキーとデジタル認証情報は、主な目的は異なりますが、現代的でより安全、かつユーザー中心のデジタルアイデンティティの未来を支える2つの柱を表しています。それらがどのように関連し、互いにサポートし合えるかを理解することは、次世代のオンラインサービスを構築する上で鍵となります。

これらの技術の現状と将来の方向性に基づき、リライングパーティにとって2つの主要なアクションが際立っています。

• 今日、あらゆる場所にパスキーを展開する： 標準は成熟しており、プラットフォームのサポートは広範で、パスワードに対する利点は明確かつ実質的です。セキュリティと使いやすさを即座に向上させるために、パスキーをユーザー認証のデフォルトターゲットにしましょう。
• AML/KYCが重要な場合はウォレットのステップアップを追加する： マネーロンダリング防止（AML）/顧客確認（KYC）規制への準拠、信頼性の高い年齢確認の実施、または専門資格の確認など、より高い保証や特定の検証済み属性を必要とするプロセスには、Verifiable Credentialの提示フローを統合して、暗号学的に検証可能な属性を取得します。これは、巧妙なデジタル偽造やディープフェイクの時代にアイデンティティと主張を信頼するために不可欠です。Digital Credentials APIが利用可能な場合はそれを使用し、APIが安定するまでクロスプラットフォームでの到達を確保するために堅牢なQR/ディープリンクのフォールバックを実装します。これにより、すべてのログインに負担をかけることなく、対象を絞った高い保証が提供されます。

将来を見据えると、さらなる収束と改善が期待できます。

• クレデンシャルのポータビリティ向上： デバイス間の転送方法はおそらく改善されるでしょう。これは、パスキーのためのCTAP 2.2クロスデバイス認証を超えて、ウォレット間でVCをよりスムーズに移動させる方法を含むかもしれませんが、ここでの標準化はまだそれほど進んでいません。
• 統合されたブラウザAPI： Digital Credentials APIはおそらく成熟し、ブラウザ間でより一貫してサポートされるようになるでしょう。これにより、RPはnavigator.credentialsを通じてパスキーとVCの両方を要求するためのより標準的な方法を得ることができます。
• 統一されたユーザー体験： 最終的に、ユーザーはパスキーでの認証とVCでの属性提示の技術的な違いをあまり感じなくなるはずです。プラットフォームのクレデンシャルマネージャーとウォレットは、おそらくこれらのインタラクションを舞台裏でスムーズに管理するでしょう。それらは共有の暗号ツールとセキュアハードウェアを使用し、パスキーが使われようとVCが使われようと、ユーザーがおなじみの生体認証やPINプロンプトでリクエストを承認するだけで済むようになります。さらに、行動生体認証やその他のシグナルを使用してバックグラウンドでユーザーを常に検証する継続的受動認証（CPA）のような概念は、このシームレスなセキュリティをさらに強化し、パスキーのようなアクティブな認証システムと連携して機能する可能性があります。

この統合された未来に到達するには、標準、プラットフォームがそれらをどのようにサポートするか、そしてアプリがそれらをどのように使用するかについて、さらなる作業が必要になります。今すぐパスキーを使用し、思慮深くデジタル認証情報を追加することで、組織はパスワードレスで、ユーザーが自分のデータをよりコントロールできるデジタル世界へのこの移行に備えることができます。