- From: David Nicol <davidnicol@gmail.com>
- Date: Sat, 12 May 2012 02:33:13 -0500
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Dave Raggett <dsr@w3.org>, public-webpayments@w3.org, Alan Bird <abird@w3.org>
- Message-ID: <CAFwScO_=VOmMA-9GMBz3015Zmq_JFWozWZd_uchfbHt+yqsjZg@mail.gmail.com>
On Fri, May 11, 2012 at 2:57 PM, Manu Sporny <msporny@digitalbazaar.com>wrote: > > > I suspect that a whitelist of services provided by the website > > hosting the web app may prove practical especially for solutions > > built around debit and credit cards whether physical or virtual (as > > in eWallets). It is also possible to imagine trusted third parties > > that bridge between services, thereby indirectly expanding the > > coverage of a white list. The concept of a white list is an > > interesting contribution to the discussion on Web Intents. > > Sure, but as I said in the previous e-mail, this problem is a bit harder > than it seems at first. For example, it requires websites to keep their > whitelist up-to-date and that's not always practical for all websites. > There are many ways to go about this, but the place we have to end up is > something equivalent to or /simpler/ than the current state of the art. > > A benefit of distributed whitelists is that the choice of who to trust > is left to the web app - this is good (and is what we do in PaySwarm). > However, a down-side is that the website might not update their > whitelist and lose out on customers. > > So, it's not only about the whitelist - but how the whitelist is updated > and how that impacts the customer's experience. If the whitelist is > centrally controlled (which might lead to the best customer experience) > - then listing how systems qualify for being added to the whitelist > becomes very important as you don't want the larger players raising the > bar such that the smaller players aren't allowed to compete. it seems to me that a good way forward is, rather than defining *the* whitelist, instead define *how* one consults a whitelist, and let whitelists compete. A working example of this approach is documentation of interoperable standards for RBL lists for spam mitigation. Although letting caveat emptor and organic reputation just work itself out also seems like a winner. The point about established players being opposed to interoperability is excellent and valid. -- "Oblige a man to rise at four in the morning, and it is more than probable he will go willingly to bed at eight in the evening; and, having had eight hours sleep, he will rise more willingly at four in the morning following." -- Benjamin Franklin
Received on Saturday, 12 May 2012 07:33:43 UTC