セキュアペイメント確認

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 加盟店による認証管理参照。

注: 最初のSPC実験を迅速にサポートするため、このAPIはPayment RequestとPayment Handler APIの既存実装上に設計されましたが、今後SPCをPayment Requestから独立した設計にする方向で合意されています（具体的な時期は未定）。これにより、開発者は機能検出や呼び出し等、API利用体験が向上する見込みです。

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.8 支払い可能か確認手順参照。

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

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. 決済方式データの検証手順

この決済方式の決済方式データの検証手順は、入力PaymentRequest requestおよびSecurePaymentConfirmationRequest dataについて、以下の通りです：

テスト

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

4.8. 支払い可能か確認手順

この決済方式の支払い可能か確認手順は、入力SecurePaymentConfirmationRequest dataについて、以下の通りです：

テスト

data["payeeOrigin"] が存在する場合：
1. parsedURLをdata["payeeOrigin"]に URLパーサーを実行して得る。
2. parsedURLが失敗でないことを保証する。
3. parsedURLのschemeが"https"であることを保証する。
注: これらの事前条件は以前決済方式データの検証手順でチェックされていた。
1. data["payeeOrigin"] をparsedURLのオリジンのシリアル化結果に設定する。
アイコン画像リソースをフェッチし、«["src" → data["instrument"]["icon"]]»をimageに渡す。失敗した場合：
1. data["instrument"]["iconMustBeShown"] がtrueならfalseを返す。
2. それ以外ならdata["instrument"]["icon"]を空文字列に設定する。
  
  注: 指定されたアイコンが表示されなかったことをRPに通知（出力instrumentのicon文字列が空になる）。
注: 画像リソースは認証情報一致の有無にかかわらずフェッチされ、認証情報ID存在のプロービング対策となる。
ユーザーエージェントは任意でdata["paymentEntitiesLogos"] のエントリーをリスト末尾から削除可能。

注: ユーザーエージェントは表示ロゴ数を自身で調整可能。ロゴは表示優先度降順維持。
data["paymentEntitiesLogos"]の各logoについて：
1. logo画像リソースをフェッチし、«["src" → logo["url"]]»をimageに渡し、結果をデコードする。
2. フェッチまたはデコード失敗ならlogo["url"]を空文字列に設定。
  
  注: 指定ロゴが表示されなかったことをRPに通知（出力paymentEntitiesLogos シーケンス内の当該logoのurlが空文字になる）。
注: ロゴリソースも認証情報一致の有無にかかわらずフェッチされ、認証情報ID存在のプロービング対策となる。
data["credentialIds"]の各idについて：
1. 認証情報が現デバイスで利用可能かサイレント判定する手順をdata["rpId"]とidで行う。結果がfalseならidをdata["credentialIds"]から削除。
2. data["rpId"]がrequestのオリジンでない場合は、 SPC認証情報がサードパーティ対応かサイレント判定する手順をdata["rpId"]とidで行い、結果がfalseならidをdata["credentialIds"]から削除。
trueを返す。

4.9. 取引確認UXの表示

PaymentRequest.show() が呼び出され、Secure Payment Confirmation payment handlerが選択された場合（当該アルゴリズムのステップ19–24）、ユーザーエージェントはユーザーに対して、続行するかどうかおよびどのように続行するかを選択できるユーザーインターフェイスを必ず提示しなければなりません。

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

ユーザーエージェントの実装の選択肢を制限しないために、本仕様は特定のユーザーインターフェイスの表示を要求しません。しかし、Relying PartyがCollectedClientPaymentData に含まれる情報を信頼できるようにするため、ユーザーエージェントは次の事項がユーザーに伝えられ、認証に対するユーザーの同意が収集されることを保証しなければなりません：

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

注: 指定されたアイコンをフェッチまたはデコードできなかった場合、iconMustBeShown はここではfalseでなければならない。そうでないと支払い可能か確認する手順が先に失敗しているはずだからである。
非空の場合は、url エントリで表されるpaymentEntitiesLogos のロゴを表示すること。
- ユーザーエージェントは各label を必ず表示する必要はないが、アクセシビリティの目的で使用するべきである。labelは引き続き含まれ、CollectedClientAdditionalPaymentData に署名されることになる。

