결제 수단 매니페스트

이 문서의 상태

HEAD / HTTP/2
Host: alicepay.com
User-Agent: Mellblomenator/9000

HTTP/2 204
Link: </pay/payment-manifest.json>; rel="payment-method-manifest"

{
  "default_applications": ["https://alicepay.com/pay/app/webappmanifest.json"],
  "supported_origins": [
    "https://bobpay.xyz",
    "https://alicepay.friendsofalice.example"
  ]
}

2. 매니페스트 형식

유효한 결제 수단 매니페스트 파일은 JSON 객체로 구문 분석 가능한 내용을 포함하는 UTF-8 인코딩 파일이다. 결과 JSON 객체는 가능한 키 "default_applications" 및 "supported_origins"를 사용하여 최대 두 개의 항목을 포함해야 한다.

default_applications 키의 값이 존재하는 경우, 비어 있지 않은 JSON 배열이어야 한다. 배열의 각 항목은 결과로 구문 분석된 URL의 스킴이 "https"인 절대-URL 문자열이어야 한다.

supported_origins 키의 값이 존재하는 경우, 문자열 "*"이거나 비어 있지 않은 JSON 배열이어야 한다. 후자의 경우, 배열의 각 항목은 HTTPS 출처를 나타내는 절대-URL 문자열이어야 한다. 형식적으로, 해당 문자열은 결과로 구문 분석된 URL의 출처를 직렬화한 것과 같아야 한다.

웹 개발자는 모든 결제 수단 매니페스트가 유효하도록 보장해야 한다.

파일 내용에 대한 모든 적합성 요구사항과 마찬가지로, 이것들은 구현자 대상이 아니라 웹 개발자 대상이다. §3 처리 모델에 제시된 정확한 처리 모델이 유효하지 않은 것을 포함하여 모든 결제 수단 매니페스트 파일을 구현자가 처리하는 방식을 지배한다.

{
  "default_applications": ["https://alicepay.com/pay/app/webappmanifest.json"],
  "created_by": "Alice",
  "created_in": "Wonderland"
}

3. 처리 모델

3.1. Payment Request API에 대한 수정

이 명세는 PaymentRequest(methodData, details, options) 생성자를 수정하여 Payment Request 생태계의 나머지 부분과 통합된다. 알고리즘이 완료되어 새로 생성된 PaymentRequest 객체를 반환하기 전에 다음 단계를 추가한다. 다음에서 request를 생성 중인 PaymentRequest 인스턴스라고 하자. [PAYMENT-REQUEST]

1. identifiers를 request.[[serializedMethodData]] 안의 각 쌍의 첫 번째 항목으로 구성된 목록이라고 하자.

2. client를 현재 설정 객체라고 하자.

3. identifiers와 client가 주어졌을 때 결제 수단 매니페스트를 수집한다.

이 단계들이 전체 과정을 시작한다. §3 처리 모델의 나머지는 이 과정이 궁극적으로 사용자에게 새로운 결제 앱을 사용할 수 있게 하는 방식의 정의와 관련된다.

이 명세가 여러 구현자의 관심을 얻게 되면, 이 절을 여기서 monkeypatch로 유지하는 대신 Payment Request API 명세 자체로 옮길 것으로 예상한다.

3.2. 결제 수단 매니페스트 수집

결제 수단 식별자 목록 identifiers와 환경 설정 객체 client가 주어졌을 때, 사용자 에이전트는 결제 수단 매니페스트를 수집하기 위해 다음 단계를 실행할 수 있다:

1. identifiers와 client가 주어졌을 때 결제 수단 매니페스트를 가져오고, 이것이 manifestsMap으로 비동기적으로 완료될 때까지 기다린다. 결과가 실패이면 반환한다.

