Intent to Implement: Web NFC API

[Alexander]

Contact emails

alexander...@intel.com (developer)

rijubrat...@intel.com (developer)

zolta...@intel.com (spec editor)

kenneth.r.c...@intel.com (spec editor)

Spec

http://w3c.github.io/web-nfc/

Summary

The goal of the Web NFC API is to enable a set of Near Field Communication (NFC) functionality in the browser, which is useful for web pages and relies on browser security mechanisms.

Motivation

This feature gives developers the ability to access Near Field Communication (NFC) functionality of a device, such as reading and writing NFC tags as well as exchanging data between NFC capable devices. Example use cases can be found at [1].

Compatibility Risk:

This is a new API and has not been implemented in other browsers, therefore, there is no compatibility risk.

The spec is being defined by Web NFC CG [2] and has undergone review by the W3C TAG, so few changes are expected during the implementation. The feature would be implemented behind experimental runtime flag.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No (Feature would be supported on: Android, Android WebView, ChromeOS, Linux and Windows [3])

Support for Mac would be implemented as soon as NFC API is supported by the platform. Initially, the feature would be implemented for ChromeOS and Android.

OWP launch tracking bug

crbug.com/520391

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6261030015467520

Requesting approval to ship?

No.

[1] http://w3c.github.io/web-nfc/use-cases.html#use-cases

[2] https://www.w3.org/community/web-nfc/

[3] https://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.proximity

[PhistucK]

Do you intend to make it work with USB based NFC devices and older operating systems?

For example, the Israeli transit card uses NFC based smart cards for reading data and buying public transportation tickets and contracts. They intend to sell an NFC device (connected via USB) for reading the smart card and buying tickets using a computer.

Given the necessary drivers, will the Web NFC API be able to use that device on Windows 7 (I do not think Windows 7 has an NFC API out of the box, as it is only defined within Windows Runtime, which is only supported on Windows 8 and later)?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Alexander]

If there would be demand for Web NFC working on Windows 7 platform, I think it could be done, but it would require extra effort comparing to the platforms that already support NFC APIs.
New "third_party" components would need to be added to chromium. For example, libusb, libnfc and some NDEF parsing library.
For payments use case that you've provided, card emulation mode is needed, however it is not in the scope of the current spec version.

On Thursday, August 13, 2015 at 12:14:07 PM UTC+3, PhistucK wrote:

Do you intend to make it work with USB based NFC devices and older operating systems?

For example, the Israeli transit card uses NFC based smart cards for reading data and buying public transportation tickets and contracts. They intend to sell an NFC device (connected via USB) for reading the smart card and buying tickets using a computer.

Given the necessary drivers, will the Web NFC API be able to use that device on Windows 7 (I do not think Windows 7 has an NFC API out of the box, as it is only defined within Windows Runtime, which is only supported on Windows 8 and later)?

☆PhistucK

On Thu, Aug 13, 2015 at 11:10 AM, Alexander <alexander...@intel.com> wrote:

Contact emails

alexander...@intel.com (developer)

rijubrat...@intel.com (developer)

zolta...@intel.com (spec editor)

kenneth.r.christiansen@intel.com (spec editor)

Spec

http://w3c.github.io/web-nfc/

Summary

The goal of the Web NFC API is to enable a set of Near Field Communication (NFC) functionality in the browser, which is useful for web pages and relies on browser security mechanisms.

Motivation

This feature gives developers the ability to access Near Field Communication (NFC) functionality of a device, such as reading and writing NFC tags as well as exchanging data between NFC capable devices. Example use cases can be found at [1].

Compatibility Risk:

This is a new API and has not been implemented in other browsers, therefore, there is no compatibility risk.

The spec is being defined by Web NFC CG [2] and has undergone review by the W3C TAG, so few changes are expected during the implementation. The feature would be implemented behind experimental runtime flag.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No (Feature would be supported on: Android, Android WebView, ChromeOS, Linux and Windows [3])

Support for Mac would be implemented as soon as NFC API is supported by the platform. Initially, the feature would be implemented for ChromeOS and Android.

OWP launch tracking bug

crbug.com/520391

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6261030015467520

Requesting approval to ship?

No.

