セキュアペイメント確認

1. はじめに

このセクションとそのサブセクションは規範的ではありません。

本仕様は、ウェブ上の決済フローで強力な認証方法を利用可能にするAPIを定義します。[webauthn-3]と同様の認証利点およびユーザープライバシー重視を提供しつつ、決済処理のニーズに対応する強化を目指しています。

同様に[webauthn-3]と、本仕様はユーザーが関与する2つのプロセスを定義します。1つ目は§ 3 登録（以前の「登録」）で、ユーザーとRelying Partyとの関係を構築します。2つ目は§ 4 認証 - 安全な決済確認の決済方法で、Relying Party（場合によっては仲介決済サービスプロバイダー経由）からのチャレンジに、ユーザーが特定の決済に同意するために応答します。

本仕様の目的には、チェックアウト時の認証の摩擦を減らすことがあり、その一側面は、ユーザーが1回の登録で可能な認証回数を最大化することです。つまり、Relying Partyの同意があれば、理想的にはユーザーが「一度登録」すれば、初回登録した加盟店のオリジンだけでなく、他の加盟店オリジン（および決済サービスプロバイダー経由）でも認証できるようにすることです。

そのため、安全な決済確認の重要な機能は、加盟店（または他の事業体）がRelying Partyの代理で認証セレモニーを開始できることです。Relying Partyは認証情報作成時に、この動作を許可するようオプトインする必要があります。

機能面では、本仕様はPaymentRequest APIの新しい決済方法を定義し、WebAuthn拡張を追加して[webauthn-3]を決済向けデータ構造、デバイスバインディング、および決済コンテキストでAPI呼び出しを可能にするための仮定の緩和で拡張します。

1.1. ユースケース

[webauthn-3]はウェブ全体向けの一般的な認証機能を提供しますが、本仕様で定義した決済向け拡張の価値を示す以下のユースケースがあります。

オンライン取引で暗号技術に基づく認証の一般的なユースケースが確立されていると仮定します。

1.1.1. 取引確定の暗号証拠

多くのオンライン決済システムでは、支払い手段を発行する事業体（例：銀行）が認証を通じて不正利用を抑止しようとします。[webauthn-3]や本仕様により、認証器で加盟店オリジンや取引金額・通貨など重要な決済情報を暗号署名できるようになります。銀行はRelying Partyとして、署名付与された決済情報を決済承認判断時に検証できます。

銀行がプレーンな[webauthn-3]を利用する場合、検証対象の決済情報はWebAuthnのchallengeに格納する必要があります。これにはいくつかの課題があります：

challengeフィールドの誤用となる（本来リプレイ攻撃防止用）。
仕様が存在せず、各銀行が独自の決済情報フォーマットやchallengeへのエンコード方法を考案する必要があり、導入の複雑化や断片化を招く。
規制要件でユーザーへの決済情報表示や同意記録が必要とされる場合があり、プレーンな[webauthn-3]ではchallenge利用に表示指定UXがなく対応できない。

これらの限界は次の安全な決済確認の振る舞いを動機付けています：

プレーン[webauthn-3]と同様、challengeフィールドはリプレイ攻撃防止のみに使用する。
SPCで決済情報のフォーマットを規定する。これにより汎用的な検証コードやテスト群の開発が可能となる。
SPCにより、ユーザーエージェントが決済情報を必ずユーザーに提示したこと、および悪意あるウェブサイトや信頼されたサイト上の悪意あるJavaScriptコードによる迂回ができないことを保証する。
- 決済情報はCollectedClientData辞書に格納され、JavaScriptで改ざんできません。
注: 今日、ブラウザ経由のweb決済は、TLSやiframe等ウェブ機能で十分信頼されており、現行仕様はweb決済の安全性と利便性向上を目的としています。

1.1.2. 加盟店による認証管理

加盟店はチェックアウト時のユーザー離脱を避け、特に認証摩擦の軽減を目指します。Relying Party（例：銀行）が[webauthn-3]による認証を利用する際、iframe内で実行するのが一般的です。しかし加盟店は、Relying Partyによる認証結果の検証は維持しつつ、認証体験の管理を望んでいます。

この制限を踏まえ、安全な決済確認では次の振る舞いを導入します：

SPCではRelying Party以外の事業体もRelying Partyの代理として認証情報を利用可能。Relying Partyはその認証結果を検証できます。

この機能の追加的な利点として、Relying Partyは独自の認証フロント体験を構築せずともよくなり、支払いサービスプロバイダーが加盟店のために体験構築を担う見込みです。

注: 認証体験をRelying Partyが提供したい場合、iframe経由でSPCから依然として可能です。

1.1.3. デバイスバインディングの暗号証拠

決済業界では、デバイス所有の証跡が第2要素として重要な役割を持ちます。WebAuthnでは、1つの認証情報が複数デバイスで利用可能な同期パスキーを許容しています（Web Authentication § 1.2.1 Consumer with Multi-Device Credentials）。同期はログイン用途のユーザー体験向上に役立ちますが、同期パスキーのみでは一部規制環境で求められるデバイス所有要件を満たさない懸念があります。

この懸念に対応するため、ユーザーエージェントがユーザーによって作成し、秘密鍵が1台のデバイスにのみ存在（使用）する補助的な公開・秘密鍵ペアの導入を検討します。この鍵とSPCにおけるその利用をブラウザバウンドキーと呼びます。

