Re: Concrete contribution to Web Payments

there’s a bunch of use-cases; where the existing TLS WebID (x.509v3) could be issued to a machine rather than a person (agent for machine, by relating owner to machine perhaps) then associate to other accounts as ‘guests’ or whatever.

but this still means it’s difficult to identify the individual in-front of the machine. can use multiple online devices, but simply ‘something you have’ make some sense.  Having a tag that’s got both a QR-CODE and NFC Chip is one means; another is perhaps creating a relationship between a personal device (like a phone) and the web-browser in use (i.e. a desktop / laptop) 

a practical application might also include methods to provide receipts to/from NFC/QRCode tagged loyalty programs; most older POS systems run on XP / windows.  might be a useful alternative / method for parsing ‘loyalty’ info securely, especially in RWW types of situations (user holds their own data in their own account somewhere).

are you considering perhaps in the back of your mind somewhere; that perhaps part of the needs assessment for Web-payments is working code.  therein, your already working on something and perhaps we could get our heads together to figure out integration / use-cases?? 

happy to help in any case.  interested in the project for sure. 


On 11 Apr 2014, at 7:27 pm, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

> On 2014-04-11 09:32, Tim Holborn wrote:
>> Anders, 
>> 
>> cheer-up… 
> 
> :-) :-)
> 
>> I imagine the thing can be NFC / 2D Barcode (QR-code (for example) compliant? 
> 
> This scheme is web-based.  Assuming that you can receive a URL with
> (for example) a payment request over NFC it is compliant.
> 
>> 
>> Have you spoken to melvin about it?
> 
> Not yet.
> 
> 
>> Why not chrome too? 
> 
> It is a resource issue.  I'm essentially only *one* person :-)
> 
> In addition, Google have a magnitude more resources to throw on things
> they find useful than Mozilla.  If they Google don't find a thing useful
> they won't accept it either even if it is free, tested etc.
> 
> 
>> What’s the best forum to continue the discussion..? 
> 
> I don't anticipate any discussions on this thing until it is shipping.  Mozilla
> have declared that they are uninterested discussing specs, they want code.
> 
> There are also very few people who have the technical background needed to
> understand why you cannot directly expose a smart card to the web.  W3C is
> trying to do that: http://opoto.github.io/secure-element and IMO this scheme
> suffers from a truckload of issues as well as no voiced support from "the big three".
> 
> 
>> does this relate specifically to web-payments?
>> sounds like a WebID Related method to me… 
> 
> This is thing.  Universal often means "useless for all" but I believe
> this scheme actually is equally useful for payments as for WebID.
> 
> 
>> does this mean i’m the first moral contributor?> :)
> 
> Indeed it does :-)
> 
> Anders
> 
>> 
>> On 11 Apr 2014, at 6:25 pm, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>> 
>>> Pardon me if I have used too much list bandwidth to express my somewhat pessimistic
>>> view on W3C's ability "upgrading" the payment world.
>>> 
>>> To make you feel slightly happier (?), I can report that I'm in the *very* early phases of
>>> implementing a browser extension in Firefox which combines smart card technology
>>> and Web Crypto which have multiple uses including payments:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=978867
>>> 
>>> This project has to date no moral, monetary, or technical support from anybody.
>>> I haven't even been able to get constructive feedback on the concept itself.
>>> 
>>> My hope is that Mozilla will include the code (when ready...) in the shipping browser
>>> but this is one of the many hurdles we are facing today: Browser vendor support.
>>> Open Source is by no means a guarantee for success!
>>> 
>>> Cheers
>>> Anders
>>> 
>> 
>

Received on Friday, 11 April 2014 09:42:00 UTC