2. manifestsMap의 각 identifier → manifest에 대해 반복한다:

   1. parsed를 manifest를 검증 및 구문 분석한 결과라고 하자. 이것이 실패를 반환하면 continue한다.

   2. parsed의 기본 애플리케이션 안의 각 url에 대해 반복한다:

      1. client가 주어졌을 때 url의 웹 앱 매니페스트를 가져오고, 그것이 webAppManifestString으로 비동기적으로 완료될 때까지 기다린다. 결과가 실패이면 continue한다.

      2. webAppManifest를 webAppManifestString이 주어졌을 때 웹 앱 매니페스트 처리 단계를 실행한 결과라고 하자.

         웹 앱 매니페스트 처리 단계는 매우 관대하며, 실패하는 대신 빈 객체 또는 중요한 필드가 빠진 객체를 반환한다. 사용자 에이전트는 다음 단계에서 자신의 목적에 충분한 데이터를 포함하는지 확인하기 위해 처리된 웹 앱 매니페스트를 별도로 검증해야 한다.

      3. 사용자 에이전트 고유의 방식으로, 결과 처리된 웹 앱 매니페스트 webAppManifest를 사용하여 identifier로 식별되는 결제 수단에 적용 가능한 결제 앱을 설치한다.

         향후에는 그 serviceworker 필드를 참조하고, 이를 사용하여 Payment Handler API 명세에 부합하는 웹 기반 결제 앱을 설치함으로써 결과 처리된 웹 앱 매니페스트를 사용자 에이전트와 독립적인 방식으로 사용할 수 있게 하는 것이 계획이다. [PAYMENT-HANDLER]

   3. 지원되는 출처를 identifier와 연결하여, 사용자 에이전트가 나중에 이를 사용해 identifier로 식별되는 결제 수단에 표시할 수 있는 제3자 결제 앱을 결정할 수 있도록 한다.

3.3. 결제 수단 매니페스트 가져오기

목록의 JavaScript 문자열 supportedMethods와 환경 설정 객체 client가 주어졌을 때, 결제 수단 매니페스트를 가져오려면 다음 단계를 수행한다. 이 알고리즘은 맵(비어 있을 수 있음)으로 비동기적으로 완료되며, 이는 URL에서 바이트 시퀀스로의 맵으로, 결제 수단 식별자를 해당 매니페스트의 내용에 매핑한다.

1. identifierURLs를 빈 목록이라고 하자.

2. supportedMethods의 각 string에 대해 반복한다:

   1. identifierURL을 string을 기본 URL 구문 분석한 결과라고 하자. 결과가 실패이면 continue한다.

      결과는 URL 기반 결제 수단 식별자가 아닌 모든 결제 수단 식별자, 즉 표준화된 결제 수단 식별자에 대해 실패가 된다.

   2. identifierURL을 검증한 결과가 false이면, continue한다.

   3. 선택적으로, continue한다.

      이 단계는 구현이 사용자 에이전트 고유의 이유로 제공된 결제 수단 식별자 중 일부를 건너뛸 수 있게 한다. §4 보안 및 개인정보 고려사항은 사용자 에이전트가 특정 식별자만 수집하는 것을 선호할 수 있는 몇 가지 이유를 논의한다.

   4. identifierURL을 identifierURLs에 추가한다.

3. manifestsMap을 빈 맵이라고 하자.

