보안 결제 확인

1. 소개

이 절과 그 하위 절은 비규범적입니다.

이 명세는 웹상의 결제 과정에서 강력한 인증 방법을 사용할 수 있도록 하는 API를 정의합니다. 이 API는 [webauthn-3]와 동일한 인증 이점과 사용자 개인정보 보호에 대한 중점을 유지하면서 결제 처리의 요구 사항을 충족하기 위한 개선 사항을 제공하는 것을 목표로 합니다.

[webauthn-3]와 마찬가지로, 이 명세는 사용자와 관련된 두 가지 프로세스를 정의합니다. 첫 번째는 § 3 등록(이전에는 "등록 절차(enrollment)"라고 불렸습니다)로, 사용자와 신뢰 당사자 사이의 관계가 형성됩니다. 두 번째는 § 4 인증 - 보안 결제 확인 결제 수단으로, 사용자가 신뢰 당사자의 챌린지에 (중개 결제 서비스 제공업체를 통해서일 수도 있습니다) 응답하여 특정 결제에 동의하는 과정입니다.

이 명세의 목표 중 하나는 결제 과정에서 인증에 따른 불편을 줄이는 것이며, 이를 위한 한 가지 방법은 한 번의 등록으로 사용자가 수행할 수 있는 인증 횟수를 최대화하는 것입니다. 즉, 신뢰 당사자의 동의가 있다면, 이상적으로 사용자는 "한 번만 등록"하고 모든 판매자 출처에서(결제 서비스 제공업체를 통해서도) 인증할 수 있어야 하며, 최초 등록한 판매자 출처에만 국한되지 않아야 합니다.

이를 위해 보안 결제 확인의 중요한 기능 중 하나는 판매자(또는 다른 주체)가 신뢰 당사자를 대신하여 인증 절차를 시작할 수 있다는 것입니다. 신뢰 당사자는 자격 증명을 생성할 때 이러한 동작을 허용하도록 명시적으로 동의해야 합니다.

기능적으로 이 명세는 결제 수단을 PaymentRequest API에 새롭게 정의하고, WebAuthn 확장을 추가하여 [webauthn-3]에 결제 전용 데이터 구조와 기기 바인딩을 추가하고, 결제 환경에서 API를 호출할 수 있도록 기존 가정을 완화합니다.

1.1. 사용 사례

[webauthn-3]는 웹을 위한 일반적인 인증 기능을 제공하지만, 다음 사용 사례는 이 명세에서 정의하는 결제 전용 확장의 가치를 보여줍니다.

온라인 거래에서 암호화 기술을 기반으로 한 인증의 일반적인 사용 사례는 이미 널리 확립되어 있다고 가정합니다.

1.1.1. 거래 확인에 대한 암호학적 증거

많은 온라인 결제 시스템에서는 결제 수단을 발급하는 주체(예: 은행)가 인증을 통해 사기를 줄이려는 것이 일반적입니다. [webauthn-3]와 이 명세를 사용하면 인증기를 통해 판매자의 출처, 거래 금액 및 통화와 같은 중요한 결제 전용 정보에 암호학적으로 서명할 수 있습니다. 그러면 은행은 신뢰 당사자로서 서명된 결제 전용 정보를 검증하고 이를 결제 승인 여부를 결정하는 데 활용할 수 있습니다.

은행이 일반적인 [webauthn-3]를 사용한다면, 검증해야 할 결제 전용 정보는 WebAuthn의 challenge에 저장해야 합니다. 이로 인해 다음과 같은 문제가 발생합니다.

이는 재전송 공격을 방지하기 위한 challenge 필드를 본래 목적과 다르게 사용하는 것입니다.
이에 대한 명세가 없으므로 각 은행은 결제 전용 정보를 챌린지에 어떤 형식으로 구성하고 인코딩할지 자체적으로 정의해야 할 가능성이 높으며, 이로 인해 배포가 복잡해지고 파편화가 심화됩니다.
규제에 따라 사용자에게 결제 전용 정보가 표시되었고 사용자가 이에 동의했다는 증거가 요구될 수 있습니다. 일반적인 [webauthn-3]는 이러한 정보 표시를 지원하지 않습니다. challenge 필드에 저장된 정보와 관련된 사용자 경험이 정의되어 있지 않기 때문입니다.

이러한 제약으로 인해 보안 결제 확인에는 다음과 같은 동작이 도입되었습니다.

challenge 필드는 일반적인 [webauthn-3]와 마찬가지로 재전송 공격을 방지하는 용도로만 사용됩니다.
SPC는 결제 전용 정보의 형식을 정의합니다. 이를 통해 범용 검증 코드와 테스트 스위트를 개발할 수 있습니다.
SPC는 악의적인 웹사이트(또는 신뢰할 수 있는 웹사이트에 악의적으로 삽입된 JavaScript 코드)가 우회할 수 없는 방식으로 사용자 에이전트가 결제 전용 정보를 사용자에게 표시했음을 보장합니다.
- 결제 전용 정보는 CollectedClientData 사전에 포함되며, 이 사전은 JavaScript를 통해 변조할 수 없습니다.
참고: 은행과 결제 생태계의 다른 이해관계자들은 현재 TLS, iframe 및 기타 웹 기능을 사용한 브라우저 기반 결제를 충분히 신뢰하고 있습니다. 현재 명세는 웹 결제의 보안성과 사용성을 향상하도록 설계되었습니다.

1.1.2. 판매자의 인증 제어

판매자는 결제 과정에서 사용자가 이탈하는 것을 방지하려 하며, 특히 인증에 따른 불편을 줄이고자 합니다. 사용자 인증에 [webauthn-3]를 사용하려는 신뢰 당사자 (예: 은행)는 일반적으로 iframe에서 인증을 수행합니다. 그러나 판매자는 신뢰 당사자가 인증 결과를 검증할 수 있도록 하면서도 사용자 인증 경험을 직접 관리하기를 선호합니다.

이러한 제약으로 인해 보안 결제 확인에는 다음과 같은 동작이 도입되었습니다.

