- From: Wayne Carr <wayne.carr@linux.intel.com>
- Date: Tue, 14 Apr 2015 12:58:07 -0700
- To: Anders Rundgren <anders.rundgren.net@gmail.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 08:52, Anders Rundgren wrote: > On 2015-04-14 17:16, Kis, Zoltan wrote: >> On Tue, Apr 14, 2015 at 6:01 PM, Anders Rundgren >> <anders.rundgren.net@gmail.com >> <mailto:anders.rundgren.net@gmail.com>> wrote: >> >> On 2015-04-14 15:46, Kostiainen, Anssi wrote: >> >> On 14 Apr 2015, at 14:41, Anders Rundgren >> <anders.rundgren.net@gmail.com >> <mailto:anders.rundgren.net@gmail.com>__> wrote: >> >> When I read issues like >> https://github.com/w3c/web-__nfc/issues/16 >> <https://github.com/w3c/web-nfc/issues/16> >> I get the impression that you expect connecting clients >> to use Web-technology. >> >> IMO, this assumption will severely limit the value of Web >> NFC. >> The only "standard" that's really lacking, is a way for >> untrusted Web-pages to interact with connecting client devices. >> http://ipt.intel.com/Home/How-__it-works/network-security-__identity-management/ipt-with-__near-field-communications >> <http://ipt.intel.com/Home/How-it-works/network-security-identity-management/ipt-with-near-field-communications> >> >> >> How Web-based OSes expose NFC to the outer world should >> IMO be left to another forum to cater for including >> security considerations. >> >> >> This is the CG which intended to deal with it. > > So this is basically SysApps reborn, then? > > > Yet I am just thinking: isn't the Web Payments IG a better place to > handle your request > > in more detail, and provide input for this CG for API changes? > > > I'm not talking about API changes, I'm suggesting an entirely > different direction > targeted at the mass-market which is currently using *agnostic* > connecting clients. 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. > > 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 19:58:36 UTC