Allow a NFC tap to load a URL with NFC message payload passed to the page

[markafoltz]

[Rephrasing a discussion during yesterday's F2F]

The museum use case described in [1] would benefit if the web app could bootstrap itself with an initial tap on a NFC tag. The UA would read a URL to which the user would be prompted to navigate. If the URL were already loaded, the UA would foreground an existing browser/tab (in case there are a series of tags that are "anchors" into the same content).

Once the browser navigates to this URL, it would be helpful if the page were able to access the other records in the message (NFCMessage.data) without a second tap. This might require a solution like adding a navigator.nfc.referrerMessage property, similar to what is proposed in the Web Bluetooth API [2].

Another variant is to actually read the HTML document from the NFC tag and load it in the browser. This would require careful design to ensure that the document is loaded in a secure way (sandboxed/unique origin), and some convention for the data payload to let the browser know that it should render the content of the tag. This would allow nice applications like being able to retrieve a bus schedule by tapping on a tag even if you don't have Internet connectivity.

[1] https://w3c.github.io/web-nfc/use-cases.html#reading-generic-information-in-a-museum
[2] WebBluetoothCG/web-bluetooth#163

[kenchris]

+@alexshalamov would something like this be implementable on Android.

@mfoltzgoogle do you have any contacts in the team doing NFC for Android?

[alexshalamov]

Bootstrapping from tag is simple. Tag with multiple records would need to have first record to be URL. Most of the systems then launch browser that would open new tab.

@kenchris, @mfoltzgoogle, on Android, I need to check whether I can get tag object after Chrome tab is opened and page starts watching for tags.
I can quickly prototype that this week or early next week and tell my findings.

[zolkis]

I think there is a difference when the tag is a Web NFC tag vs when it's a normal tag.

The implementation will register for handling the Web NFC tags. In that case it can buffer the tag content for a given time. Pages using Web NFC watch that are launched within that time would get the data (if policy and filters apply).

For normal tags, when the first record is a URL record, the implicit action is to open a page with it. In that case it applies what Alex said: we need to check if the data (and what data) is available.

So to me it seems we can implement both of your uses cases at least with Web NFC tags, and let's see if normal tags would work as well.

[alexshalamov]

@zolkis As it seems that you pretty much have a solution in mind 😉, would you like to provide prototype as well as cross platform evaluation?

[markafoltz]

@kenchris Re: #78 (comment)

Sorry, I don't have any specific contacts who are familiar with the Android NFC implementation. @riju is handling the implementation on the Chrome side and might have some guidance.

[du5hyanth]

I need expert suggestion in specific use case of order management in Restaurants.

We are using NFC Tags in our restaurant to present menu electronically, to users who have NFC enabled phones. URL identifies the table and kitchen interface receives a notification whenever there is an order.

Since URLs can be copied easily we are facing issues of fake ordering, is there anyway to leverage webNFC api to identify orders generated by manually typing urls?

[kenchris]

Hi there @du5hyanth

Let me see if I can answer, but I am trying to understand your setup here.

• Users tap on a passive tag which opens up a web site which identifies the table.

If the tag is passive it is hard to change what the NFC tags has stored, but you could still store a hash of the table number with a special key only you know and then compare on the server side: ie, using something like: https://github.com/blueimp/JavaScript-MD5/blob/master/README.md

That would make it hard for people to type in a browser URL by mistake and place orders.

People can still read the tag with their phones and save the URL and thus use it later if they wish to do harm.

On the other hand, if your menu is on a screen with a programmable nfc device, then you could change the table identifier after each customer has paid and then only the paying customer can make fake orders to his own table.

It seems that you mostly use NFC for bootstrapping the initial URL to the site (like Physical Web does it) but with an actual physical connection. You don't really need Web NFC for that, but being able to program the NFC tags (ie change table identified - ie number plus code hashed with key - after each paying customer or at least once every two hours, would be quite useful)

A small device with NFC writer (card emulation) attached should be able to do that.

[du5hyanth]

Thank you so much for your response 👍

[kenchris]

@Honry @DonnaWuDongxia As I already stated that we handle URL records wrongly (read from PAYLOAD and not TYPE field) it makes sense to test whether this is possible while fixing that.

If we cannot get access to the payload, then we can drop this and add a note to the spec, but if we can, it makes a lot of sense doing this! :-)

[leonhsl]

For URL records,
TNF_ABSOLUTE_URI records. ---> the URL is saved in TYPE field
TNF_WELL_KNOWN with a type of RTD_URI. ---> the URL is saved in PAYLOAD
Our impl in Chromium just get the URL of them by calling https://developer.android.com/reference/android/nfc/NdefRecord.html#toUri(), which always reads from the correct field.

I'm not quite sure though, the use case mentioned here seems to me kind of out scope of web-nfc spec, it's more like a feature of Browser, like opening a page for the url read from a NFC tag, meanwhile feeding other records data to the opened page.

[kenchris]

Yes the Web NFC API is implemented by browsers. Opening the page, yes could be a browser only feature, but passing the data along definitely needs speccing if possible

[beaufortfrancois]

Curious here, what's the current status?

[kenchris]

No further research. You already looked in this area or maybe you want to look?

We don't have to use it's payload, but might make sense to share records read with the web site, when it was launched from the tag.

Something like NDEFReader.referringNdef

[kenchris]

We could potentially also do a lastReading or so similar to Generic Sensors

[beaufortfrancois]

I'd like to pursue this as this makes it an interesting use case for sure.

const reader = new NDEFReader();
if (reader.discoveryEvent) {
  // User landed on this page from tapping a NFC tag with a URL record
  const { serialNumber, message } = reader.discoveryEvent;
}

Let's bikeshed on the name later. For now, I think we should expose the event (serialNumber + message) that triggered the discovery of the website user landed on. WDYT?

[zolkis]

There seem to be several issues in this issue.
The original comment seems to be loading a URL from the first record in a browser page and make the tag content available to that page.

We don't have anything on that yet.

There was a related use-case discussion that was given a solution.

Then there was the absolute-URL discussion. We handled that wrong, now fixed. Android handles it in a special way. That was a side-kick.

The example above exposes the tag data in a discovery event - the problem is the tag has not been discovered, it's been already read by the time the script gets to it.

In the original use case, when the page loads the tag has already been read, the question being how to provide that content to the page (bootstrapped from the same tag) without making another read (which is an option, too).

Kenneth's referringNDEF suggestion seems like a better match to this particular use case.

However, I can see that we could redesign the API for the better, and in the same time aim low level. In that case IMHO we'll end up with a (potentially simplified) Android API with events and intents etc.

[icecold546]

Hi, would a business use case for this feature accelerate the progress of development? I have a strong business use case for this feature.

[anssiko]

Use cases are certainly helpful when development priorities are considered. Please feel free to share your use case here in this issue. Thanks!

[icecold546]

We offering a e-receipt service.

NDEF with URL to bring user to PWA >> NDEF has additional payload which PWA reads (likely a JSON, this as a referringNDEF would be prefect)>> Instant e-receipt without an mobile application and no connectivity needed to the internet

We have about 1500 POS machines that are waiting to use this e-receipt functionality

[naton]

I’m in a similar position as @icecold546 here, although I think a URL with the key to the receipt would be enough for us. And opening the default browser would suffice (doesn’t have to have a PWA installed in our case). Being able to create and send the info from within a PWA (our web POS software) is what we are aiming at though.