[1] http://w3c.github.io/web-nfc/use-cases.html#use-cases

[2] https://www.w3.org/community/web-nfc/

[3] https://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.proximity

[Alex Komoroske]

On Thu, Aug 13, 2015 at 1:10 AM, Alexander <alexander...@intel.com> wrote:

Contact emails

alexander...@intel.com (developer)

rijubrat...@intel.com (developer)

zolta...@intel.com (spec editor)

kenneth.r.c...@intel.com (spec editor)

Spec

http://w3c.github.io/web-nfc/

Summary

The goal of the Web NFC API is to enable a set of Near Field Communication (NFC) functionality in the browser, which is useful for web pages and relies on browser security mechanisms.

Motivation

This feature gives developers the ability to access Near Field Communication (NFC) functionality of a device, such as reading and writing NFC tags as well as exchanging data between NFC capable devices. Example use cases can be found at [1].

Compatibility Risk:

This is a new API and has not been implemented in other browsers, therefore, there is no compatibility risk.

To be clear, that is not the right interpretation of "compatibility risk" in this context. Compatibility risk does not refer to "when we ship it, will it be compatible with the version other vendors already ship". Instead, it refers to "what is the chance that over the long term what we ship will be incompatible with what other vendors have shipped, or will ultimately ship." In addition, for the purposes of this section of the Intent template, other vendors choosing to never ship the API counts as the highest possible incompatibility.

Being the first to ship an API, especially one that other vendors haven't given positive signals on, inherently carries a high amount of compatibility risk over the long term. That's not to say it's necessarily a bad idea, of course--just that it's something to consider carefully, which is why we have this section of the template.

[Rick Byers]

I'm glad you're working on this - expanding mobile device NFC scenarios to the web seems like a great fit for our overall mobile capabilities vision for blink.  So LGTM to implement. 

Have any patches landed yet?  I don't see reference to any from the bug.  An API of this size / risk typically gets a fair amount of incremental development in blink and experimentation under the 'experimental web platform features' status before we seriously consider flipping it to 'stable' status.

Also are there any signals from other browser vendors on this at all?  I see what appear to be some substantial open issues in GitHub, eg. the security review, and an ongoing extensive debate about the use of URL objects.  In general it doesn't look to me like this is mature enough to ship with confidence yet.  As Alex mentioned the main thing we're concerned about in this process is whether we're going to regret shipping an API before it has stabilized.

Rick

[Kenneth Rohde Christiansen]

Hi there,

I think it will be beneficial for us spec writers to get feedback on implementation problems and feedback from actual users willing to turn on the experimental flag - which is why I support implementing this behind a flag. As Alexander has already implemented the current API as a POC in a local branch, we are pretty confident that there are no major implementation issues.

As Rick pointed out there are still some things that we are ironing out with the spec due to great feedback from the W3C TAG and the Google security review. We don't intent to ship the API before these things have settled and the compatibility risk is considered low.

Cheers

Kenneth 

[Jonas Sicking]

Is the API still a generic NFC API? Or is it specifically targeting
sharing? Or is it a combination, like being generic NFC API for
reading/writing tags, but only targeting sharing for P2P?

I.e. does the API enable a webpage to use NFC for P2P communication
without bringing up UI for sharing?

/ Jonas

[Alexander]

It is generic NFC API that allows webpage to exchange data (NDEF messages) with NFC tags and NFC capable devices (P2P).
Specification maps NFC NDEF records to "web friendly" types here: https://w3c.github.io/web-nfc/#web-nfc-payload

On Thursday, August 13, 2015 at 10:06:58 PM UTC+3, Jonas Sicking wrote:

Is the API still a generic NFC API? Or is it specifically targeting
sharing? Or is it a combination, like being generic NFC API for
reading/writing tags, but only targeting sharing for P2P?

I.e. does the API enable a webpage to use NFC for P2P communication
without bringing up UI for sharing?

If by sharing, you mean connection handover, then it is not supported. Simple P2P message exchange should possible without showing "sharing UI".

[Kostiainen, Anssi]

Hi Jonas,

> On 13 Aug 2015, at 22:06, Jonas Sicking <jo...@sicking.cc> wrote:
>
> Is the API still a generic NFC API? Or is it specifically targeting
> sharing? Or is it a combination, like being generic NFC API for
> reading/writing tags, but only targeting sharing for P2P?

