public-webpayments-specs@w3.org from August 2016 by subject

[w3c/browser-payment-api] "Incognito mode" notes (#238)

[w3c/browser-payment-api] Add Guidance Text for Incognito Mode (#230)

[w3c/browser-payment-api] Add Guidance Text for User Consent (#229)

[w3c/browser-payment-api] Add links into Github (#226)

[w3c/browser-payment-api] Add security text regarding payment apps and phishing (#233)

[w3c/browser-payment-api] an event to providing standards for push payment methods (#223)

[w3c/browser-payment-api] Annotate all interfaces with SecureContext (#241)

[w3c/browser-payment-api] Cannot use 2119 terms in notes (#240)

[w3c/browser-payment-api] Change “MUST…to be valid” to just “are required” (#236)

[w3c/browser-payment-api] Clarify that HTTPS is required to use the API (#232)

[w3c/browser-payment-api] Clear pointer to GitHub at the top (#239)

[w3c/browser-payment-api] Expand Privacy Considerations Section (#228)

[w3c/browser-payment-api] Expand Security Considerations Section (#231)

[w3c/browser-payment-api] If a card payment fails, should we support exclusion of that card instrument from matching? (#237)

[w3c/browser-payment-api] Make ISO4217 an informative reference rather than normative (#242)

[w3c/browser-payment-api] Normative References (#227)

[w3c/browser-payment-api] Should the API support field validation? (#225)

[w3c/browser-payment-api] Should the messages support field-level encryption? (#55)

[w3c/browser-payment-api] Should the Payment Request API only be available in a top-level browsing context? (#2)

[w3c/browser-payment-api] Specify UA requirements if “id” field of PaymentShippingOption is not unique (#243)

[w3c/browser-payment-api] Supporting push payment methods (#224)

[w3c/browser-payment-api] U (#234)

[w3c/browser-payment-api] Unambiguously specify UA requirements for instances that are not valid (#235)

[w3c/webpayments-method-identifiers] Add Security Considerations and Privacy Considerations sections (#7)

[w3c/webpayments-method-identifiers] Identifier equivalence does not handle failure (#8)

[w3c/webpayments-method-identifiers] Resolve whether browsers need to police payment app claims of supported methods (#11)

[w3c/webpayments-method-identifiers] Should a payment method identifier that is a URL bind that payment method to a single payment app or origin? (#12)

[w3c/webpayments-method-identifiers] update pmi spec with apen and proprietary payment method identifiers (#10)

[w3c/webpayments-method-identifiers] Why URLs? (#9)

[w3c/webpayments-methods-card] Add privacy and security considerations (#7)

[w3c/webpayments-methods-card] Add privacy and security section (#8)

[w3c/webpayments-methods-card] Add Security Considerations and Privacy Considerations sections (#6)

[w3c/webpayments-methods-card] Editorial suggestions (#9)

[w3c/webpayments-methods-card] Leave Off Unneeded Information (#5)

[w3c/webpayments-methods-card] Storing card information (#2)

[w3c/webpayments-payment-apps-api] Add "incognito mode" text (#31)

[w3c/webpayments-payment-apps-api] Add issue 127 mention (#29)

[w3c/webpayments-payment-apps-api] Addition of new design considerations (#19)

[w3c/webpayments-payment-apps-api] Analyse security properties of payment app execution environment (#23)

[w3c/webpayments-payment-apps-api] Case sensitive doc type (ED) (#18)

[w3c/webpayments-payment-apps-api] Communication between JS PaymentApps and the User Agent (#26)

[w3c/webpayments-payment-apps-api] Design considerations for payment app registration: recommended apps, user consent, and optional registration (#21)

[w3c/webpayments-payment-apps-api] Extending invocation of payment apps with other techniques than HTTP (#10)

[w3c/webpayments-payment-apps-api] Fixes (#16)

[w3c/webpayments-payment-apps-api] High-level proposal for general shape of JS API (#25)

[w3c/webpayments-payment-apps-api] How can we optimize user experience when there is only one match? (#14)

[w3c/webpayments-payment-apps-api] Is the concept of payment app registration necessary? (#8)

[w3c/webpayments-payment-apps-api] Markup fixes (#15)

[w3c/webpayments-payment-apps-api] Note on usability/security tension around registration (#30)

[w3c/webpayments-payment-apps-api] Remove accepted payment app concept (#22)

[w3c/webpayments-payment-apps-api] Remove async perhaps to help with rendering (#17)

[w3c/webpayments-payment-apps-api] Require secure contexts for web-based payment apps (#24)

[w3c/webpayments-payment-apps-api] Should merchants be able to limit matching to trusted apps? (#1)

[w3c/webpayments-payment-apps-api] Should origin information (about the payment request) be shared with the payment app? (#27)

[w3c/webpayments-payment-apps-api] Should payment instrument details be included at registration? (#12)

[w3c/webpayments-payment-apps-api] Should the browser pass user data it has collected (email etc) to the payment app? (#13)

[w3c/webpayments-payment-apps-api] Should we distinguish the identifier for a payment app from the identifier for the app server that processes payments? (#20)

[w3c/webpayments-payment-apps-api] The relationship between payment apps and service workers (#33)

[w3c/webpayments-payment-apps-api] Two origin-related additions (#32)

[w3c/webpayments-payment-apps-api] Updates from Tommy's feedback (#28)

[w3c/webpayments-payment-apps-api] What should be the user experience when an app is recommended for two methods? (#11)

[w3c/webpayments-payment-apps-api] “Security Error” on different origins (#9)

Last message date: Wednesday, 31 August 2016 22:39:30 UTC