4. identifierURLs의 각 identifierURL에 대해 반복한다:

   1. identifierRequest를 요청으로 새로 만들되, 그 메서드는 `HEAD`, url은 identifierURL, client는 client, mode는 "cors", credentials mode는 "omit", redirect mode는 "error"로 한다.

   2. identifierRequest를 Fetch한다. 응답 identifierResponse로 process response하려면:

      1. identifierResponse가 네트워크 오류이거나 identifierResponse의 상태가 ok 상태가 아니면 continue한다.

      2. linkHeaders를 `Link`와 identifierResponse의 헤더 목록이 주어졌을 때 헤더 목록 값 추출의 결과라고 하자.

      3. manifestURLString을 null이라고 하자.

      4. linkHeaders의 각 linkHeader에 대해 반복한다:

         1. linkHeader를 link-value production에 따라 구문 분석한다. 구문 분석할 수 없으면 continue한다. [RFC8288]

         2. 구문 분석된 헤더가 이름이 문자열 "rel"과 ASCII 대소문자 구분 없는 일치이고, 값이 문자열 "payment-method-manifest"와 ASCII 대소문자 구분 없는 일치인 매개변수를 포함하면, manifestURLString을 구문 분석된 헤더의 URI-Reference production이 제공하는 문자열로 설정하고 break한다.

      5. manifestURLString이 null이 아니면:

         1. manifestURL을 identifierResponse의 url이 제공한 base URL로 manifestURLString을 기본 URL 구문 분석한 결과라고 하자. 결과가 실패이면 continue한다.

         2. manifestURL의 스킴이 "https"가 아니면 continue한다.

         3. manifestRequest를 요청으로 새로 만들되, 그 url은 manifestURL, client는 client, mode는 "cors", credentials mode는 "omit", redirect mode는 "error"로 한다.

         4. manifestRequest를 Fetch한다. 응답 manifestResponse로 process response end-of-body하려면:

            1. manifestResponse가 네트워크 오류이거나 manifestResponse의 상태가 ok 상태가 아니면 continue한다.

            2. body를 manifestResponse의 body라고 하자.

            3. body가 null이면 continue한다.

            4. reader를 body에서 reader를 가져온 결과라고 하자.

            5. promise를 reader로 body에서 모든 바이트 읽기를 수행한 결과라고 하자.

            6. promise가 바이트 시퀀스 bytes로 fulfillment되면, manifestsMap[identifierURL]을 bytes로 설정한다.

5. 위 단계에서 시작된 모든 진행 중인 fetch 알고리즘이 완료되면, 지정된 process response 및 process response end-of-body 단계를 포함하여, 이 알고리즘을 manifestsMap으로 비동기적으로 완료한다.

3.4. 결제 수단 매니페스트 검증 및 구문 분석

구문 분석된 결제 수단 매니페스트는 두 필드를 포함하는 구조체이다:

기본 애플리케이션

URL의 정렬된 집합, 비어 있을 수 있음

지원되는 출처

문자열 "*" 또는 출처의 정렬된 집합

결제 수단 매니페스트를 포함한다고 주장하는 바이트 시퀀스 bytes를 검증 및 구문 분석하려면, 다음 단계를 수행한다. 결과는 구문 분석된 결제 수단 매니페스트 또는 실패이다.

1. parsed를 사용자 에이전트가 정의한 JavaScript realm에서 bytes가 주어졌을 때 바이트에서 JSON 구문 분석을 수행한 결과라고 하자. 이것이 예외를 throw하면 실패를 반환한다.

2. Type(parsed)이 Object가 아니면 실패를 반환한다.

3. defaultApps를 빈 정렬된 집합이라고 하자.

4. defaultAppsValue를 Get(parsed, "default_applications")이라고 하자.

5. defaultAppsValue가 undefined가 아니면:

   1. IsArray(defaultAppsValue)가 false이면 실패를 반환한다.

   2. defaultAppsList를 CreateListFromArrayLike(defaultAppsValue, « String »)이라고 하자. 이것이 예외를 throw하면 실패를 반환한다.

   3. defaultAppsList의 크기가 0이면 실패를 반환한다.

   4. defaultAppsList의 각 defaultAppString에 대해 반복한다:

      1. defaultAppURL을 defaultAppString을 기본 URL 구문 분석한 결과라고 하자. 결과가 실패이면 실패를 반환한다.

      2. defaultAppURL의 스킴이 "https"가 아니면 실패를 반환한다.

      3. defaultAppURL을 defaultApps에 추가한다.

6. supportedOrigins를 빈 정렬된 집합이라고 하자.

7. supportedOriginsValue를 Get(parsed, "supported_origins")이라고 하자.

8. supportedOriginsValue가 "*"이면, supportedOrigins를 "*"로 설정한다.