1.2. API利用シナリオ例

このセクションでは、安全な決済確認のシナリオと本APIの利用サンプルコード例を紹介します。なお、これらは利用例であり、API活用範囲を制限するものではありません。

1.2.1. チェックアウト時の登録

これは初回フローで、新規認証情報が発行銀行によって加盟店のチェックアウト時に作成・保存されます。

ユーザーはmerchant.exampleにアクセスし、購入商品を選択した後、チェックアウトフローに進みます。支払い手段情報を入力し、支払い意思（例: 「支払う」ボタン押下）を示します。
加盟店は支払い手段発行銀行と帯域外通信（例：他のプロトコル）でやり取りし、銀行はユーザーの認証を要求し、加盟店に銀行制御のURLをiframeで開くよう提供します。
加盟店はbank.exampleへのiframeをallow属性"publickey-credentials-create"付きで開きます。
銀行iframe内で、銀行は従来方式（例: SMS・OTP）でユーザー本人性を確認後、SPC認証への登録をユーザーに勧めます。
ユーザーは銀行UXの「登録」ボタンなどで同意し、銀行はiframe内で下記例のコードを実行します。
ユーザーはWebAuthn登録フローを経て、新規認証情報を銀行へ返送。銀行はその認証情報を自サーバ側DBにユーザー・支払い手段に紐付け保存します。
認証終了後、銀行iframeは閉じ、加盟店はユーザーのチェックアウト処理を完了します。

この方法でユーザー登録するサンプルコード：

if (!window.PublicKeyCredential) { /* クライアント非対応。エラー処理。 */ }

const publicKey = {
  // challengeは銀行サーバーが生成しiframeに送る必要あり。
  challenge: new Uint8Array([21,31,105 /* サーバーが生成した他の29バイト乱数 */]),

  // Relying Party：
  rp: {
    name: "Fancy Bank",
  },

  // User：
  user: {
    // WebAuthn部分。SPCには必須ではないが銀行サーバーは今後取引でユーザー識別に使うことがある。
    // 同じユーザーで値が不整合だと複数認証情報作成＝選択UX摩擦の原因。
    id: Uint8Array.from(window.atob("MIIBkzCCATigAwIBAjCCAZMwggE4oAMCAQIwggGTMII="), c=>c.charCodeAt(0)),
    name: "jane.doe@email.example",
    displayName: "Jane Doe",
  },

  // この例ではRPはES256またはRS256認証情報を受け入れ、ES256を優先。
  pubKeyCredParams: [
    {
      type: "public-key",
      alg: -7 // "ES256"
    },
    {
      type: "public-key",
      alg: -257 // "RS256"
    }
  ],

  authenticatorSelection: {
    userVerification: "required",
    residentKey: "required",
    authenticatorAttachment: "platform",
  },

  timeout: 360000,  // 6分間

  // SPC認証情報であることを示す。現状これが必要で、SPC関係であることをブラウザが認識する。他、クロスオリジンiframeで認証情報作成対応可。例で必須。
  //
  // 将来仕様で本拡張不要となる可能性あり。
  extensions: {
    "payment": {
      isPayment: true,
      // 許可アルゴリズムリスト（任意）。未指定・空時はpubKeyCredparamsのデフォルト（ES256, RS256）。この例はRS256優先、両方許可。
      browserBoundPubKeyCredParams: [
        {
          type: "public-key",
          alg: -257 // "RS256"
        },
        {
          type: "public-key",
          alg: -7 // "ES256"
        }
      ]
    }
  }
};

// 注意：この呼び出しで認証器がUI表示を行う。
navigator.credentials.create({ publicKey })
  .then(function (newCredentialInfo) {
    // 新しい認証情報をサーバーへ送信し、検証・登録する。
  }).catch(function (err) {
    // 認証器未対応/同意拒否。適切に対処。
  });

1.2.2. 加盟店サイトでの認証

これは、すでに認証情報が登録されているユーザーが取引を行う際に、発行銀行と加盟店が安全な決済確認（SPC）を利用する場合のフローです。

ユーザーはmerchant.exampleにアクセスし、商品を選択してチェックアウトフローに進みます。支払い手段情報を入力し、支払い意思（例：「支払う」ボタン押下）を示します。
加盟店は支払い手段の発行銀行と帯域外通信（例：他のプロトコル）でやり取りします。発行銀行はユーザーの認証を要求し、同時に加盟店へSPC対応を伝え、API利用に必要な情報（チャレンジや当該ユーザー・支払い手段に関連付けられた認証情報ID群等）を提供します。
加盟店は以下のサンプルコードを実行します。
ユーザーはSPC UXで表示される決済情報に同意し、続けてWebAuthn認証セレモニーを実施します。署名済み暗号文が加盟店に返送されます（AuthenticationExtensionsPaymentOutputsでブラウザバウンドキーの出力も含まれる）。
加盟店は署名済み暗号文を発行銀行へ帯域外で送付します。発行銀行は暗号文を検証し、ユーザーが有効であること、どんな決済情報を表示したか、取引へ同意したかを把握します。発行銀行は取引を承認し、加盟店はユーザーのチェックアウト処理を終えます。発行銀行はブラウザバウンドキーの公開鍵、 browserBoundPublicKeyを保存します。

