Status of the Web-NFC Working Group

[OlivierGre]

Hi,

What is the status of the Web-NFC Working Group and what are the evolutions that you expect in the coming year?

What are the chances to get the Web NFC API adopted by the W3C and progressively used by every browsers?

Is there some plans to modify Chrome on IOS to be able to read NDEF content from a NFC tag (still after enabling Chrome's "NFC Flag")?

Thanks for this info Regards

[cyberphone]

Hi Olivier, What use-cases do you see for Web NFC in Android?

Haven't QR effectively already killed NFC on the Web? Dell recently removed NFC from their XPS line.

None of the HW vendors (including ST...) have shown any interest in supporting AliPay-like payments at the PoS terminal using NFC either.

Starting the browser via an NFC-emitted URL seems like the best "Web NFC" solution but this has nothing to do with Web NFC as far as I can tell.

https://github.com/w3c/web-nfc/issues/140

[OlivierGre]

In my opinion that's nice if a Web App can change the content of a tag. This opens possibilities...

My question was for the members of this Web NFC Working Group. What evolutions do you expect?

[cyberphone]

Olivier, There is no Web NFC working group (WG), only a Web NFC community group (CG) which anybody can be a member of for free. I'm one :-)

What possibilities are you thinking about? Are they addressing a mass market?

[anssiko]

@OlivierLorente, we need signals from other browsers beside Chrome to justify advancement to a WG. We evaluated the WG migration opportunity last November, see https://github.com/w3c/dap-charter/issues/29

[cyberphone]

@anssiko @OlivierLorente @dontcallmedom It is not the browser vendors that's the problem, it is the lack of useful Web NFC applications. There's little point bothering with marginal applications or applications that are already firmly established through other means including native apps.

An obvious application is a "Better QR" but it appears that the NFC-forum is not working with such concepts although QR is effectively eating NFC's lunch.

[mrj]

Currently, QR is the only way for a website to transmit a URL from iOS, because there are no indications of WebNFC being implemented in Safari. QR is also the best way to receive a URL on iOS, because it's built-in to the iOS 11 Camera app (iPhone 5S and above), while only iPhone 7 and above supports the triggering of a browser action from a URL sent by NFC.

On Android, easy inbuilt support for URL reception and browser triggering by QR code is much less widespread. But conversely, support for URL reception and browser triggering by NFC is much more widespread than iOS. Chrome on Android is still the only prospect for transmitting URLs from a website via NFC to both Android and iOS devices. But WebNFC is still both unreleased for general use, and lacks support for peer-to-peer URL sharing. I first expressed interest in such support in September 2015.

On the surface, NFC seems to be a more reliable and less awkward means of URL transmission than QR codes, but I've been impressed with QR's ability to decode rough photos of on-screen codes. Both take-photo and tap-payment are widely-familiar phone actions.

[cyberphone]

As long as the NFC vendors do not care that QR is winning the game, nothing will happen.

[mrj]

Isn't QR entrenched mainly in Asia? In Australia, NFC on phones is a thousand-fold more used than QR, because of its use in payments. This familiarity with tapping is ripe to be exploited in non-payment applications.

[cyberphone]

Nowadays QR is pretty much everywhere. On the Web there is nothing even remotely comparable.

The luxury shops in Europe are gearing up for 100M Chinese tourists. Their payment systems are not based on 20Y+ old 7816 technology.

There's a complete disconnect between the different players in this space.

[mrj]

QR is only popular because it's an end-run around Apple Pay, plus its suitability for use on printed marketing materials.

[cyberphone]

QR has gotten traction for Web payments and Authentication using Mobile/App + PC/Web

[leolux]

The adoption of NFC is growing. You can find many news on this site: https://www.nfcworld.com/technology/nfc/.

In my eyes WebNFC should be able support the NFC (hosted) card emulation mode which is a perfect fit for authentication and check-in systems. Users can tap an NFC reader to authenticate or checkin without having to open an app or website at this moment. It seems to me that the required pieces for implementing the card emulation mode in the Web are already here. The browser would have to register an HCE service listening for an Application ID or AID group triggering the corresponding service worker which implements the actual communication to the reader device. The usability of hosted card emulation mode could further be improved by laveraging the Wake Lock API [1] to make the HCE service working even from the lock-screen.

[1] https://www.w3.org/TR/2017/CR-wake-lock-20171214/

[cyberphone]

@leolux I believe this idea has considerable security issues. Cards were designed to be used in secure environments like payment terminals. A Web site is not comparable.

High level schemes using mobile devices can be secure: https://github.com/w3c/web-nfc/issues/128#issuecomment-308647894

[leolux]

Yes, but I am not sure about your security issues because a website cannot read any credit card because they are secured to be used only by authorized readears. HCE allows you to roll out and implement your own NFC reader infrastructure implementing your own application which has no interference with existing cards and readers. Futhermore the use of HCE within the Web NFC API could be restricted to non-payment AIDs by managing a list of AIDs of payment networks such as Visa and MasterCard. Browsers are also able to manage a list of Certificate Authorities which is required for the secure use of TLS.

[mrj]

We shouldn't let security concerns so weaken the power of the open Web relative to mobile apps that apps take over even more than they have. Just as a user can choose to trust an app which asks for certain permissions, so should a user be able to trust a website to do certain things, possibly by giving specific permissions via prompt in the same way as apps.

[leolux]

I agree and permission prompts are already implemented for a bunch of web APIs requiring user consent which works exactly the same way as for native apps.

[cyberphone]

There's a huge difference between access to geolocation or camera because

• the security prompt is possible to understand by mere mortals
• the resource belongs to you

Giving (indirect) access to low-level cryptographic operations to a card issued by your employer, government or bank is another thing.

Mobile device based authentication and payments do not have this problem because such applications only exposes high-level operations like: https://cyberphone.github.io/doc/saturn/ui-demo/personalpaymentterminal.html

[cyberphone]

@leolux @jasondavies @mrj This is what you will be facing: https://lists.w3.org/Archives/Public/public-web-security/2018Mar/0008.html A famous French smart card vendor tried to get support for a smart card API in browsers. After five years with no progress they quit the W3C.

[cyberphone]

Here is another take on the matter using BLE: https://www.dropbox.com/s/do6o3g0eczdtrbg/Tyfone%20animation%20on%20blockchain%20(v10).mp4

It starts 3 minutes into the clip.

[Liryna]

Giving (indirect) access to low-level cryptographic operations to a card issued by your employer, government or bank is another thing.

It will give nothing. If there is a low-level cryptographic operations, they are protected by a strong mechanism otherwise it is not a hardware that can be trusted.

A famous French smart card vendor tried to get support for a smart card API in browsers. After five years with no progress they quit the W3C.

They are talking about strong identity and tracking issue. Nothing about smartcard.

@cyberphone I understand from all your post here that you are not friendly to NFC/RFID. This is probably because of the vision coming for PKI used in such field. Yes PKI can be used by this technology but not only. Even here PKI would not be an issue if the hardware used to store it allows only strong communication channels.

BLE has the same issue that NFC/RFID about security. It depends on the hardware and communication channel.

Please @cyberphone can we keep the discussion focus on NFC/RFID.

[cyberphone]

@Liryna Opening a physical door with a RFID device is a different use case than opening a virtual door on the Web. RFID wasn't designed to cope with phishing attacks. For the latter you need high level protocols. The RFID/NFC industry doesn't appear to be overly interested in such topics.

[Liryna]

@cyberphone Can you describe technically how this is different ? Which low-level protocol part would be an issue for you ?

[cyberphone]

@Liryna Assuming that the system is open ended with respect to the client side (that is, the device is not locked to a single relying party), a phishing site can emulate a user. This is why FIDO U2F requires a specific key for each site making it harmless accidentally going to a phisher.

[Liryna]

@cyberphone Well, assuming this, would be really kind from you. I never saw an open-ended smartcard.

Even if it is open-ended, what would be the fishing angle here ? Structure of the card ? Existing app ? Locked memory ? What about if app listing is disabled as all open-ended do (or should do) ? You agree that it would not be the data since such card are app locked for each service.

[cyberphone]

@Liryna I believe that you (in some way) must involve the domain of the site in the equation in order to make authentications "phishfree". This seems to be independent of the open/locked issue as well.

RFID/NFC security is mainly based on proximity. With the Web this quality is weakened, leaving a new trust decision to the user which isn't that great. I would personally not bother creating new technology having built-in flaws of that magnitude.

I claim that this issue is solvable but I certainly can't succeed on my own. Yes, my claim may even be incorrect!

[Liryna]

@cyberphone RFID/NFC proximity has always been an issue and not linked to the Web. Cards have evolved since and have proximity check security (this could even break the Web NFC API, test should be done on this side).

The only issue that I can find here is the card configuration and this is the matter of the card provider to secure his users as a website developer when he provides online services.

[cyberphone]

The only issue that I can find here is the card configuration and this is the matter of the card provider to secure his users as a website developer.

@Liryna I have no idea what that means in practice.

[leolux]

Some time ago I have started a discussion about the issue that the browser does not provide any context information to the web app while loading a page: https://discourse.wicg.io/t/adding-an-execution-context-while-starting-web-apps/2537

Maybe the concept of a browser generated context information could be used to better secure the web.

[cyberphone]

Maybe the concept of a browser generated context information could be used to better secure the web.

@leolux Yes, this is the missing ingredient I'm talking about.

How you do that over NFC is not entirely straightforward though. I begun with a very elaborate solution but then turned to something much simpler: https://github.com/w3c/web-nfc/issues/140