This high level Web NFC API (https://w3c.github.io/web-nfc/) should not be confused with the old now obsoleted "generic" low level Web NFC API (http://www.w3.org/TR/nfc/). I believe the Mozilla only navigator.mozNfc API for Firefox OS is closer to the low level one, but I haven't looked at it in detail.

This API that is now being implemented is a redesigned one that is scoped more tightly to make it browser-friendly & adheres to the Web's security model.

The spec enumerates the requirements it addresses:

https://w3c.github.io/web-nfc/#technical-requirements

> I.e. does the API enable a webpage to use NFC for P2P communication
> without bringing up UI for sharing?

The spec is explicit about user's consent:

http://w3c.github.io/web-nfc/index.html#security

Thanks,

-Anssi

[Jeffrey Yasskin]

3 questions:

1) In the spec, I can't find a description of when to fire the
'message' event. Where is it?
2) In https://w3c.github.io/web-nfc/#the-send-method, step 6 is
careful to set 'scope' to a sub-domain match of the document base URL,
but then it never uses 'scope' to constrain which targets it sends
messages to. Have I missed a use in some other algorithm? Did you
intend a use somewhere below?
3) Do you have screenshots of the permission UI you're thinking of for
Chrome? The spec rightly doesn't say how the UA should "obtain
permission", but you'll have to nail that down in your implementation,
and it'd be good to get a preview here.

Thanks,
Jeffrey

[Alexander]

Hi Jeffrey,

Zoltan is answering to the first and second question in a github (https://github.com/w3c/web-nfc/issues/31 https://github.com/w3c/web-nfc/issues/32).

On Friday, August 14, 2015 at 9:04:30 PM UTC+3, Jeffrey Yasskin wrote:

3 questions:

1) In the spec, I can't find a description of when to fire the
'message' event. Where is it?
2) In https://w3c.github.io/web-nfc/#the-send-method, step 6 is
careful to set 'scope' to a sub-domain match of the document base URL,
but then it never uses 'scope' to constrain which targets it sends
messages to. Have I missed a use in some other algorithm? Did you
intend a use somewhere below?
3) Do you have screenshots of the permission UI you're thinking of for
Chrome? The spec rightly doesn't say how the UA should "obtain
permission", but you'll have to nail that down in your implementation,
and it'd be good to get a preview here.

I'm planning to use existing permission codebase (Permission API <-> Permission service <-> "NfcPermissionContext" <-> PermissionBubble)
That would require addition of an icon(s) and a text for infobar notification. Therefore, permission UI for Web NFC would look like other security infobars (e.g. geolocation).

[Jeffrey Yasskin]

On Mon, Aug 17, 2015 at 7:23 AM, Alexander <alexander...@intel.com> wrote:
> On Friday, August 14, 2015 at 9:04:30 PM UTC+3, Jeffrey Yasskin wrote:
>> 3) Do you have screenshots of the permission UI you're thinking of for
>> Chrome? The spec rightly doesn't say how the UA should "obtain
>> permission", but you'll have to nail that down in your implementation,
>> and it'd be good to get a preview here.
>
> I'm planning to use existing permission codebase (Permission API <->
> Permission service <-> "NfcPermissionContext" <-> PermissionBubble)
> That would require addition of an icon(s) and a text for infobar
> notification. Therefore, permission UI for Web NFC would look like other
> security infobars (e.g. geolocation).

Is it a single infobar on the requestAdapter() call, or separate
requests for addEventListener('message') and send()? What text are you
thinking of?

+security-enamel since they do most of the work to think about our
permission UIs.

Thanks,
Jeffrey

[Jonas Sicking]

On Fri, Aug 14, 2015 at 4:57 AM, Alexander <alexander...@intel.com> wrote:
>> Is the API still a generic NFC API? Or is it specifically targeting
>> sharing? Or is it a combination, like being generic NFC API for
>> reading/writing tags, but only targeting sharing for P2P?
>>
>> I.e. does the API enable a webpage to use NFC for P2P communication
>> without bringing up UI for sharing?
>
> If by sharing, you mean connection handover, then it is not supported.
> Simple P2P message exchange should possible without showing "sharing UI".

