- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sun, 4 May 2014 22:37:09 +0200
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Timothy Holborn <timothy.holborn@gmail.com>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKaEYhKF7XFAMd1oGOC0HZdV-AHtwCMdxRRKnHt=Rh-v_j9duQ@mail.gmail.com>
On 2 May 2014 06:56, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: > I'm a bit worried that the idea of blending payment transactions and > identity may open a can of worms for which we have no cure. > The internet standards community is very picky about privacy these days > which essentially means the less identity information the better. > > Current EMV (card) transactions do (AFAIK) not provide any identity > information except card number which is really just an account. > > I would at least try to specify in detail what identity may be needed for > a specific payment scenario. > 1. Initially, you have a real world identity, as you might expect. 2. You have a digital identifier which is a string of characters that denotes your identity. 3. The only sane way to standardize this is to use a URI (or IRI) as this identifier. 4. You can go into details of which kind of URIs are preferred in which cases, or which will be implemented first (of course, we want HTTP URIs being a W3C group). If this had been done already, it would be possible to reuse something. But it's only done in WebID, to date. Every other identity system is either woolly, they dont know, or non standard. It's essential with payments to send the right money to the right place. So it's important to be precise here, or money will get lost. > > Cheers > Anders > > On 2014-05-01 09:12, Timothy Holborn wrote: > > Sent from my iPad > > > >> On 1 May 2014, at 5:05 pm, Anders Rundgren < > anders.rundgren.net@gmail.com> wrote: > >> > >>> On 2014-05-01 07:53, Timothy Holborn wrote: > >>> > http://www.zdnet.com/cba-launches-cardless-atm-cash-withdrawal-service-7000028914/ > >> thanx Tim, this is really interesting! > >> > >>> Implications > >>> 1. A definition of a "wallet" > >>> 2. Banking based interface for CNP (card not present) payments > (receipt might be adapted via www of merchant system. How's it tag the > account / transaction, then link it back to a web-payments account system? ) > >>> > >>> 3. If user can connect the "app id" to an online "web payments > enabled" profile, then > >>> > >>> A. transaction related data could be facilitated to an online account > >>> B. how could a merchants online environment and crm be linked to > physical retail environments? > >>> C. KYC issue seems to be sorted? > >> Regarding KYC I remain fix in my belief that this has no room in a > payment standard. > >> > >> Banks do not generally share customer info between each other and > certainly not with merchants. > >> Not to mention that the amount of KYC and how you obtain it varies > widely. > >> Paypal's scheme using a credit-card transaction + email round-trip is > an example of a smart but still highly specific KYC method. > >> > >> Anders > > Perhaps, maintaining KYC, rather than establishing it specifically, in > this business case. KYC is probably the wrong term, but should explain the > concept adequately. > > > > WoT (web of trust), httpa (http accountability) - all similar concepts. > > > > Accounts will trade data without a banking gateway. This could be > deemed a form of improvement to emailing market sensitive information to > involved parties. > > > >>> Nb: web2 portals trade on user-data (insights, etc.) as part of the > ARPU (average revenue per user) calc. Traditionally banking relationships > have not featured a great deal of profiling data, which could be valuable > to advertisers in a similar way to the type of data generated in a web2 > portal. > >>> > >>> Who is the trusted "cloud storage" provider, and how is that > information made portable between providers (ie: end-user seeks to take > their business elsewhere). From w3 communities perspective, I guess, we're > building standards to minimise potential lock-ins.?? > >>> > >>> Timh. > >>> Sent from my iPad > > >
Received on Sunday, 4 May 2014 20:37:38 UTC