- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Tue, 14 Apr 2015 23:08:52 +0200
- To: Wayne Carr <wayne.carr@linux.intel.com>, "Kis, Zoltan" <zoltan.kis@intel.com>
- CC: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "Web NFC (W3C)" <public-web-nfc@w3.org>
On 2015-04-14 21:58, Wayne Carr wrote: <snip> > Community Groups are set up so if someone has an idea they want to > pursue, a new Community Group for that is very easy to start. You could > create a CG aimed at the "a way for untrusted Web-pages to interact with > connecting client devices". That isn't what the Web NFC CG is about. I see. I must admit that I don't fully understand what you are actually trying to do. Payments and authentication is apparently not in scope. Anyway, setting up a CG for my specification would be useless because: - The use-case and approximate tech is already reasonably well described - I do not represent any major vendor. I'm just an individual who want things to NOT end-up as SysApps or WebCrypto.Next. Anders >> >> This is way outside of what a Web Payment IG could deal with, this is >> core technology. >> In fact, I'm not even myself enough into NFC and WebIDL to create the >> complete >> specification which is one reason why I joined this CG. >> >> Anyway, there is a 3 + 8 page "presentation/specification" for those >> who are interested. >> https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf >> >> https://cyberphone.github.io/openkeystore/resources/docs/web2native-bridge.pdf >> >> >> Regards >> Anders >> >>> >>> >>> The group's Charter defines the goals and scope for the >>> group. I encourage you familiarise yourself with the document: >>> >>> http://w3c.github.io/web-nfc/__charter/ >>> <http://w3c.github.io/web-nfc/charter/> >>> >>> The Charter was crafted with input from multiple >>> stakeholders, including multiple major browser implementers. >>> >>> >>> I know but the charter doesn't address my question. >>> >>> >>> In version 1 of the API we didn't want to address payments at all. >>> The use cases we intended to solve are more like the following >>> (reading/writing tags, send peer messages/data): >>> http://w3c.github.io/web-nfc/use-cases.html#reading-generic-information-in-a-museum >>> >>> http://w3c.github.io/web-nfc/use-cases.html#reading-information-in-administration-office >>> >>> http://w3c.github.io/web-nfc/use-cases.html#updating-tag-information >>> http://w3c.github.io/web-nfc/use-cases.html#sending-image-to-another-web-nfc-capable-device >>> >>> >>> and the problems we wanted to deal with concerning security and >>> privacy are summarized in >>> https://github.com/w3c/web-nfc/issues/2 >>> >>> and in >>> http://w3c.github.io/web-nfc/security-privacy.html#threats-and-possible-solutions >>> >>> http://w3c.github.io/web-nfc/security-privacy.html#security-policies >>> >>> This defines the scope for Version 1. As a note, there are a couple >>> of bugs in the current version of the spec which we'll iron out ASAP >>> (this week). >>> >>> I.e. a fundamental issue didn't show-up until it got into the >>> actual specification. >>> BTW, this is quite normal, it happens all the time :-) >>> >>> >>> Yes, your proposal has potential indeed, and I encourage you to drive >>> it forward in this CG and/or in Web Payments IG. >>> >>> >>> As the participant of the group, you are free to propose changes >>> >>> > to the Charter per the "Amendments to this Charter" section >>> defined in the above-mentioned document. >>> >>> I prefer leaving this to Intel and Google to think about. >>> >>> >>> It doesn't work like this. If this is important for you, please >>> contribute: make proposals, edit the spec/submit PR's etc. >>> Of course others will also think about it, but priorities may differ. >>> >>> >>> There is one consideration I would like to add as well: >>> Ideally you always want to "centralize" privacy and security UX, >>> right? >>> The problem is that this "one-size-fits-all" approach creates new >>> problems >>> since the browser often cannot really tell the user what exactly >>> is at risk. >>> Therefore I have decided to "delegate" this problem to the >>> connecting applications >>> which can do this job much better. >>> >>> >>> It would be nice if you'd write that up as a section to the Security >>> and Privacy doc. >>> >>> Best regards, >>> Zoltan >>> >> >> >> >
Received on Tuesday, 14 April 2015 21:09:26 UTC