Re: General objection regarding Web NFC

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.

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 15:53:28 UTC