Re: [w3c/webpayments-payment-apps-api] Revisiting payment app filtering (#96)

Was web crypto considered? I've not done the work yet to see how it would work to encrypt ".data", but might save me some time exploring that rabbit hole if someone else has already evaluated it. 

> On 28 Jan 2017, at 12:17 am, Adrian Hope-Bailie <notifications@github.com> wrote:
> 
> For some context, this is a requirement that has migrated from the payment request discussions to here because the editors/implementors felt a "generic" filtering algorithm was a bad idea.
> 
> I stand to be corrected but I think @zkoch made the statement that the security team at Google were not happy with the idea of processing filters that were not from a predefined set.
> 
> As such, browsers will natively support SOME filtering for well-known payment methods (like basic-card) but there was no mechanism for developers of new payment methods (like https://bobpay.com) to define their own method-specific filters.
> 
> @ianbjacobs , @mattsaxon and I spent a lot of time proposing ideas on how this might work. It went from query string params in the identifier to stand-alone filter data in the PaymentMethodData as @adamroach describes above.
> 
> I would agree that if we can come up with a config only way for this to work then that would be first prize but it would be useful to hear from the implementors if this is something they would support.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-275676089