SPC를 사용하면 신뢰 당사자 이외의 주체도 신뢰 당사자를 대신하여 인증 자격 증명을 사용할 수 있습니다. 이후 신뢰 당사자는 인증 결과를 검증할 수 있습니다.

이 기능은 신뢰 당사자가 더 이상 인증을 위한 자체 프런트엔드 사용자 경험을 구축할 필요가 없다는 추가적인 이점도 제공합니다. 대신 결제 서비스 제공업체가 판매자를 대신하여 이를 구축할 가능성이 높습니다.

참고: 인증 사용자 경험을 직접 제공하려는 신뢰 당사자는 여전히 iframe에서 SPC를 사용하여 이를 제공할 수 있습니다.

1.1.3. 기기 바인딩에 대한 암호학적 증거

결제 업계에서는 기기 소유를 나타내는 신호가 두 번째 인증 요소로서 중요한 역할을 합니다. WebAuthn은 하나의 자격 증명을 여러 기기에서 사용할 수 있는 동기화된 패스키를 지원합니다(웹 인증 § 1.2.1 다중 기기 자격 증명을 사용하는 소비자). 동기화는 로그인 사용 사례에서 사용자 경험을 개선하지만, 일부 규제 환경에서는 동기화된 패스키만으로 기기 소유 요구 사항을 충족하지 못한다는 우려가 제기되었습니다.

이러한 우려에 따라 사용자 에이전트가 생성하는 보조 공개 키와 비공개 키 쌍을 포함하게 되었습니다. 이 키 쌍의 비공개 키는 오직 하나의 기기에만 저장되고 해당 기기에서만 사용됩니다. 이러한 키와 SPC에서의 사용을 브라우저 바인딩 키라고 합니다.

1.2. API 사용 시나리오 예시

이 절에서는 보안 결제 확인의 몇 가지 시나리오와 이 API를 사용하는 데 필요한 해당 예제 코드를 살펴봅니다. 이러한 시나리오는 예시 흐름일 뿐이며 API 사용 범위를 제한하지 않습니다.

1.2.1. 결제 과정 중 등록

이는 사용자가 특정 판매자에서 결제하는 동안 발급 은행이 새로운 자격 증명을 생성하고 저장하는 최초 등록 흐름입니다.

사용자가 merchant.example에 방문하여 구매할 상품을 선택한 다음 결제 과정으로 진행합니다. 사용자는 결제 수단의 세부 정보를 입력하고 결제 의사를 표시합니다(예: "결제" 버튼을 누릅니다).
판매자는 결제 수단을 발급한 은행과 대역 외 방식(예: 다른 프로토콜 사용)으로 통신합니다. 발급 은행은 사용자 확인을 요청하고 판매자가 iframe에서 열 수 있도록 은행이 관리하는 URL을 제공합니다.
판매자는 bank.example을 가리키는 iframe을 열고 allow 속성을 "publickey-credentials-create"로 설정합니다.
iframe에서 발급 은행은 기존 인증 수단(예: SMS 일회용 비밀번호)을 통해 사용자의 신원을 확인합니다. 확인 후 은행은 사용자에게 향후 결제를 위한 SPC 인증 등록을 안내합니다.
사용자가 동의하면(예: 은행의 사용자 인터페이스에서 "등록" 버튼 클릭) 은행은 iframe에서 코드를 실행합니다(아래 예제 참조).
사용자는 WebAuthn 등록 과정을 거칩니다. 새로운 자격 증명이 생성되어 발급 은행으로 반환되며, 은행은 이를 사용자 및 결제 수단과 연결된 서버 측 데이터베이스에 저장합니다.
확인이 완료되면 은행 iframe이 닫히고 판매자는 사용자의 결제 과정을 마무리합니다.

이러한 방식으로 사용자를 등록하는 예제 코드는 다음과 같습니다. 이 예제 코드는 Promise를 더 쉽게 읽고 처리할 수 있도록 async/await를 사용할 수 있다고 가정합니다.

if (!window.PublicKeyCredential) { /* 클라이언트가 지원하지 않습니다. 오류를 처리합니다. */ }

const publicKey = {
  // 챌린지는 은행 서버에서 생성하여 iframe으로 전송해야 합니다.
  challenge: new Uint8Array([21,31,105 /* 서버에서 생성한 29개의 추가 무작위 바이트 */]),

  // 신뢰 당사자:
  rp: {
    name: "Fancy Bank",
  },

  // 사용자:
  user: {
    // WebAuthn의 일부입니다. 이 정보는 SPC에서 필수는 아니지만
    // 은행 서버가 향후 거래에서 이 사용자를
    // 식별하는 데 사용할 수 있습니다. 동일한 사용자에게 서로 다른 값을
    // 사용하면 해당 사용자에 대해 여러 자격 증명이 생성될 수 있으며
    // 자격 증명 선택으로 인한 사용자 경험의 불편이 발생할 수 있습니다.
    id: Uint8Array.from(window.atob("MIIBkzCCATigAwIBAjCCAZMwggE4oAMCAQIwggGTMII="), c=>c.charCodeAt(0)),
    name: "jane.doe@email.example",
    displayName: "Jane Doe",
  },

  // 이 예제에서 신뢰 당사자는 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입니다. 이
      // 예제에서는 ES256과 RS256이 허용되고 RS256이 선호됩니다.
      browserBoundPubKeyCredParams: [
        {
          type: "public-key",
          alg: -257 // "RS256"
        },
        {
          type: "public-key",
          alg: -7 // "ES256"
        }
      ]
    }
  }
};

// 참고: 다음 호출은 인증기에 사용자 인터페이스를 표시하게 합니다.
try {
  const newCredentialInfo = await navigator.credentials.create({ publicKey });
  // 검증 및 등록을 위해 새로운 자격 증명 정보를 서버로 전송합니다.
} catch(err) {
  // 허용 가능한 인증기가 없거나 사용자가 동의를 거부했습니다. 적절히 처리합니다.
}

1.2.2. 판매자 사이트에서의 인증

이는 이미 등록된 자격 증명을 보유한 사용자가 거래를 수행할 때 발급 은행과 판매자가 보안 결제 확인을 사용하려는 경우의 흐름입니다.

