Re: Intro & Project Status

Hi Mark,

On Mon, Sep 7, 2015 at 9:23 PM, Mark James <mrj@rbate.com> wrote:

>
> The use case I'm interested in is a user of an NFC-capable device
> (embedded or USB) being able to use a web-app to open a URL on a peer
> device (which has factory intent settings) via NFC. I'm glad this looks
> like it will work in the implementation that will soon be available for
> testing.
>

If you see this Web NFC API supported in a browser on a given platform, it
will likely have different Android intent settings than without it.


>
> However sections 4.3
> <https://w3c.github.io/web-nfc/#sending-data-to-nfc-peer-devices> and 10.4
> <https://w3c.github.io/web-nfc/#steps-receiving> of the spec aren't clear
> on the circumstances in which the native NFC message router passes Web-NFC
> messages to a browser. In what ways does it depend on the native intent
> rules, the installed and default browsers, the Web-NFC message type, and
> the active watches?
>

This is considered implementation detail and it is not supposed to be in a
W3C spec. You need to look at the intents to implement in each browser that
will support this API. Currently we are doing that for Chrome.


>
> I'm not understanding the significance of the record order. What is an AAR?
>

Android Application Record, which can be used for making sure no other apps
than the specified package will get the dispatched NDEF message. The Web
NFC record needs to be the first record because intent filters work on the
first NDEF record in Android (so far), and we do want to differentiate on
that record when determining whether the message is a Web NFC message or
not: it contains a URN specific to w3c and web-nfc.


> I may have a fundamental misunderstanding. Does a "Web-NFC message" just
> mean it comes from the Web, or does it mean that its messages are targeted
> to the Web? If the former, how can non-browser apps be set to accept text
> and JSON messages, and can this be controlled by some app-name field in the
> message?
>
>
It means a normal NDEF message which contains a Web NFC record. It is true
both for reading and writing.

Now regular NDEF messages are infinitesimally unlikely to contain a Web NFC
record "by accident",
but the existence of Web NFC record does not guarantee it actually comes
from the Web, since any native app can forge a Web NFC record if they want
(otherwise we could not implement the spec).

Therefore it is more correct to say that the Web NFC message is targeted to
web pages (too), and in most cases (all but forgery or pre-programming) are
likely to come from a web page too. The forgery case is said to be deferred
to app stores, like you'd need to shoot down fake browsers (or extensions)
too - but for the sake of correctness we treat NDEF content as untrusted
for integrity, unless prearranged trust relationship (content encryption,
etc) exists.

I will think about how could we formulate a Note in the spec about the
platform specific details of dispatching in generic terms.

Best regards,
Zoltan