- From: Erik Wilde <notifications@github.com>
- Date: Thu, 21 Apr 2016 17:11:40 -0700
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Cc:
- Message-ID: <w3c/browser-payment-api/issues/150/213167722@github.com>
On 2016-04-21 14:27, Dave Longley wrote: > That isn't the only thing you can get from machine readable data. What > if you just want to get descriptions or icons? What if there are terms > of use or rules that indicate you must display brand image X (found at a > URL specified in the machine readable data) when offering a payment method? then these are all things that the registration process has to define and has to make sure that all this information is made available when the scheme is registered. what if the dynamically loaded data changes? do the terms of the payment service change because the data referenced by the payment identifier changed? if that's the case, then very clearly the payment identifier is not a self-describing identifier anymore, but the relevant data is the data that's dereferenced. that's a very different architecture from having self-describing identifiers. both are possible ways to design such a facility, but it should be crystal clear which route is taken, and how clients are supposed to use the identifiers. --- 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/browser-payment-api/issues/150#issuecomment-213167722
Received on Friday, 22 April 2016 00:12:21 UTC