ユーザーエージェントは、あればlocale の情報を利用して、ウェブサイトと整合した言語でローカライズされたUXやロケールに基づく書式で表示してもよい。

もしshowOptOut がtrueであれば、ユーザーエージェントはユーザーに対して当該指定されたRelying Party に関してプロセスからオプトアウトしたいかを示す機会を与えなければなりません。

Tests

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

4.9.2. 取引確認UXの結果

ユーザーエージェントは、続行するかどうか、またどのように続行するかについて、ユーザーが次のいずれかの選択を示せるようにしなければなりません：

ユーザーは支払いを続行したい。認証には SPC Credentialを使用する、

ユーザーが対話しているPaymentRequest 上で、user accepts the payment request algorithmを実行する。

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

以下の手順を実行する：

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

注: これによりPaymentRequest.show() のPromiseは"NotAllowedError" DOMException で拒否される；§ 4.10 支払い要求への応答手順参照。
ユーザーが対話しているPaymentRequest 上で、user accepts the payment request algorithmを実行すること。

Tests

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

ユーザーは支払いを続行したくない、

ユーザーが対話しているPaymentRequest 上で、user aborts the payment request algorithm を実行すること。

注: これによりPaymentRequest.show() のPromiseは"AbortError" DOMException で拒否される。

ユーザーは当該指定されたRelying Party のプロセスからオプトアウトしたい、

PaymentRequest.show() を"OptOutError" DOMException で拒否すること。§ 12.6 ユーザーのオプトアウト参照。

注: このオプションは、showOptOut がtrueに設定されている場合にのみユーザーに提供されればよい。

4.9.3. テスト自動化のサポート

もし現在のトランザクション自動化モードが"none"でない場合、ユーザーエージェントはまずそれが自動化コンテキストであることを検証すべきです（WebDriverのセキュリティ考慮参照）。そのうえで、上記の情報伝達とユーザー同意の収集をバイパスし、現在のトランザクション自動化モードの値に基づいて代わりに以下を行うべきです：

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

4.10. 支払い要求への応答手順

この決済方式のための支払い要求への応答手順は、指定されたPaymentRequest requestおよびSecurePaymentConfirmationRequest dataについて以下の通りです。

注: これらの手順はユーザーが取引確認UXを受け入れた場合にのみ実行されます；これらはuser accepts the payment request algorithmによって呼び出されます。

data["credentialIds"] が空であれば、"NotAllowedError" DOMException をthrowすること。これは、ユーザーがSPCを使えないか使いたくない場合の認証セレモニーのプライバシーを保護するためである。

注: ここでthrowするとPaymentRequest.show() のPromiseは"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を追加するかもしれません。その場合、仕様はどの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

注: このアルゴリズムはuserVerification に対して"required"をハードコーディングしている。これはChromeの初期実装がサポートする値であるためで、現状の制限は将来変更される可能性がある。ワーキンググループは、"preferred"や"discouraged"のような他の値のサポートが有益なユースケースについて実装者からの情報提供を求めている。
data["credentialIds"]内の各idについて：
1. descriptorを新しいPublicKeyCredentialDescriptor 辞書として作成し、そのフィールドを以下のように設定する：
  
  type
  
  public-key
  
  id
  
  id
  
  transports
  
  唯一のメンバーがinternal である長さ1のシーケンス。
2. AppendでdescriptorをpublicKeyOpts["allowCredentials"] に追加する。
outputCredentialを、Request a Credentialアルゴリズムを実行して得る結果とする。渡す引数は«["publicKey" → publicKeyOpts]»である。

注： Chrome の初期実装では、data.credentialIds の全リストを Request a Credential に渡しません。代わりにリストの中から現在のデバイスに一致する1つの資格情報を選択し、それだけを渡します。
注: これにより[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