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