사용자가 merchant.example에 방문하여 구매할 상품을 선택한 다음 결제 과정으로 진행합니다. 사용자는 결제 수단의 세부 정보를 입력하고 결제 의사를 표시합니다(예: "결제" 버튼을 누릅니다).
판매자는 결제 수단의 발급 은행과 대역 외 방식으로 통신합니다(예: 다른 프로토콜 사용). 발급 은행은 사용자 확인을 요청하는 동시에 API 사용에 필요한 정보를 제공하여 SPC를 허용한다는 사실을 판매자에게 알립니다. 이 정보에는 챌린지와 해당 사용자 및 결제 수단에 연결된 모든 자격 증명 ID가 포함됩니다.
판매자는 아래에 표시된 예제 코드를 실행합니다.
사용자는 SPC 사용자 인터페이스에 표시된 결제 전용 정보에 동의하고 이후 WebAuthn 인증 절차를 수행합니다. 서명된 암호문은 판매자에게 반환됩니다(브라우저 바인딩 키 출력도 AuthenticationExtensionsPaymentOutputs에 포함됩니다).
판매자는 서명된 암호문을 발급 은행에 대역 외 방식으로 전달합니다. 발급 은행은 암호문을 검증하여 사용자가 유효한지, 어떤 결제 전용 정보가 표시되었는지, 사용자가 거래에 동의했는지를 확인합니다. 발급 은행은 거래를 승인하고 판매자는 사용자의 결제 과정을 완료합니다. 발급 은행은 브라우저 바인딩 키의 공개 키인 browserBoundPublicKey를 저장합니다.

사용자를 인증하는 예제 코드는 다음과 같습니다. 이 예제 코드는 Promise를 더 쉽게 읽고 처리할 수 있도록 async/await를 사용할 수 있다고 가정합니다.

/* securePaymentConfirmationAvailability는 브라우저가 */
/* SPC를 지원하는지 나타냅니다. 사용자가 이 기기에서 사용할 수 있는 */
/* 자격 증명을 가지고 있는지는 나타내지 않습니다. */
const spcAvailable =
  (await window.PaymentRequest?.securePaymentConfirmationAvailability?.()) === 'available';
if (!spcAvailable) {
  /* 브라우저가 SPC를 지원하지 않으므로 판매자는 기존 흐름으로 대체해야 합니다. */
}

