STATUS: No consensus.
Questions? ij@w3.org

===========
Goals for second half of 2020:

 - Drive adoption of Web payments APIs
 - Improve privacy characteristics of APIs
 - Monitor and provide guidance about managing payments
   use cases (e.g., risk assessment) in light of browser changes
   around cookies, fingerprinting.
 - FPWD of SRC payment method specification (not described here)
 - (Stretch) Provide path forward for dynamic linking use case.
 
--------------------------
Changes to Payment Request

- Simplify PR API (v 1.0)

  Pros:
    * Easier for browsers to implement
    * Eliminates privacy issue related to incremental request for address info
      https://github.com/w3c/payment-request/pull/873
    * Improves privacy by reducing some cross-origin communication
  Cons:
    * No longer fulfills guest checkout use case in one call.
    * May lead to incompatibilities with some implementations (e.g., Webkit
      for Apple Pay)
  Notes:
    * Payment apps wish to manage shipping, contact info, etc.
  Proposed:
    * Remove top-level flags
    * Define flags in the payment method, so becomes part of payment data

- Require user consent before hasEnrolledInstrument can return true

  Pros:
    * Improved protection for user privacy
    * May simplify browser implementation if other mitigations not
      required.
    * Keeps the functionality, which PSPs have cited as valuable.
  Cons:
    * Additional friction at first transaction
  Proposed:
    * Integrate consent as part of registration ceremony.

- Validate that 1p cookie storage is available through registration flows
    with user consent.

  Pros:
    * Improved privacy through consent
    * Meets industry needs for cross-origin risk assessment.
  Cons:
    * Additional friction at first transaction
  Proposed:
    * Integrate consent as part of registration ceremony.


--------------------------
Changes to Payment Handler

- Define openMinimalWindow method on PaymentRequestEvent. 

  Pros:
    * Allows streamlined UX including authentication.
    * Allows merchants to express preference for that known UX.
  Proposed:
    * See [1].
    * Payment app invokes openMinimalWindow when merchant
      expresses that preference.
    * The browser must implement:
      a) Display of total, beneficiary, and instrument
      b) Selection of instrument (with default shown)
      c) Authentication prompt. We imagine an enumeration of
         options, such as WebAuthn, QR code, and OTP. In each
	 case, the browser would not display arbitrary content.
	 Labels would be pre-defined and i18n-able.
	 For example, the browser would:
	   - For WebAuthn, all call and display authenticator prompt
	   - For OTP, provide an input form
	   - For QR Code, display an image computed by the payment app.
    * If the payment app does not succeed, then "fails" and merchant
      can call PR API with other options (e.g., without asking for minimal
      UI, so payment app could then use openWindow).

  Questions:
    * What is the (new) role of PaymentInstruments if instrument selection
      is a requirement in the UI?

      [1] https://github.com/w3c/webauthn-pay/blob/gh-pages/proposals/pr-webauthn-txconf.md

- TODO: Prioritize other PH API issues
   https://github.com/w3c/payment-handler/issues/

- TODO: Prioritize privacy threat analysis mitigations
   https://w3c.github.io/webpayments/proposals/privacy-threat-model.html

--------------------------
Changes to Web Authentication

- Transaction Confirmation (Stretch Goal)
           
  Pros:
    * Would satisfy PSD2 use case
  Proposed:
    * See [1].
    * Have browsers implement txAuthSimple [2] where the string is created
      by the browser from:
         - The origin of the party that called PR API
	 - The origin of the payment app
	 - The total that is part of PR API.
    * Question: Are there authenticators that support this extension?


  [2] https://www.w3.org/TR/webauthn/#sctn-simple-txauth-extension