ユーザー認証用サンプルコードは以下です。コードはasync/await構文で、Promiseの扱いが読みやすくなっています。

/* securePaymentConfirmationAvailability はブラウザがSPC対応か示すが、現デバイスに認証情報があるかは示さない */
const spcAvailable =
  PaymentRequest &&
  PaymentRequest.securePaymentConfirmationAvailability &&
  (await PaymentRequest.securePaymentConfirmationAvailability()) === 'available';
if (!spcAvailable) {
  /* ブラウザがSPC非対応の場合は、加盟店は従来フローへフォールバックする */
}

const request = new PaymentRequest([{
  supportedMethods: "secure-payment-confirmation",
  data: {
    // 銀行から取得した認証情報IDリスト
    credentialIds,

    rpId: "fancybank.example",

    // challengeも銀行から取得
    challenge: new Uint8Array([21,31,105 /* 銀行が生成した他29バイト乱数 */]),

    instrument: {
      displayName: "FancyBank Platinum Card",
      details: "****1234 | 01/29",
      icon: "https://fancybank.example/card-art.png",
    },

    payeeName: "Merchant Shop",

    payeeOrigin: "https://merchant.example",

    paymentEntitiesLogos: [
      {
        url: "https://fancybank.example/logo.png",
        label: "Fancy Bank",
      },
      {
        url: "https://securenetwork.example/logo.png",
        label: "Secure Network",
      },
    ],

    // 呼び出し側が希望するローカライズ体験
    locale: ["en"],

    timeout: 360000,  // 6分

    // 許可アルゴリズムリスト。デフォルトはES256, RS256。例ではES256優先・両方許容。
    // ブラウザバウンドキーが既に存在する場合は作成されず、このリストは新規作成時のみ利用。
    browserBoundPubKeyCredParams: [
      {
        type: "public-key",
        alg: -7 // "ES256"
      },
      {
        type: "public-key",
        alg: -257 // "RS256"
      }
    ]
  }], {
    total: {
      label: "合計",
      amount: {
        currency: "USD",
        value: "5.00",
      },
    },
  });

try {
  const response = await request.show();
  await response.complete('success');

  // response.dataはPublicKeyCredential型で、発行銀行が検証するための取引データを含むclientDataJSONを持つ。

  /* response.dataを発行銀行へ送って検証する */
} catch (err) {
  /* SPC利用不可なら従来フローへフォールバック */
}

2. 用語

SPC 認証情報

本仕様で定義される振る舞いで利用可能なWebAuthn認証情報。

本仕様は、SPC認証情報が他の認証フロー（例：ログイン）においてRelying Partyにどのように使用・未使用されるかの制限意図はありません。

注: 現仕様では、Relying Partyが認証情報をファーストパーティまたはサードパーティの文脈で使用するため明示的にオプトインする必要があります。今後はすべてのWebAuthn認証情報がファーストパーティ文脈（例：Relying Partyドメイン）でSPC利用可能となり、オプトイン要件はサードパーティ利用時のみとなる方向です。

サードパーティ対応SPC認証情報

SPC認証情報のうち、Relying Partyが認証情報作成時に明示的にオプトインしたことで、Relying Party以外が安全な決済確認認証に利用できるもの。

SPC認証情報がサードパーティ対応かサイレント判定する手順

ユーザーエージェントがRelying Party Identifierおよび認証情報IDを与えられたときに、当該認証情報IDで表現される認証情報がサードパーティ対応SPC認証情報かどうか、ユーザー操作なしに（サイレントに）判定する未定義処理。

注: WebAuthn issue 1667参照。

認証情報が現デバイスで利用可能かサイレント判定する手順

ユーザーエージェントがRelying Party Identifierおよび認証情報IDを与えられたときに、当該認証情報IDで表現される認証情報が現デバイスで利用可能（すなわちWebAuthn Get 呼び出しで成功利用し得る）か、ユーザー操作なしに（サイレントに）判定する未定義処理。

これによりユーザーエージェントは、取引UXをユーザーへ条件付き表示することができます（＝成功見込みがある場合のみ提示）。

注: このプロパティ実現にはSPC認証情報が発見可能認証情報である必要があり、現仕様ではそれを要件として明記しています。

注: このプロパティはWebAuthn Conditional UI Proposalが要件とするものに非常に類似しており、両者とSPCが共通の基盤APIでサポート可能になる見込みです。

ブラウザバウンドキー

WebAuthn認証情報に加え、取引詳細にも署名できるユーザーエージェントが単一デバイスに紐付けた公開・秘密鍵ペア。

鍵ペア

鍵ペアは、構造体であり、公開鍵と秘密鍵で構成され、実装定義型です。

注: 公開鍵・秘密鍵は暗号アルゴリズムごとのパラメータで、該当するのはIANA COSE Algorithmsレジストリ [IANA-COSE-ALGS-REG]にある暗号アルゴリズムです。

注: 公開鍵は登録時に CollectedClientAdditionalPaymentRegistrationData.browserBoundPublicKey で、決済認証時には CollectedClientAdditionalPaymentData.browserBoundPublicKey で返されます。

注: 秘密鍵は BrowserBoundSignature.signature で署名作成に使われます。ユーザーエージェントは秘密鍵を輸出せず、デバイスのセキュア・エレメントに保管する場合があります。

3. 登録

ユーザーを安全な決済確認（SPC）に登録するには、Relying Partyは navigator.credentials.create() を payment WebAuthn拡張を指定して呼び出すべきです。

テスト

注: 本仕様では、ブラウザがSPC認証情報IDをキャッシュできるようWebAuthn Conditional UI未対応時に拡張機能を定義しています。将来WebAuthnでこの機能が導入されれば、SPCから拡張要件を削除する可能性があります。SPC認証情報（拡張付き）はその他は完全なWebAuthn認証情報です。

注: 登録時、Web Authenticationでは両方 name と displayName が必須ですが、userメンバーの定義により、その後の認証時に両方を表示する必要はありません。2023年10月時点では name の方が一貫して表示されます。開発者は各実装の動向に注意してください。

4. 認証 - セキュアペイメント確認決済方式

セキュアペイメント確認を通じて決済を認証するために、本仕様は以下を定義します：

決済ハンドラー、すなわちセキュアペイメント確認決済ハンドラー、与えられた決済の認証要求を処理します。
本決済ハンドラーのための標準化済み決済方式識別子である "secure-payment-confirmation"。

セキュアペイメント確認決済ハンドラーはユーザーと取引内容を確認した後、認証セレモニーを行い、ユーザーの認証とセレモニーを表す署名付きblobを作成します。

概念的には、セキュアペイメント確認の認証は[webauthn-3]と似ていますが、主要な転換点があります。セキュアペイメント確認は、第三者（例：加盟店）がRelying Partyの代理で認証セレモニーを呼び出し、Relying Partyから他のチャネルで取得した認証情報を渡すことを許可します。§ 1.1.2 加盟店による認証管理参照。

4.1. [payment-method-id]への登録

標準化済み決済方式のレジストリに次を追加します（[payment-method-id]）：

"secure-payment-confirmation": Secure Payment Confirmation仕様。

4.2. Payment Requestコンストラクタの変更

PaymentRequestオブジェクトのコンストラクタの手順で、新たなステップを4.3の後に追加：

決済方式の処理：[サブステップ1-3省略]
1. seenPMIsに"secure-payment-confirmation"が含まれ、かつseenPMIsのサイズが1を超える場合、RangeErrorをthrowする。

4.3. ユーザーアクティベーション要件の変更

PaymentRequest.show() メソッドの手順で、ステップ２と３を修正：

関連グローバルオブジェクトがrequest のもので、一時的アクティベーション（transient activation）がない場合、ユーザーエージェントは次を実施可能：
1. 拒否されたPromiseを返すが、その理由は"SecurityError" DOMException。
そうでなければ、ユーザーアクティベーションの消費を関連グローバルオブジェクトで行う。

注: これにより、ユーザーエージェントはユーザーアクティベーション不要となり、例えばリダイレクト認証フローでリダイレクト時点にアクティベーションがなくても対応できる。セキュリティ面は§ 11.4 ユーザーアクティベーション要件の欠如参照。

4.4. `SecurePaymentConfirmationRequest` 辞書型

dictionary SecurePaymentConfirmationRequest {
    required BufferSource challenge;
    required USVString rpId;
    required sequence<BufferSource> credentialIds;
    required PaymentCredentialInstrument instrument;
    unsigned long timeout;
    USVString payeeName;
    USVString payeeOrigin;
    sequence<PaymentEntityLogo> paymentEntitiesLogos;
    AuthenticationExtensionsClientInputs extensions;
    sequence<PublicKeyCredentialParameters> browserBoundPubKeyCredParams;
    sequence<USVString> locale;
    boolean showOptOut;
};

SecurePaymentConfirmationRequest 辞書型は以下のメンバーを持ちます：

challenge

リプレイ攻撃防止のため、Relying Partyがサーバ側で生成する乱数チャレンジ。

rpId

認証情報のRelying Party識別子。

credentialIds

与えられた支払い手段の認証情報IDリスト。

instrument

登録画面表示や取引詳細署名時に利用する手段の名称とアイコンの説明。

timeout

取引詳細署名要求のタイムアウトまでのミリ秒数。最大1時間。デフォルト値・許可範囲はユーザーエージェントが決定。Web Authenticationは追加タイムアウト指針あり。

payeeName

本SPC呼び出し対象の受取人（加盟店等）の表示名。任意。payeeOriginと併用・代用可能。

payeeOrigin

本SPC呼び出し対象受取人（加盟店等）のオリジン。任意。payeeNameと併用・代用可能。

paymentEntitiesLogos

本SPC呼び出しで支払いを仲介する事業体ロゴの任意リスト（表示優先度降順）。ユーザーエージェントは一部またはすべてのロゴを必須表示ではない。§ 4.9 支払い可能か確認手順参照。

注: ロゴ表示方法は仕様で厳密規定せず、ユーザーエージェントの裁量に委ねます。ロゴ順序は重要なため、開発者は表示結果で順番調整可能。

extensions

渡す認証情報に利用する任意のWebAuthn拡張。呼び出し元は payment拡張指定不要、自動追加される。

browserBoundPubKeyCredParams

ブラウザバウンドキー用暗号アルゴリズム種類の許可リスト。

注: このメンバーはブラウザバウンドキーを新規作成時のみ利用されます。

locale

言語タグ（[BCP47]参照）優先度降順リスト（任意）。ウェブサイトの言語ロケール優先リスト language priority list [RFC4647]。ユーザーエージェントはこれをもとに言語ネゴシエーションや書式化に利用可能。

showOptOut

取引確認UXでユーザーにオプトアウト機会を与えるかどうか。任意。デフォルトはfalse。

4.5. 決済方式の追加データ型

本決済方式の追加データ型は SecurePaymentConfirmationRequestです。

4.6. セキュアペイメント確認の利用可能性判定API

PaymentRequest に静的APIが追加され、開発者がセキュアペイメント確認利用可否を簡易判定できるようになります。securePaymentConfirmationAvailability() メソッドはenumのメンバーを返し、セキュアペイメント確認が利用可能か、不可能な場合はその理由を示します。enum出力を用いることで、開発者はユーザーへ認証オプション案内で適切な誘導・通知がしやすくなります。

enum SecurePaymentConfirmationAvailability {
  "available",
  "unavailable-unknown-reason",
  "unavailable-feature-not-enabled",
  "unavailable-no-permission-policy",
  "unavailable-no-user-verifying-platform-authenticator",
};

partial interface PaymentRequest {
    static Promise<SecurePaymentConfirmationAvailability> securePaymentConfirmationAvailability();
};

SecurePaymentConfirmationAvailability enumは以下のメンバーを持ちます：

available

ユーザーエージェントが呼び出し元フレーム内でセキュアペイメント確認API利用可と判断したことを示す。

注: この結果は、特定SPC認証情報が現時点で利用可能か否かは示しません。

unavailable-unknown-reason

呼び出し元フレームでセキュアペイメント確認API利用不可（理由不明）。ユーザーエージェントはより具体的な理由よりも、本結果を常に返すことがある（ユーザープライバシー保護のため）。

unavailable-feature-not-enabled

呼び出し元フレームでセキュアペイメント確認API利用不可（機能未有効）。

unavailable-no-permission-policy

呼び出し元フレームでセキュアペイメント確認API利用不可（"payment"パーミッションポリシー未付与）。

unavailable-no-user-verifying-platform-authenticator

呼び出し元フレームでセキュアペイメント確認API利用不可（ユーザー認証可能プラットフォーム認証器未利用可能）。

注: この情報はisUserVerifyingPlatformAuthenticatorAvailable でも取得可能だが、開発者利便性のため本APIにも含む。

securePaymentConfirmationAvailability() を与えられたDocument documentで呼び出した場合、ユーザーエージェントは以下の手順を実施する。必要に応じてユーザープライバシー保護やユーザーエージェント固有理由で "unavailable-unknown-reason" を返しても良い。

ユーザーエージェントがセキュアペイメント確認非対応、または対応だがユーザーエージェント固有の仕組みで機能無効の場合、 "unavailable-feature-not-enabled" を返す。
documentで"payment"パーミッションポリシーが未有効なら、 "unavailable-no-permission-policy" を返す。
ユーザー認証可能プラットフォーム認証器がない場合、 "unavailable-no-user-verifying-platform-authenticator" を返す。
他にセキュアペイメント確認機能が稼働しない理由あれば、 "unavailable-unknown-reason"を返す。
"available"を返す。

このAPIは、SPCフロー開始前に下記のような可否判定チェックを行うのに利用できます：

const spcAvailable =
    PaymentRequest &&
    PaymentRequest.securePaymentConfirmationAvailability &&
    await PaymentRequest.securePaymentConfirmationAvailability() === 'available';

注: SPC機能検出には、staticなsecurePaymentConfirmationAvailability を推奨し、すでに構築済みPaymentRequestオブジェクトのcanMakePayment は利用すべきではありません。

注: 本APIのプライバシー考慮は§ 12.5 securePaymentConfirmationAvailabilityによるフィンガープリンティング参照。

4.7. Secure Payment Confirmation 機能の利用可能性

Secure Payment Confirmation の機能の利用可能性を開発者が判定できるようにするため、PaymentRequest に静的 API が追加される。このメソッド getSecurePaymentConfirmationCapabilities() は、機能キーから Boolean 値へのレコードを返す。

partial interface PaymentRequest {
    static Promise<SecurePaymentConfirmationCapabilities> getSecurePaymentConfirmationCapabilities();
};

typedef record<DOMString, boolean> SecurePaymentConfirmationCapabilities;

SecurePaymentConfirmationCapabilities の中のキーは、辞書式昇順にソートされていなければならない (MUST)。キーの集合には、SecurePaymentConfirmationCapability の列挙値の集合が含まれているべきである (SHOULD)。ただしユーザーエージェントは、必要と判断したキーを省略してもよい (MAY)。詳細は § 12.6 getSecurePaymentConfirmationCapabilities によるフィンガープリントを参照。

ある機能に対する値が true の場合、その機能は、このユーザーエージェントの Secure Payment Confirmation 実装において現在サポートされていることが分かっている。

ある機能に対する値が false の場合、その機能は、このユーザーエージェントの Secure Payment Confirmation 実装において現在サポートされていないことが分かっている。

ある機能がキーとして存在しない場合、その機能のサポート状況は、このユーザーエージェントの Secure Payment Confirmation 実装において不明である。

この API により、開発者は Secure Payment Confirmation フローを開始するかどうか判断する際に、特定の機能がサポートされているかを次のように確認できる。

if (PaymentRequest && PaymentRequest.getSecurePaymentConfirmationCapabilities) {
    const capabilities = await PaymentRequest.getSecurePaymentConfirmationCapabilities();
    if (capabilities.browserBoundKeyHardware) {
        // When the SPC API is used, hardware backed BBKs will be available.
    }
}

Note: この API に関するプライバシー上の考慮事項については、 § 12.6 getSecurePaymentConfirmationCapabilities によるフィンガープリントを参照のこと。

4.7.1. `SecurePaymentConfirmationCapability` 列挙型

enum SecurePaymentConfirmationCapability {
  "browserBoundKeyHardware",
};

この列挙型は、開発者が評価してユーザーに特定のワークフローや体験を提供できる、限定された Secure Payment Confirmation 機能の集合を定義する。

browserBoundKeyHardware

Secure Payment Confirmation API が、デバイス上のハードウェアセキュアエレメントに保存されたブラウザバウンドキーを利用できることを示す。

詳細は § 6 Browser Bound Key Store を参照。

4.8. 支払方法データを検証する手順

この支払方法に対する、入力 PaymentRequest request と SecurePaymentConfirmationRequest data の支払方法データを検証する手順は次のとおりである。

Tests

もし data["credentialIds"] が空であれば、 RangeError を投げる。
data["credentialIds"] 内の各 id について：
1. もし id が空であれば、 RangeError を投げる。
もし data["challenge"] が null または空であれば、 TypeError を投げる。
もし data["instrument"]["displayName"] が空であれば、 TypeError を投げる。
もし data["instrument"]["icon"] が空であれば、 TypeError を投げる。
data["instrument"]["icon"] について URL パーサーを実行する。これが失敗を返したなら、 TypeError を投げる。
もし data["instrument"]["details"] が存在していて空であるなら、 TypeError を投げる。
もし data["rpId"] が有効なドメインでないなら、 TypeError を投げる。
もし data["payeeName"] と data["payeeOrigin"] の両方が省略されているなら、 TypeError を投げる。
もし data["payeeName"] または data["payeeOrigin"] のいずれかが存在していて空であるなら、 TypeError を投げる。
もし data["payeeOrigin"] が存在するなら：
1. parsedURL を、data["payeeOrigin"] に対して URL パーサーを実行した結果とする。
2. もし parsedURL が failure であれば、 TypeError を投げる。
3. もし parsedURL のscheme が "https" でなければ、 TypeError を投げる。
もし data["paymentEntitiesLogos"] が存在しかつ空でないなら：
1. data["paymentEntitiesLogos"] 内の各 logo について：
  1. もし logo["url"] が空であれば、 TypeError を投げる。
  2. logo["url"] について URL パーサーを実行する。これが失敗を返したら、 TypeError を投げる。
  3. もし logo["label"] が空であれば、 TypeError を投げる。
もし data["locale"] が存在しかつ空でないなら
1. data["locale"] 内の各 tag について：
  1. もし tag が、正しい形式の [BCP47] 言語タグでなければ、 TypeError を投げる。
NOTE: locale は、特定の入力メンバーに結び付いた言語や方向のメタデータとは異なり、特定の文字列値についての主張ではなく、呼び出し元が要求するローカライズされた体験を表す。さらなる議論については § 14 Internationalization Considerations を参照。

4.9. 支払いが可能かどうかを確認する手順

この支払方法に対する、入力 SecurePaymentConfirmationRequest data に関する支払いが可能かどうかを確認する手順は次のとおりである。

Tests

もし data["payeeOrigin"] が存在するなら：
1. parsedURL を、data["payeeOrigin"] に対して URL パーサーを実行した結果とする。
2. parsedURL が failure ではないことをアサートする。
3. parsedURL のscheme が "https" であることをアサートする。
NOTE: これらの前提条件は、以前に支払方法データを検証する手順の中でチェックされている。
1. data["payeeOrigin"] を、parsedURL のorigin のシリアライズ結果に設定する。
icon について、«["src" → data["instrument"]["icon"]]» を image に渡して、画像リソースを取得する。これが失敗した場合：
1. もし data["instrument"]["iconMustBeShown"] が true なら、false を返す。
2. それ以外の場合、data["instrument"]["icon"] を空文字列に設定する。
  
  Note: これにより、出力の instrument の icon 文字列が空であるため、RP は指定されたアイコンが表示されなかったことを認識できる。
Note: 資格情報が一致するかどうかにかかわらず、アイコンの画像リソースは取得されなければならない。これは資格情報 ID の存在をプローブする試みを防ぐためである。
オプションとして、ユーザーエージェントは data["paymentEntitiesLogos"] から、リストの末尾から先頭へ向かう形でエントリを削除してもよい。

Note: これにより、ユーザーエージェントは表示するロゴの数を制御できる一方で、ロゴが呼び出し元にとっての表示優先度の降順であるという意味付けは保たれる。
data["paymentEntitiesLogos"] 内の各 logo について：
1. logo について、«["src" → logo["url"]]» を image に渡して画像リソースを取得し、結果をデコードする。
2. 取得またはデコードのいずれかが失敗した場合、logo["url"] を空文字列に設定する。
  
  Note: これにより、出力の paymentEntitiesLogos シーケンスの該当ロゴについて url 文字列が空になるため、RP は指定されたロゴが表示されなかったことを認識できる。
Note: 資格情報が一致するかどうかにかかわらず、ロゴの画像リソースは取得されなければならない。これは資格情報 ID の存在をプローブする試みを防ぐためである。
data["credentialIds"] 内の各 id について：
1. data["rpId"] と id を引数として、現在のデバイスで利用可能な資格情報かをサイレントに判定する手順を実行する。結果が false なら、data["credentialIds"] から id を削除する。
2. もし data["rpId"] が、request の関連設定オブジェクトのオリジンではないなら、 data["rpId"] と id を引数として、 SPC 資格情報がサードパーティ利用可能かをサイレントに判定する手順を実行する。結果が false なら、data["credentialIds"] から id を削除する。
true を返す。

4.10. 取引確認 UX の表示

PaymentRequest.show() が呼び出され、（そのアルゴリズムの手順 19–24 において）Secure Payment Confirmation 支払ハンドラーが選択されたとき、ユーザーエージェントは、先に進むかどうか、どのように進みたいかをユーザーが選択できるユーザーインターフェースを提示しなければならない (MUST)。

4.10.1. ユーザーに提示される情報

ユーザーエージェントの実装選択を制限しないように、この仕様は特定のユーザーインターフェースの表示を要求しない。しかし、Relying Party が CollectedClientPaymentData に含まれる情報を信頼できるようにするため、ユーザーエ��ジェントは、以下の内容がユーザーに伝えられ、かつ認証に対するユーザーの同意が収集されることを保証しなければならない (MUST)。

存在する場合、payeeName。
存在する場合、payeeOrigin。
total、すなわち取引の currency と value。
instrument の詳細、すなわち支払インストゥルメントの displayName、 details、および icon。入力の icon から画像リソースを取得またはデコードできなかった場合、ユーザーエージェントはアイコンを表示しないか、汎用的な支払インストゥルメントアイコンを代わりに表示してもよい。

NOTE: 指定されたアイコンを取得またはデコードできなかった場合、 iconMustBeShown はここでは false でなければならない。そうでなければ、支払いが可能かどうかを確認する手順は以前に失敗しているはずである。
空でない場合、 paymentEntitiesLogos のエントリ中の url によって表現されるロゴ。
- ユーザーエージェントは、各 PaymentEntityLogo の label を表示する必要はないが、アクセシビリティのために使用するべきである (SHOULD)。これらの label は、 CollectedClientAdditionalPaymentData に含まれ、署名対象にもなり続ける。

ユーザーエージェントは、存在する場合、 locale の情報を利用して、Web サイトのものと一致する言語およびロケールに基づく書式でローカライズされた UX を表示してもよい。

もし showOptOut が true なら、ユーザーエージェントは、ユーザーが given relying party に対するこの処理からオプトアウトしたいことを示す機会を与えなければならない (MUST)。

Tests

authentication-optout.https.html (live test) (source)

4.10.2. 取引確認 UX の結果

ユーザーエージェントは、先に進むかどうか、およびどのように進むかについて、ユーザーが次のいずれかの選択肢を示せるようにしなければならない (MUST)。

ユーザーが支払いを続行したく、認証に SPC Credential を使用したい場合

ユーザーが操作している PaymentRequest に対して、ユーザーが支払リクエストを受諾するアルゴリズムを実行する。

ユーザーが支払いを続行したいが、 data["credentialIds"] が空であるか、 SPC Credential を使用したくない場合

次の手順を実行する：

data["credentialIds"] を空リストに設定する。

Note: これにより、 PaymentRequest.show() のプロミスは "NotAllowedError" DOMException で拒否される。詳細は § 4.11 支払リクエストへの対応手順を参照。
ユーザーが操作している PaymentRequest に対して、ユーザーが支払リクエストを受諾するアルゴリズムを実行する。

Tests

authentication-auth-another-way.https.html (live test) (source)

ユーザーが支払いを続行したくない場合

ユーザーが操作している PaymentRequest に対して、ユーザーが支払リクエストを中止するアルゴリズムを実行する。

Note: これにより、 PaymentRequest.show() のプロミスは "AbortError" DOMException で拒否される。

ユーザーが given relying party に対するこの処理からオプトアウトしたい場合

"OptOutError" DOMException で PaymentRequest.show() を拒否する。 § 12.7 User opt out を参照。

Note: この選択肢は、 showOptOut が true に設定されている場合にのみユーザーに提供されなければならない。

4.10.3. テスト自動化サポート

current transaction automation mode が "none" でない場合、ユーザーエージェントはまず、自身が自動化コンテキスト内にいることを検証するべきである (should) （WebDriver のセキュリティ上の考慮事項を参照）。その後、ユーザーエージェントは上記の情報伝達およびユーザー同意の取得をバイパスし、代わりに current transaction automation mode の値に基づいて次のように振る舞うべきである。

"autoAccept": ユーザーが取引の詳細を確認し、承認したかのように振る舞う。
"autoChooseToAuthAnotherWay": ユーザーが取引の詳細を確認し、承認したが、認証に SPC Credential を使用したくないことも示したかのように振る舞う。もし data["credentialIds"] が空であれば、これは "autoAccept" と同等である。
"autoReject": ユーザーが取引の詳細を確認し、それを拒否した（つまり、取引を続行したくない）かのように振る舞う。
"autoOptOut": ユーザーが取引の詳細を確認し、オプトアウトしたいことを示したかのように振る舞う。

4.11. 支払リクエストへの対応手順

この支払方法に対する、与えられた PaymentRequest request および SecurePaymentConfirmationRequest data に対する支払リクエストへの対応手順は次のとおりである。

Note: これらの手順は、ユーザーが取引確認 UX を受諾した場合にのみ実行される。これらはユーザーが支払リクエストを受諾するアルゴリズムから呼び出される。

もし data["credentialIds"] が空であれば、 "NotAllowedError" DOMException を投げる。これは、ユーザーが SPC を使用できない、または使用したくない場合における Authentication Ceremony Privacy を維持する。

Note: ここで throw すると、 PaymentRequest.show() のプロミスは "NotAllowedError" DOMException で拒否される。
topOrigin を、request の関連設定オブジェクトのトップレベルオリジンとする。
payment を、新しい AuthenticationExtensionsPaymentInputs 辞書とし、そのフィールドを次のようにする：

isPayment

ブール値 true。

rpId

data["rpId"]

topOrigin

topOrigin

payeeName

存在する場合は data["payeeName"]、そうでなければ省略。

payeeOrigin

存在する場合は data["payeeOrigin"]、そうでなければ省略。

paymentEntitiesLogos

存在しかつ空でない場合は data["paymentEntitiesLogos"]、そうでなければ省略。

この仕様の現行バージョンでは、PaymentEntityLogo ごとに 1 つの URL のみをサポートする。そのため、データ構造をそのままコピーして署名すれば、ユーザーに何が表示されたかを示すのに十分である。将来のバージョンでは、たとえばダークモードのネイティブサポートのために、 PaymentEntityLogo ごとに複数の URL を追加するかもしれない。その場合、この仕様は、ある PaymentEntityLogo についてどの URL が表示されたかを Relying Party に示す必要がある。

total

request.[[details]]["total"]

instrument

data["instrument"]

browserBoundPubKeyCredParams

data["browserBoundPubKeyCredParams"]
extensions を、新しい AuthenticationExtensionsClientInputs 辞書とし、その payment メンバーを payment に設定し、その他のメンバーを data["extensions"] から設定する。
publicKeyOpts を、新しい PublicKeyCredentialRequestOptions 辞書とし、そのフィールドを次のようにする：

challenge

data["challenge"]

timeout

data["timeout"]

rpId

data["rpId"]

userVerification

required

extensions

extensions

Note: このアルゴリズムは、 userVerification の値として "required" をハードコードしている。これは Chrome の初期実装がサポートする値であるためである。現在の制限は将来的に変わる可能性がある。作業グループは、（"preferred" や "discouraged" など）他の値のサポートによって恩恵を受けるユースケースの共有を実装者に求めている。
data["credentialIds"] 内の各 id について：
1. descriptor を、新しい PublicKeyCredentialDescriptor 辞書とし、そのフィールドを次のようにする：
  
  type
  
  public-key
  
  id
  
  id
  
  transports
  
  長さ 1 のシーケンスで、その唯一のメンバは internal である。
2. 追加により、 descriptor を publicKeyOpts["allowCredentials"] に加える。
outputCredential を、 «["publicKey" → publicKeyOpts]» を渡して資格情報を要求するアルゴリズムを実行した結果とする。

Note: Chrome の初期実装は、資格情報を要求するに対して data.credentialIds の全リストを渡さない。代わりに、リスト内から現在のデバイスに一致する 1 つの資格情報を選び、それだけを渡す。

Note: これは [webauthn-3] の Get 挙動をトリガーする。
outputCredential を返す。

5. WebAuthn拡張 - "`payment`"

このクライアント登録拡張および認証拡張は、認証情報がそれぞれSecure Payment Confirmation向けに作成または利用されることを示します。

登録時には、この拡張がブラウザによるSecure Payment Confirmation認証情報IDの識別・キャッシュを可能にします。認証時には、第三者がRelying Partyの代理で認証セレモニーを行えるようにし、署名暗号文に取引情報を追加します。

特に、ウェブサイトはnavigator.credentials.get()を使って直接この拡張を呼び出すべきではありません。認証用途の拡張は、PaymentRequestの"secure-payment-confirmation"決済方式を介してのみ利用可能です。

注: 以前はpayment拡張でクロスオリジンiframe内で認証情報作成が可能でしたが、WebAuthnではWebAuthn PR #1801以降、デフォルト対応となっています。

テスト

このテストは仕様記述の各行に直接対応するものではなく、クロスオリジンiframe内から認証処理が可能なことを検証します。この挙動は禁じる記述がないことで仕様化されています。

authentication-in-iframe.sub.https.html (ライブテスト) (ソース)

拡張子識別子

payment

操作の適用範囲

登録及び認証

クライアント拡張入力

partial dictionary AuthenticationExtensionsClientInputs {
  AuthenticationExtensionsPaymentInputs payment;
};

dictionary AuthenticationExtensionsPaymentInputs {
  boolean isPayment;
  sequence<PublicKeyCredentialParameters> browserBoundPubKeyCredParams;

  // Only used for authentication.
  USVString rpId;
  USVString topOrigin;
  USVString payeeName;
  USVString payeeOrigin;
  sequence<PaymentEntityLogo> paymentEntitiesLogos;
  PaymentCurrencyAmount total;
  PaymentCredentialInstrument instrument;
};

isPayment

拡張がアクティブであることを示す。

rpId