9. 그렇지 않고 supportedOriginsValue가 undefined가 아니면:

   1. IsArray(supportedOriginsValue)가 false이면 실패를 반환한다.

   2. supportedOriginsList를 CreateListFromArrayLike(supportedOriginsValue, « String »)이라고 하자. 이것이 예외를 throw하면 실패를 반환한다.

   3. supportedOriginsList의 크기가 0이면 실패를 반환한다.

   4. supportedOriginsList의 각 supportedOriginString에 대해 반복한다:

      1. supportedOriginURL을 supportedOriginString을 기본 URL 구문 분석한 결과라고 하자. 결과가 실패이면 실패를 반환한다.

      2. supportedOriginURL의 스킴이 "https"가 아니면 실패를 반환한다.

      3. supportedOriginURL의 username 또는 password가 빈 문자열이 아니면 실패를 반환한다.

      4. supportedOriginURL의 path의 크기가 0이 아니면 실패를 반환한다.

      5. supportedOriginURL의 query 또는 fragment가 null이 아니면 실패를 반환한다.

      6. supportedOriginURL의 origin을 supportedOrigins에 추가한다.

10. defaultApps가 제공한 기본 애플리케이션과, supportedOrigins가 제공한 지원되는 출처를 가진 새 구문 분석된 결제 수단 매니페스트를 반환한다.

{
  "default_applications": ["https://alicepay.com/pay/app/webappmanifest.json"],
  "supported_origins": []
}

3.5. 웹 앱 매니페스트 가져오기

결제 앱의 결정이 임베딩된 HTML 문서와 독립적으로 발생하기 때문에, 기본 결제 앱에 대한 정보를 제공하는 웹 앱 매니페스트를 얻는 절차는 일반적인 웹 앱 매니페스트를 얻는 단계와 다르다.

URL url 및 환경 설정 객체 client가 주어졌을 때, 기본 결제 앱의 웹 앱 매니페스트를 가져오려면 다음 단계를 수행한다. 이 알고리즘은 스칼라 값 문자열 또는 실패로 비동기적으로 완료된다.

1. request를 요청으로 새로 만들되, 그 url은 url, client는 client, mode는 "cors", credentials mode는 "omit", redirect mode는 "error"로 한다.

2. request를 Fetch한다. 응답 response로 process response end-of-body하려면:

   1. response가 네트워크 오류이거나 response의 상태가 ok 상태가 아니면, 이 알고리즘을 실패로 비동기적으로 완료한다.

   2. body를 response의 body라고 하자.

   3. body가 null이면, 이 알고리즘을 실패로 비동기적으로 완료한다.

   4. reader를 body에서 reader를 가져온 결과라고 하자.

   5. promise를 reader로 body에서 모든 바이트 읽기를 수행한 결과라고 하자.

   6. promise가 바이트 시퀀스 bytes로 fulfillment되면, 이 알고리즘을 bytes를 UTF-8 디코딩한 결과로 비동기적으로 완료한다.

   7. promise가 rejection되면, 이 알고리즘을 실패로 비동기적으로 완료한다.

4. 보안 및 개인정보 고려사항

결제 수단 매니페스트 수집은 최종 사용자의 활동에 관한 정보를 결제 서비스에 드러낼 수 있다. 예를 들어, 하나의 웹사이트에서만 지원되는 결제 수단은 해당 결제 제공자가 그 웹사이트를 방문하는 사용자의 IP 주소를 알아낼 수 있게 할 수 있다.

이를 완화하는 한 가지 방법은 사용자가 설치했거나 명시적으로 관심을 표현한 결제 앱에 대해서만 매니페스트를 가져오는 것이다. 이는 사용자의 IP 주소를 해당 당사자들과만 공유하도록 위험을 제한한다.

5. IANA 고려사항

5.1. payment-method-manifest 링크 관계

이 등록은 커뮤니티 검토를 위한 것이며, 검토, 승인, 그리고 IANA 등록을 위해 IESG에 제출될 것이다.

관계 이름

payment-method-manifest

설명

Web Payments 생태계 안의 특정 결제 수단을 설명하는 결제 수단 매니페스트로 연결한다.

참조

https://w3c.github.io/payment-method-manifest/

참고

이러한 링크가 가져와질 것으로 예상되는 구체적인 방식은 §3.3 결제 수단 매니페스트 가져오기를, 그것들이 사용되는 더 큰 맥락은 §3.2 결제 수단 매니페스트 수집을 참조한다.

감사의 말

§3 처리 모델은 Rouslan Solomakhin이 원래 개요를 작성한 알고리즘에 크게 기반한다.