const request = new PaymentRequest([{
  supportedMethods: "secure-payment-confirmation",
  data: {
    // 은행에서 받은 자격 증명 ID 목록입니다.
    credentialIds,

    rpId: "fancybank.example",

    // 챌린지도 은행에서 받습니다.
    challenge: new Uint8Array([21,31,105 /* 은행에서 생성한 29개의 추가 무작위 바이트 */]),

    instrument: {
      displayName: "FancyBank 플래티넘 카드",
      details: "****1234 | 01/29",
      icon: "https://fancybank.example/card-art.png",
    },

    payeeName: "판매자 상점",
    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과 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는 발급 은행이 검증할 거래 데이터가 포함된
  // clientDataJSON을 가진 PublicKeyCredential입니다.

  /* 검증을 위해 response.data를 발급 은행에 전송합니다. */
} catch (err) {
  /* SPC를 사용할 수 없으므로 판매자는 기존 흐름으로 대체해야 합니다. */
}

2. 용어

SPC 자격 증명

이 명세에서 정의한 동작에 사용할 수 있는 WebAuthn 자격 증명입니다.

이 명세는 신뢰 당사자가 다른 인증 흐름(예: 로그인)에서 SPC 자격 증명을 사용할 수 있는지 또는 사용할 수 없는지를 제한하려는 의도가 없습니다.

참고: 이 명세의 현재 버전에서는 자격 증명을 자사 또는 제3자 컨텍스트에서 사용하려면 신뢰 당사자가 명시적으로 동의해야 합니다. 장기적으로는 모든 WebAuthn 자격 증명을 자사 컨텍스트(예: 신뢰 당사자의 도메인)에서 SPC에 사용할 수 있도록 하고, 제3자가 자격 증명을 사용하도록 허용할 때만 명시적 동의를 요구하려는 것입니다.

제3자 사용이 허용된 SPC 자격 증명

SPC 자격 증명 중 신뢰 당사자가 자격 증명 생성 시 자신 이외의 주체가 보안 결제 확인 인증에 해당 자격 증명을 사용할 수 있도록 명시적으로 동의한 신뢰 당사자의 자격 증명입니다.

SPC 자격 증명의 제3자 사용 허용 여부를 사용자에게 알리지 않고 확인하는 단계

사용자 에이전트가 신뢰 당사자 식별자와 자격 증명 ID를 받아, 해당 ID가 나타내는 자격 증명이 제3자 사용이 허용된 SPC 자격 증명인지 사용자와 상호 작용하지 않고 확인하는 아직 정의되지 않은 프로세스입니다.

참고: WebAuthn 이슈 1667을 참조하시기 바랍니다.

현재 기기에서 자격 증명을 사용할 수 있는지 사용자에게 알리지 않고 확인하는 단계

사용자 에이전트가 신뢰 당사자 식별자와 자격 증명 ID를 받아, 해당 자격 증명 ID가 나타내는 자격 증명을 현재 기기에서 사용할 수 있는지(즉, WebAuthn Get 호출의 일부로 성공적으로 사용할 수 있는지) 사용자와 상호 작용하지 않고 확인하는 아직 정의되지 않은 프로세스입니다.

이를 통해 사용자 에이전트는 사용자가 거래를 성공적으로 완료할 가능성이 있을 때만 거래 사용자 인터페이스를 조건부로 표시할 수 있습니다.

참고: 이 속성을 지원하려면 SPC 자격 증명이 검색 가능해야 할 가능성이 높으며, 따라서 이 명세에서는 현재 이를 요구 사항으로 규정합니다.

참고: 이 속성은 WebAuthn 조건부 UI 제안에 필요한 속성과 매우 유사합니다. 두 기능 모두 동일한 기반 API로 지원할 수 있을 것으로 보입니다.

브라우저 바인딩 키

WebAuthn 자격 증명과 함께 거래 세부 정보에 서명하며 사용자 에이전트에 의해 단일 기기에 바인딩되는 공개 키와 비공개 키 키 쌍입니다. 참고: 이 기능의 초기 구현이 브라우저용으로 만들어졌기 때문에 이러한 이름이 선택되었지만, 이 개념은 모든 사용자 에이전트에 적용할 수 있습니다.

키 쌍

키 쌍은 공개 키와 비공개 키로 구성된 구조체이며, 두 키의 유형은 구현 정의에 따릅니다.

참고: 공개 키와 비공개 키는 IANA COSE 알고리즘 등록부 [IANA-COSE-ALGS-REG]에 명시된 암호화 알고리즘의 알고리즘별 매개변수입니다.

참고: 공개 키 부분은 등록 시 CollectedClientAdditionalPaymentRegistrationData.browserBoundPublicKey에서 반환되고, 결제 어서션 시에는 CollectedClientAdditionalPaymentData.browserBoundPublicKey에서 반환됩니다.

참고: 비공개 키는 BrowserBoundSignature.signature에 포함되는 암호학적 서명을 생성하는 데 사용됩니다. 사용자 에이전트는 비공개 키를 내보내지 않으며 기기의 보안 요소에 비공개 키를 저장할 수 있습니다.

3. 등록

보안 결제 확인에 사용자를 등록하려면 신뢰 당사자는 navigator.credentials.create()를 호출할 때 payment WebAuthn 확장을 지정해야 합니다.

테스트

참고: 이 명세에서는 조건부 UI가 없는 경우에도 브라우저가 SPC 자격 증명 ID를 캐시할 수 있도록 확장을 정의합니다. 향후 WebAuthn 버전에서 이 기능을 사용할 수 있게 되면 SPC에서 해당 확장에 대한 요구 사항을 제거할 수 있습니다. 확장을 포함한 SPC 자격 증명도 그 밖의 측면에서는 완전한 WebAuthn 자격 증명입니다.

참고: 등록 시 웹 인증에서는 name과 displayName이 모두 필요하지만, user 멤버의 정의에 따르면 구현에서 이후 인증 절차 중 어느 값도 표시할 의무는 없습니다. 2023년 10월 기준으로 두 값 중 name이 더 일관되게 표시됩니다. 개발자는 계속해서 구현 현황을 살펴보아야 합니다.

4. 인증 - 보안 결제 확인 결제 수단

보안 결제 확인을 통해 결제를 인증하기 위해 이 명세는 다음을 정의합니다.

주어진 결제의 인증 요청을 처리하는 결제 처리기인 보안 결제 확인 결제 처리기입니다.
이 결제 처리기에 대한 표준화된 결제 수단 식별자인 "secure-payment-confirmation"입니다.

보안 결제 확인 결제 처리기는 사용자에게 거래를 확인받은 후 인증 절차를 수행하여 사용자를 인증하고 인증 절차를 나타내는 서명된 데이터 블롭을 생성합니다.

개략적으로 보안 결제 확인의 인증은 [webauthn-3]와 유사하지만 한 가지 중요한 개념적 차이가 있습니다. 보안 결제 확인은 제3자(예: 판매자)가 신뢰 당사자를 대신하여 인증 절차를 시작하고, 명시되지 않은 다른 채널을 통해 신뢰 당사자로부터 받은 자격 증명을 전달할 수 있도록 합니다. § 1.1.2 판매자의 인증 제어를 참조하시기 바랍니다.

4.1. [payment-method-id]에 등록

[payment-method-id]의 표준화된 결제 수단 등록부에 다음을 추가합니다.

"secure-payment-confirmation": 보안 결제 확인 명세입니다.

4.2. Payment Request 생성자 수정

PaymentRequest 객체의 생성자에 대한 단계에서 4.3단계 뒤에 새 단계를 추가합니다.

결제 수단 처리: [하위 단계 1~3 생략]
1. seenPMIs에 "secure-payment-confirmation"이 포함되어 있고 seenPMIs의 크기가 1보다 크면 RangeError를 발생시킵니다.

4.3. 사용자 활성화 요구 사항 수정

PaymentRequest.show() 메서드의 단계에서 2단계와 3단계를 수정합니다.

request의 관련 전역 객체에 일시적 활성화가 없으면 사용자 에이전트는 다음을 수행할 수 있습니다(MAY).
1. "SecurityError" DOMException으로 거부된 Promise를 반환합니다.
그렇지 않으면 관련 전역 객체의 사용자 활성화를 소비합니다.

참고: 이를 통해 사용자 에이전트는 사용자 활성화를 요구하지 않을 수 있습니다. 예를 들어 리디렉션 시 사용자 활성화가 존재하지 않을 수 있는 리디렉션 인증 흐름을 지원할 수 있습니다. 보안 고려 사항은 § 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

재전송 공격을 방지하기 위해 신뢰 당사자가 서버 측에서 생성하는 무작위 챌린지입니다.

rpId

자격 증명의 신뢰 당사자 식별자입니다.

credentialIds

주어진 결제 수단에 대한 자격 증명 식별자 목록입니다.

instrument

등록 중 표시되고 거래 세부 정보와 함께 서명될 결제 수단의 이름과 아이콘에 대한 설명입니다.

timeout

거래 세부 정보에 서명하는 요청이 시간 초과되기까지의 밀리초 수입니다. 최대 1시간입니다. 기본값과 허용되는 값의 범위는 사용자 에이전트가 정의합니다. 웹 인증에서는 시간 초과에 대한 추가 지침을 제공합니다.

payeeName

이 SPC 호출의 대상인 수취인(예: 판매자)의 표시 이름입니다. 선택 사항이며 payeeOrigin과 함께 또는 이를 대신하여 제공할 수 있습니다.

payeeOrigin

이 SPC 호출의 대상인 수취인(예: 판매자)의 출처입니다. 선택 사항이며 payeeName과 함께 또는 이를 대신하여 제공할 수 있습니다.

paymentEntitiesLogos

이 SPC 호출의 대상인 결제를 지원하는 주체를 나타내는 로고의 선택적 목록이며, 표시 우선순위가 높은 순서대로 나열됩니다. 사용자 에이전트는 일부 또는 모든 로고를 표시할 의무가 없습니다. § 4.9 결제 가능 여부 확인 단계를 참조하시기 바랍니다.

참고: 이 명세에서 로고의 정확한 렌더링 방식을 지정하지 않은 것은 의도적입니다. 이는 렌더링에 대한 사용자 에이전트의 제어권을 유지하고, 여러 고려 사항과 제약에 따라 정보를 최적으로 표시할 수 있도록 하기 위한 것입니다. 하지만 목록 내 로고의 순서는 중요하므로 개발자는 특정 순서가 원하는 결과를 제공하는지 실험할 수 있습니다.

extensions

전달된 자격 증명에 사용해야 하는 모든 WebAuthn 확장입니다. 호출자는 결제 확장을 지정할 필요가 없으며 자동으로 추가됩니다.

참고: 제3자 SPC 호출에서는 이 사전이 비어 있지 않으면 예외가 발생합니다. 이는 비공개 데이터를 저장할 수 있는 신뢰 당사자의 확장에 대한 공격을 방지하기 위한 것입니다. § 11.1.3 신뢰 당사자에게만 허용되는 WebAuthn 확장을 참조하시기 바랍니다.

browserBoundPubKeyCredParams

브라우저 바인딩 키에 사용되는 암호화 알고리즘의 유형을 제한하는 허용된 자격 증명 유형 목록입니다.

참고: 이 멤버는 브라우저 바인딩 키를 새로 생성해야 하는 경우에만 사용됩니다.

locale

호출자의 로케일 기본 설정을 나타내는 언어 태그의 선택적 목록입니다([BCP47] 참조). 이 값에 하나 이상의 언어 태그가 설정되면 사용자 에이전트는 목록의 태그 중 보안 결제 확인 대화 상자에서 사용될 언어와 일치하는 태그가 있는지 확인합니다. 제공된 언어 태그 중 일치하는 것이 없으면 사용자 에이전트는 PaymentRequest.canMakePayment()가 반환하는 Promise를 "NotSupportedError" DOMException으로 거부합니다.

showOptOut

거래 확인 사용자 경험 중 사용자에게 거부를 선택할 기회를 제공할지 여부입니다. 선택 사항이며 기본값은 false입니다.

4.5. 결제 수단 추가 데이터 유형

이 결제 수단의 결제 수단 추가 데이터 유형은 SecurePaymentConfirmationRequest입니다.

4.6. 보안 결제 확인의 사용 가능 여부 확인

개발자가 보안 결제 확인의 사용 가능 여부를 간단하게 확인할 수 있도록 PaymentRequest에 정적 API를 추가합니다. 이 메서드인 securePaymentConfirmationAvailability()는 보안 결제 확인을 사용할 수 있는지, 사용할 수 없다면 그 근본적인 이유를 어느 정도 나타내는 열거형 멤버를 반환합니다. 열거형 출력을 사용하는 목적은 개발자가 사용자의 인증 옵션을 안내하고 설명하는 데 도움을 주기 위한 것입니다.

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 열거형에는 다음 멤버가 포함됩니다.

available

사용자 에이전트가 호출 프레임에서 보안 결제 확인 API를 사용할 수 있다고 판단함을 나타냅니다.

참고: 이 결과는 특정 SPC 자격 증명을 사용할 수 있는지 또는 향후 사용할 수 있게 되는지를 나타내지 않습니다.

unavailable-unknown-reason

알 수 없는 이유로 호출 프레임에서 보안 결제 확인 API를 사용할 수 없음을 나타냅니다. 사용자 에이전트는 사용자 개인정보를 보호하기 위해 더 구체적인 이유 대신 항상 이 결과를 반환하도록 선택할 수 있습니다(MAY).

unavailable-feature-not-enabled

기능이 활성화되지 않아 호출 프레임에서 보안 결제 확인 API를 사용할 수 없음을 나타냅니다.

unavailable-no-permission-policy

프레임에 "payment" 권한 정책이 없어서 호출 프레임에서 보안 결제 확인 API를 사용할 수 없음을 나타냅니다.

unavailable-no-user-verifying-platform-authenticator

사용할 수 있는 사용자 검증 플랫폼 인증기가 없기 때문에 호출 프레임에서 보안 결제 확인 API를 사용할 수 없음을 나타냅니다.

참고: 이 정보는 isUserVerifyingPlatformAuthenticatorAvailable를 호출하여 얻을 수도 있지만, 개발자의 편의를 위해 이 API에도 포함되었습니다.

주어진 Document document에서 securePaymentConfirmationAvailability()를 호출하면 사용자 에이전트는 아래 단계를 수행해야 합니다. 사용자 에이전트는 사용자의 개인정보를 보호해야 하거나 사용자 에이전트 고유의 이유로 단계를 완료할 수 없는 경우 언제든지 "unavailable-unknown-reason"을 반환하도록 선택할 수 있습니다.

사용자 에이전트가 보안 결제 확인을 지원하지 않거나, 지원하지만 사용자 에이전트 고유의 메커니즘을 통해 기능이 비활성화된 경우 "unavailable-feature-not-enabled"을 반환합니다.
"payment" 권한 정책이 document에 대해 활성화되지 않은 경우 "unavailable-no-permission-policy"을 반환합니다.
사용할 수 있는 사용자 검증 플랫폼 인증기가 없으면 "unavailable-no-user-verifying-platform-authenticator"을 반환합니다.
document에서 보안 결제 확인 기능을 호출했을 때 작동하지 않는 다른 이유가 있다면 "unavailable-unknown-reason"을 반환합니다.
"available"을 반환합니다.

이 API를 사용하면 개발자는 SPC 흐름을 시작할지 결정할 때 다음과 같이 확인할 수 있습니다.

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

참고: SPC 기능 감지에는 이미 생성된 PaymentRequest 객체에서 canMakePayment를 호출하는 대신 정적 securePaymentConfirmationAvailability 메서드를 사용하는 것이 권장됩니다.

참고: 이 API의 개인정보 보호 고려 사항은 § 12.5 securePaymentConfirmationAvailability를 통한 핑거프린팅을 참조하시기 바랍니다.

4.7. 보안 결제 확인 기능의 사용 가능 여부

개발자가 보안 결제 확인의 기능을 사용할 수 있는지 확인할 수 있도록 PaymentRequest에 정적 API를 추가합니다. 이 메서드인 getSecurePaymentConfirmationCapabilities()는 기능 키를 불리언 값에 매핑하는 레코드를 반환합니다.

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

typedef record<DOMString, boolean> SecurePaymentConfirmationCapabilities;

SecurePaymentConfirmationCapabilities의 키는 사전식 오름차순으로 정렬되어야 합니다(MUST). 키 집합에는 SecurePaymentConfirmationCapability의 열거형 값 집합이 포함되는 것이 좋지만(SHOULD), 사용자 에이전트는 필요하다고 판단하는 경우 키를 생략할 수 있습니다(MAY). § 12.6 getSecurePaymentConfirmationCapabilities를 통한 핑거프린팅을 참조하시기 바랍니다.

특정 기능의 값이 true이면 해당 기능이 현재 이 사용자 에이전트의 보안 결제 확인 구현에서 지원되는 것으로 알려져 있습니다.

특정 기능의 값이 false이면 해당 기능이 현재 이 사용자 에이전트의 보안 결제 확인 구현에서 지원되지 않는 것으로 알려져 있습니다.

어떤 기능이 키로 존재하지 않으면 이 사용자 에이전트의 보안 결제 확인 구현에서 해당 기능의 지원 여부를 알 수 없습니다.

이 API를 사용하면 개발자는 보안 결제 확인 흐름을 시작할지 결정할 때 다음과 같이 특정 기능의 지원 여부를 확인할 수 있습니다.

if (PaymentRequest && PaymentRequest.getSecurePaymentConfirmationCapabilities) {
    const capabilities = await PaymentRequest.getSecurePaymentConfirmationCapabilities();
    if (capabilities.browserBoundKeyHardware) {
        // SPC API 사용 시 하드웨어 기반 BBK를 사용할 수 있습니다.
    }
}

참고: 이 API의 개인정보 보호 고려 사항은 § 12.6 getSecurePaymentConfirmationCapabilities를 통한 핑거프린팅을 참조하시기 바랍니다.

4.7.1. `SecurePaymentConfirmationCapability` 열거형

enum SecurePaymentConfirmationCapability {
  "browserBoundKeyHardware",
};

이 열거형은 개발자가 사용자에게 특정 작업 흐름과 경험을 제공하기 위해 평가할 수 있는 제한된 보안 결제 확인 기능 집합을 정의합니다.

browserBoundKeyHardware

보안 결제 확인 API가 기기의 하드웨어 보안 요소에 저장된 브라우저 바인딩 키를 사용할 수 있음을 나타냅니다.

자세한 내용은 § 6 브라우저 바인딩 키 저장소를 참조하시기 바랍니다.

4.8. 결제 수단 데이터 유효성 검사 단계

이 결제 수단의 결제 수단 데이터 유효성 검사 단계는 입력 PaymentRequest request와 SecurePaymentConfirmationRequest data에 대해 다음과 같습니다.

테스트

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이 실패이면 TypeError를 발생시킵니다.
3. parsedURL의 스킴이 "https"가 아니면 TypeError를 발생시킵니다.
data["paymentEntitiesLogos"]가 존재하고 비어 있지 않으면:
1. data["paymentEntitiesLogos"]의 각 logo에 대해:
  1. logo["url"]이 비어 있으면 TypeError를 발생시킵니다.
  2. logo["url"]에 대해 URL 파서를 실행합니다. 결과가 실패이면 TypeError를 발생시킵니다.
  3. logo["label"]이 비어 있으면 TypeError를 발생시킵니다.
data["extensions"]가 존재하고 비어 있지 않으며, data["rpId"]가 request의 관련 설정 객체의 출처가 아니면 TypeError를 발생시킵니다.
data["locale"]이 존재하고 비어 있지 않으면:
1. dialogLanguageTag를 보안 결제 확인 대화 상자에서 사용하는 언어 태그로 설정합니다.
2. matched를 false로 설정합니다.
3. data["locale"]의 각 tag에 대해:
  1. tag가 올바른 형식의 [BCP47] 언어 태그가 아니면 TypeError를 발생시킵니다.
  2. tag와 dialogLanguageTag가 모두 둘 이상의 언어 하위 태그를 포함하고, tag와 dialogLanguageTag가 ASCII 대소문자를 구분하지 않는 방식으로 일치하면 matched를 true로 설정하고 반복을 종료합니다.
  3. tag 또는 dialogLanguageTag 중 적어도 하나가 기본 언어 하위 태그로만 구성되고([BCP47] 참조), 두 기본 언어 하위 태그가 ASCII 대소문자를 구분하지 않는 방식으로 일치하면 matched를 true로 설정하고 반복을 종료합니다.
4. matched가 false이면 "NotSupportedError" DOMException을 발생시킵니다.
참고: 일치하는 항목이 없을 때 NotSupportedError를 반환하면 호출자는 대화 상자의 로케일이 요청된 로케일 기본 설정 중 어느 것과도 일치하지 않음을 알 수 있습니다.

참고: 여기에서는 일반적인 언어 협상을 적용하지 않습니다. 협상 결과의 언어나 로케일을 보안 결제 확인 대화 상자에 사용하지 않기 때문입니다.

참고: locale은 특정 입력 멤버와 연결된 언어 또는 방향 메타데이터와 다릅니다. 특정 문자열 값에 대한 단언이 아니라 호출자가 요청한 현지화된 경험을 나타내기 때문입니다. 자세한 내용은 § 14 국제화 고려 사항을 참조하시기 바랍니다.

4.9. 결제 가능 여부 확인 단계

이 결제 수단의 결제 가능 여부 확인 단계는 입력 SecurePaymentConfirmationRequest data에 대해 다음과 같습니다.

테스트

data["payeeOrigin"]이 존재하면:
1. parsedURL을 data["payeeOrigin"]에 대해 URL 파서를 실행한 결과로 설정합니다.
2. parsedURL이 실패가 아님을 단언합니다.
3. parsedURL의 스킴이 "https"임을 단언합니다.
참고: 이러한 사전 조건은 앞서 결제 수단 데이터의 유효성을 검사하는 단계에서 확인되었습니다.
1. data["payeeOrigin"]을 parsedURL의 직렬화된 값으로 설정합니다. 출처의 직렬화된 값입니다.
아이콘의 이미지 리소스를 가져옵니다. 이때 «["src" → data["instrument"]["icon"]]» 를 image로 전달합니다. 실패하면:
1. data["instrument"]["iconMustBeShown"]이 true이면 false를 반환합니다.
2. 그렇지 않으면 data["instrument"]["icon"]을 빈 문자열로 설정합니다.
  
  참고: 이를 통해 RP는 지정된 아이콘이 표시되지 않았음을 알 수 있습니다. 출력 instrument에 빈 아이콘 문자열이 포함되기 때문입니다.
참고: 일치하는 자격 증명이 있는지 여부와 관계없이 이미지 리소스를 가져와야 합니다. 이는 자격 증명의 존재 여부를 탐색하려는 시도를 방지하기 위한 것입니다.
선택적으로 사용자 에이전트는 data["paymentEntitiesLogos"]에서 목록의 끝부터 시작 방향으로 항목을 제거할 수 있습니다.

참고: 이를 통해 사용자 에이전트는 표시할 로고의 수를 제어하면서 로고가 호출자에게 표시 우선순위의 내림차순으로 지정되었다는 의미를 유지할 수 있습니다.
data["paymentEntitiesLogos"]의 각 logo에 대해:
1. logo의 이미지 리소스를 가져옵니다. 이때 logo에 대해 «["src" → logo["url"]]» 를 image로 전달하고 결과를 디코딩합니다.
2. 가져오기 또는 디코딩이 실패하면 logo["url"]을 빈 문자열로 설정합니다.
  
  참고: 이를 통해 RP는 지정된 로고가 표시되지 않았음을 알 수 있습니다. 출력 paymentEntitiesLogos 시퀀스에서 해당 로고의 URL 문자열이 비어 있기 때문입니다.
참고: 일치하는 자격 증명이 있는지 여부와 관계없이 로고 리소스를 가져와야 합니다. 이는 자격 증명의 존재 여부를 탐색하려는 시도를 방지하기 위한 것입니다.
data["credentialIds"]의 각 id에 대해:
1. 현재 기기에서 자격 증명을 사용자에게 알리지 않고 사용할 수 있는지 확인하는 단계를 실행합니다. 이때 data["rpId"]와 id를 전달합니다. 결과가 false이면 data["credentialIds"]에서 id를 제거합니다.
2. data["rpId"]가 request의 관련 설정 객체의 출처가 아니라면 SPC 자격 증명의 제3자 사용 허용 여부를 사용자에게 알리지 않고 확인하는 단계를 실행합니다. 이때 data["rpId"]와 id를 전달합니다. 결과가 false이면 data["credentialIds"]에서 id를 제거합니다.
true를 반환합니다.

4.10. 거래 확인 사용자 경험 표시

PaymentRequest.show()가 호출되고 보안 결제 확인 결제 처리기가 선택되면(해당 알고리즘의 19~24단계), 사용자 에이전트는 사용자가 진행 여부와 진행 방법을 선택할 수 있는 사용자 인터페이스를 반드시 제공해야 합니다.

4.10.1. 사용자에게 표시되는 정보

사용자 에이전트 구현의 선택을 제한하지 않기 위해 이 명세에서는 특정 사용자 인터페이스를 표시하도록 요구하지 않습니다. 그러나 신뢰 당사자가 CollectedClientPaymentData에 포함된 정보를 신뢰할 수 있도록, 사용자 에이전트는 다음 정보가 사용자에게 전달되고 인증에 대한 사용자의 동의가 수집되도록 반드시 보장해야 합니다.

payeeName이 존재하는 경우 해당 값입니다.
payeeOrigin이 존재하는 경우 해당 값입니다.
total, 즉 거래의 currency와 value 입니다.
instrument의 세부 정보, 즉 결제 수단의 displayName, details 및 icon입니다. 입력 icon에서 이미지 리소스를 가져오거나 디코딩할 수 없었다면 사용자 에이전트는 아이콘을 표시하지 않거나 대신 일반적인 결제 수단 아이콘을 표시할 수 있습니다.

참고: 지정된 아이콘을 가져오거나 디코딩할 수 없었다면 iconMustBeShown은 여기서 false여야 합니다. 그렇지 않으면 앞서 결제 가능 여부를 확인하는 단계에서 실패했을 것이기 때문입니다.
paymentEntitiesLogos가 비어 있지 않은 경우, 그 안의 url 항목이 나타내는 로고입니다.
- 사용자 에이전트는 각 PaymentEntityLogo의 label을 표시할 필요는 없지만, 접근성 목적으로 사용하는 것이 좋습니다(SHOULD). label은 여전히 CollectedClientAdditionalPaymentData에 포함되어 서명됩니다.

showOptOut이 true이면 사용자 에이전트는 사용자가 주어진 신뢰 당사자에 대한 절차에서 탈퇴할 의사를 표시할 기회를 반드시 제공해야 합니다.

테스트

authentication-optout.https.html (실시간 테스트) (소스)

4.10.2. 거래 확인 사용자 경험의 결과

사용자 에이전트는 사용자가 진행 여부와 진행 방법에 대해 다음 옵션 중 하나를 선택할 수 있도록 반드시 허용해야 합니다.

사용자가 SPC 자격 증명을 사용하여 인증하고 결제를 진행하려는 경우,

사용자가 상호 작용하고 있는 PaymentRequest에 대해 사용자가 결제 요청을 수락하는 알고리즘을 실행합니다.

사용자가 결제를 진행하려고 하지만 data["credentialIds"]가 비어 있어 사용할 수 없거나 SPC 자격 증명을 사용하고 싶지 않은 경우,

다음 단계를 실행합니다.

data["credentialIds"]를 빈 목록으로 설정합니다.

참고: 이로 인해 PaymentRequest.show()의 Promise가 "NotAllowedError" DOMException으로 거부됩니다. § 4.11 결제 요청에 응답하는 단계를 참조하시기 바랍니다.
사용자가 상호 작용하고 있는 PaymentRequest에 대해 사용자가 결제 요청을 수락하는 알고리즘을 실행합니다.

테스트

authentication-auth-another-way.https.html (실시간 테스트) (소스)

사용자가 결제를 진행하고 싶지 않은 경우,

사용자가 상호 작용하고 있는 PaymentRequest에 대해 사용자가 결제 요청을 중단하는 알고리즘을 실행합니다.

참고: 이로 인해 PaymentRequest.show()의 Promise가 "AbortError" DOMException으로 거부됩니다.

사용자가 주어진 신뢰 당사자에 대한 절차에서 탈퇴하려는 경우,

PaymentRequest.show()를 "OptOutError" DOMException으로 거부합니다. § 12.7 사용자 탈퇴를 참조하시기 바랍니다.

참고: 이 옵션은 showOptOut이 true로 설정된 경우에만 사용자에게 제공해야 합니다.

4.10.3. 테스트 자동화 지원

현재 거래 자동화 모드가 "none"이 아니면 사용자 에이전트는 먼저 자동화 컨텍스트에 있는지 확인하는 것이 좋습니다( WebDriver의 보안 고려 사항 참조). 그런 다음 사용자 에이전트는 앞서 설명한 정보 전달과 사용자 동의 수집을 건너뛰고, 대신 현재 거래 자동화 모드의 값에 따라 다음을 수행하는 것이 좋습니다.

"autoAccept": 사용자가 거래 세부 정보를 확인하고 수락한 것처럼 동작합니다.
"autoChooseToAuthAnotherWay": 사용자가 거래 세부 정보를 확인하고 수락했지만 인증에 SPC 자격 증명을 사용하고 싶지 않다고 표시한 것처럼 동작합니다. data["credentialIds"]가 비어 있으면 "autoAccept"와 동일합니다.
"autoReject": 사용자가 거래 세부 정보를 확인하고 거부한 것처럼 (즉, 거래를 계속하고 싶지 않은 것처럼) 동작합니다.
"autoOptOut": 사용자가 거래 세부 정보를 확인하고 탈퇴 의사를 표시한 것처럼 동작합니다.

4.11. 결제 요청에 응답하는 단계

이 결제 수단의 결제 요청에 응답하는 단계는 주어진 PaymentRequest request와 SecurePaymentConfirmationRequest data에 대해 다음과 같습니다.

참고: 이 단계는 사용자가 거래 확인 사용자 경험을 수락한 경우에만 실행됩니다. 사용자가 결제 요청을 수락하는 알고리즘에서 호출됩니다.

data["credentialIds"]가 비어 있으면 "NotAllowedError" DOMException을 발생시킵니다. 이는 사용자가 SPC를 사용하여 인증할 수 없거나 사용하고 싶지 않은 경우에도 인증 절차의 개인정보 보호를 유지하기 위한 것입니다.

참고: 여기서 예외를 발생시키면 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에 대해 하나의 URL만 지원하므로 데이터 구조를 그대로 복사하고 서명하는 것만으로 사용자에게 표시된 내용을 나타내기에 충분합니다. 향후 이 명세의 버전에서는 다크 모드를 기본적으로 지원하는 등의 목적으로 각 PaymentEntityLogo에 여러 URL을 추가할 수 있습니다. 그렇게 되면 명세는 특정 PaymentEntityLogo에 대해 어떤 URL이 표시되었는지 신뢰 당사자에게 알려야 합니다.

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. descriptor를 publicKeyOpts["allowCredentials"]에 추가합니다.
outputCredential을 «["publicKey" → publicKeyOpts]»를 전달하여 자격 증명 요청 알고리즘을 실행한 결과로 설정합니다.

참고: Chrome의 초기 구현은 전체 data.credentialIds 목록을 자격 증명 요청에 전달하지 않습니다. 대신 목록에서 현재 기기와 일치하는 자격 증명 하나를 선택하여 그것만 전달합니다.

참고: 이는 [webauthn-3]의 Get 동작을 트리거합니다.
outputCredential을 반환합니다.

5. WebAuthn 확장 - "`payment`"

이 클라이언트 등록 확장과 인증 확장은 각각 자격 증명이 보안 결제 확인을 위해 생성되거나 사용되고 있음을 나타냅니다.

등록 시 이 확장을 통해 브라우저는 보안 결제 확인 자격 증명 ID를 식별하고 캐시할 수 있습니다. 인증 시 이 확장을 통해 제3자가 신뢰 당사자를 대신하여 인증 절차를 수행할 수 있으며, 서명된 암호문에 거래 정보도 추가됩니다.

특히 웹사이트는 이 확장을 사용하여 navigator.credentials.get()를 직접 호출해서는 안 됩니다. 인증 시 이 확장에는 "secure-payment-confirmation" 결제 수단을 지정한 PaymentRequest를 통해서만 접근할 수 있습니다.

참고: 이전에는 payment 확장이 교차 출처 iframe에서 자격 증명을 생성할 수 있도록 허용했습니다. 하지만 WebAuthn PR #1801 이후 WebAuthn에서는 이 동작을 기본적으로 허용합니다.

테스트

이 테스트는 명세의 특정 행에 직접 대응하지 않고, 대신 교차 출처 iframe 내부에서 인증을 시작할 수 있는지 확인합니다. 이 동작은 이를 금지하는 규정이 없다는 사실로 명시됩니다.

authentication-in-iframe.sub.https.html (실시간 테스트) (소스)

확장 식별자

payment

적용 가능한 작업

등록 및 인증

클라이언트 확장 입력

partial dictionary AuthenticationExtensionsClientInputs {
  AuthenticationExtensionsPaymentInputs payment;
};

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

  // 인증에만 사용됩니다.
  USVString rpId;
  USVString topOrigin;
  USVString payeeName;
  USVString payeeOrigin;
  sequence<PaymentEntityLogo> paymentEntitiesLogos;
  PaymentCurrencyAmount total;
  PaymentCredentialInstrument instrument;
};

isPayment

확장이 활성화되어 있음을 나타냅니다.

rpId