セキュアな支払い確認（SPC）は、提案されているウェブ標準で、お客様がプラットフォーム認証システムを使用して、クレジット カード発行会社、銀行、その他の決済サービス プロバイダで認証できるようにします。
- macOS デバイスの Touch ID などのロック解除機能
- Windows デバイスの Windows Hello
SPC を使用すると、販売者は購入者の購入を迅速かつシームレスに認証できます。一方、発行銀行は不正行為から顧客を保護できます。
SPC には、登録と認証の 2 つのステージがあります。
- 登録: 支払い者はデバイスを信頼できる当事者（RP）にリンクします。信頼できる当事者は、クレジット カード発行会社、銀行、その他の決済サービス プロバイダなどです。
- 認証: 支払い者は、登録済みデバイスを使用して、販売者のプラットフォームから直接 RP の身元を確認してから、支払いを確定します。
不正行為防止のための認証
認証は、支払い不正行為の防止に重要な役割を果たします。ただし、この検証プロセスでは、クレジット カード番号とカード所有者名の組み合わせや、カードの裏面に記載されている追加の CVC コードなど、脆弱なメカニズムに依存していることが多いです。これらのメカニズムは、アカウントの乗っ取りやフィッシング攻撃などのデータ セキュリティ侵害によりカード情報が漏洩した場合、簡単に不正使用やなりすましの対象になります。
EMV® 3-D Secure など、不正行為防止のメカニズムが導入されています。このメカニズムでは、支払い者にカード発行会社または銀行に対する認証を求められることがあります。認証を行うには、ユーザーはユーザー名とパスワード、または支払者のスマートフォンに SMS で送信されたワンタイム パスワード（OTP）を使用してログインします。これは不正行為からお客様を保護するために有効ですが、一部の正当なお客様が支払いを完了する際に障害となる可能性があります。SPC は、認証の手間を減らし、カートの放棄を減らすことを目的としています。
一方、WebAuthn という新しい認証標準が台頭しています。
WebAuthn とは
Web Authentication（略称: WebAuthn）は、証明書利用者（RP）サーバーがパスワードではなく公開鍵暗号を使用してブラウザでユーザーを登録および認証できるようにするウェブ標準です。
RP は、セキュリティ キーなどの物理的な認証システムに依存しています。RP はセキュリティ キーをリクエストして秘密鍵 / 公開鍵ペアを生成し、公開鍵をサーバーに保存します（登録）。生成されたキーはデバイスに固有であるため、攻撃者がユーザーになりすますのを防ぐことができます。この標準は、鍵ペアがオリジンにバインドされているため、フィッシングに耐性があります。
FIDO アライアンスは、認証システムの動作を標準化しています。一部の認証システムでは、生体認証要素（指紋や顔認識など）または知識要素（PIN コードなど）によるローカル ユーザーの確認がサポートされています。多くの認証システムは、ノートパソコンやスマートフォンなどのコンピューティング デバイスに統合されています。このような認証システムはプラットフォーム認証システムと呼ばれます。WebAuthn はすべての主要なブラウザ（パソコンとモバイル）でサポートされており、認証システムは数十億台のデバイスで利用できます。ユーザーは、プラットフォームでローカルに本人確認を行うことで、登録と認証を行うことができます。
SPC は、ユーザー確認プラットフォーム認証システム（UVPA）と連携するように設計されています。
安全なお支払い確認の仕組み
安全な支払い確認（SPC）は WebAuthn 上に構築され、支払い目的に特化して設計されています。WebAuthn 認証情報は特定のドメインに登録されているため、登録されていないサイトで認証に使用することはできません。登録されていないサイトは販売者になりすましている可能性があります。この機能により、WebAuthn はフィッシング攻撃に対して効果的です。
SPC は WebAuthn の上に支払い情報レイヤを追加し、カード発行会社または銀行が一貫した支払いエクスペリエンスを提供できるようにします。支払い者がリライング パーティに認証情報を登録すると、その認証情報を使用して、さまざまな販売者のサイトで認証を行うことができます。リライング パーティは、支払い認証情報を通常の WebAuthn 認証情報として使用することもできます。
Stripe は、Chrome のオリジン トライアルの一環として、本番環境で SPC のテストを実施しました。このテストでは、Stripe のコンバージョン率が 8% 向上し、購入手続きの完了率は 3 倍になりました。結果については、W3C ウェブ決済ワーキング グループの SPC レポートをご覧ください。
ユーザーは SPC をどのように利用しますか？
SPC フロントエンドは、登録と認証の 2 つのステージで構成されています。
お客様はまず、ユーザー確認プラットフォーム認証システム（UVPA）を使用してデバイスを登録する必要があります。デバイスが登録されると、販売者のサイトで SPC が実行されるたびに、そのデバイスを使用してユーザーの認証と支払いの確認を行うことができます。
登録
SPC には、次の 2 つの方法で登録できます。
- RP ウェブサイトで直接登録します。
- 販売者のウェブサイトで間接的に登録する。
RP ウェブサイトでの登録
RP のウェブサイトでの SPC の登録は、WebAuthn の登録と変わりません。RP は、ログイン フローの一部として UVPA の登録をお客様に依頼することをおすすめします。
一般的なシナリオは次のとおりです。
- お客様は、ユーザー名、パスワード、追加の確認手順（通常はワンタイム パスワードまたは OTP）を使用して銀行のウェブサイトにログインします。
- 認証が正常に完了したら、デバイスの登録を求める権限リクエスト（UVPA）を表示します。
- 権限が付与されると、ブラウザに WebAuthn 登録ダイアログが表示されます。
- お客様が生体認証を行うことで、デバイスの登録に同意します。
- お客様はデバイスを使用してログインし、安全に支払いできるようになりました。
再認証では、ユーザーはすでにログインしていますが、同じユーザーがまだ存在することを確認するために、再度認証を求められます。この設計は、パスワード変更のリクエストや支払い時など、セキュリティ上重要なオペレーションで一般的に使用されます。WebAuthn UVPA を使用すると、再認証がパスワードを使用する場合よりもはるかに迅速かつ強力になります。
再認証用の WebAuthn 登録と認証フローを構築する方法については、初めての WebAuthn アプリを作成するをご覧ください。
支払い中の販売者のウェブサイトでの登録
お客様が支払い発行会社のウェブサイトでデバイスを登録しない場合、販売者のウェブサイトで直接登録できます。インターフェースは同じですが、ユーザーの登録は RP のコードによって開始されます。
これは、お客様が RP のウェブサイトに頻繁にアクセスしないものの、RP が認証オプションを提供したい場合に最適です。
認証（お支払いの確認）
支払い手続き中に支払い認証情報を提供する場合は、認証が必要です。
- 支払いを行うユーザーが支払い認証情報（クレジット カード情報など）を提供します。
- 販売者は、ブラウザがセキュア ペイメント確認に対応しているかどうかを確認します。
- ブラウザが SPC をサポートしている場合は、お支払い方法として SPC を指定して Payment Request API を呼び出します。それ以外の場合は、既存の認証方法にフォールバックします。
- 支払い者は取引の詳細を確認し、認証を完了します（生体認証プラットフォーム認証システムにタップするなど）。
対応プラットフォーム
安全なお支払い確認は現在、macOS と Windows の Google Chrome でサポートされています。Android、iOS、ChromeOS などの他のプラットフォームは、2022 年 5 月時点ではサポートされていません。