That's great to hear!

My concern was that earlier discussions around this API required that
for P2P communication the implementation would always bring up a
"swipe to share UI". The reason was that there was uncertainty about
whether Android supported P2P NFC communication without such UI being
displayed first.

But it's great to hear that that's not the case. So it sounds like the
API under no circumstances will bring up any platform provided UI and
that the website has full control over what UI is displayed?

/ Jonas

[Kostiainen, Anssi]

The specification does not mandate any specific UI. It is up to the implementation to satisfy the "obtain permission" MUSTs in the spec.

Someone working on Android can probably confirm the platform imposed requirements (if any) in terms of platform provided UI in the peer-to-peer data exchange use case.

Thanks,

-Anssi

[Alexander]

On Monday, August 17, 2015 at 9:09:25 PM UTC+3, Jeffrey Yasskin wrote:

On Mon, Aug 17, 2015 at 7:23 AM, Alexander <alexander...@intel.com> wrote:
> On Friday, August 14, 2015 at 9:04:30 PM UTC+3, Jeffrey Yasskin wrote:
>> 3) Do you have screenshots of the permission UI you're thinking of for
>> Chrome? The spec rightly doesn't say how the UA should "obtain
>> permission", but you'll have to nail that down in your implementation,
>> and it'd be good to get a preview here.
>
> I'm planning to use existing permission codebase (Permission API <->
> Permission service <-> "NfcPermissionContext" <-> PermissionBubble)
> That would require addition of an icon(s) and a text for infobar
> notification. Therefore, permission UI for Web NFC would look like other
> security infobars (e.g. geolocation).

Is it a single infobar on the requestAdapter() call, or separate
requests for addEventListener('message') and send()? What text are you
thinking of?

Spec says that UA should obtain permission for addEventListener('message') and send() method: https://w3c.github.io/web-nfc/#security
I haven't thought about possible text (or icon) for permission infobar. I was thinking that I would propose "engineering English" version of the text, then Chromium security / UI localization team would review it and change if needed.
 

[Jonas Sicking]

On Tue, Aug 18, 2015 at 1:47 AM, Kostiainen, Anssi
<anssi.ko...@intel.com> wrote:
>
>
> > On 18 Aug 2015, at 01:16, Jonas Sicking <jo...@sicking.cc> wrote:
> >
> > On Fri, Aug 14, 2015 at 4:57 AM, Alexander <alexander...@intel.com> wrote:
> >>> Is the API still a generic NFC API? Or is it specifically targeting
> >>> sharing? Or is it a combination, like being generic NFC API for
> >>> reading/writing tags, but only targeting sharing for P2P?
> >>>
> >>> I.e. does the API enable a webpage to use NFC for P2P communication
> >>> without bringing up UI for sharing?
> >>
> >> If by sharing, you mean connection handover, then it is not supported.
> >> Simple P2P message exchange should possible without showing "sharing UI".
> >
> > That's great to hear!
> >
> > My concern was that earlier discussions around this API required that
> > for P2P communication the implementation would always bring up a
> > "swipe to share UI". The reason was that there was uncertainty about
> > whether Android supported P2P NFC communication without such UI being
> > displayed first.
> >
> > But it's great to hear that that's not the case. So it sounds like the
> > API under no circumstances will bring up any platform provided UI and
> > that the website has full control over what UI is displayed?
>
> The specification does not mandate any specific UI. It is up to the implementation to satisfy the "obtain permission" MUSTs in the spec.

Ah, I wonder why the spec has this requirement. But having a generic
permission UI is certainly a lot better than having the API show a UI
that's specifically geared towards sharing.

So great to know that neither Android, nor the API implementation
inside Chrome, will show sharing-specific UI.

I'll head over to https://github.com/w3c/web-nfc/issues/3 to see if we
can remove even the existing prompting requirements.

/ Jonas

[Gregg Tavares]

Is this one of those "powerful APIs" that will be https only like geolocation/devicemotion?

[PhistucK]

Perhaps this needs to be added as a question to the intent template.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Kenneth Rohde Christiansen]

Yes, that is the idea.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Adrienne Porter Felt]

+nparker, the security reviewer for this API