RE: Feedback about WebNFC API

Hi Kenneth,
Thank you for the explanation concerning the Origin Trial, I had not understood that it is possible to do this.

Concerning transceive, when you say “exposing APDU”, do you mean exposing some APDU commands from Type4 or ISO7816 standards?
In my opinion this will less flexible than exposing the transceive function.
In fact, depending of the tag used, a specific transceive should be used:

·       The transceive defined in nfcA (https://developer.android.com/reference/android/nfc/tech/NfcA) is used for Type2 Tags.

·       The transceive defined in ISODEP (https://developer.android.com/reference/android/nfc/tech/IsoDep) is used for Type4A Tags.

·       The transceive defined in nfcV (https://developer.android.com/reference/android/nfc/tech/NfcV) is used for Type5 Tags.

I’m available for a conference meeting if you wish. I’m in France so my time zone is Central European Time.

Best regards
Olivier


From: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>
Sent: mercredi 4 mars 2020 22:43
To: Olivier LORENTE <olivier.lorente@st.com>; public-web-nfc@w3.org; François Beaufort 🇫🇷 <fbeaufort@google.com>
Subject: RE: Feedback about WebNFC API

Hi there Olivier,

Ø  Also, another limitation for the developers is the required use of flags. It limits the use of the NFC web app to only very early adopters, and no pilot can be run.

This is exactly what the Origin Trial solves as it allows sites and apps to add the token to their web sites so that users do not need to do anything. That way they can use the feature before it is officially shipping.

The transceive() method won’t be part of the initial version of the API because that will block shipping and handling security is different that for NDEF so a lot of thoughts need to be done around that.

Tranceive also very much depends on the underlying protocol. Like exposing APDU might be much more valuable that exposing NFC-A or ISO-DEP which it is often implemented on top of. I have done some research in this area but it might be valuable doing a conference meeting with you to get your thoughts for that.

Cheers,
Kenneth

From: Olivier LORENTE <olivier.lorente@st.com<mailto:olivier.lorente@st.com>>
Sent: Monday, March 2, 2020 10:10 AM
To: public-web-nfc@w3.org<mailto:public-web-nfc@w3.org>
Subject: Feedback about WebNFC API

Hi,

STMicroelectronics is developing NFC Tags, Dynamic Tags and Readers for a wide range of applications (https://www.st.com/en/nfc/st25-nfc-rfid-tags-readers.html).
We have followed with interest what has been done in the last years by the Web NFC Community Group and we are glad to see that the project recently moved to a new phase with the beginning of the “Origin Trial” phase. We have seen that you are asking for feedbacks about this feature so we take this opportunity to share our view.

We see this project as a great opportunity to develop an NFC Web App that will maybe, one day, work on most browsers and OSes (iOS for instance). This would open many opportunities since the same Progressive Web App would work in every environments. Today our customers have to develop and maintain dedicated Android and iOS Apps. Having a WebApp has some other advantages: You always run the up-to-date version (with the latest fixes) and Users don’t have to install anything. For these reasons, this WebNFC project is promising.

We have used your API 2 years ago and developed a small demo reading and writing NDEF records in our tags. It worked fine. For the moment, the WebNFC API is limited to the read/write of NDEF content only, and this is a limiting factor for the use and the development of NFC apps. Indeed, the use cases are limited to “frozen” use cases, while adding a general purpose “transceive()” command would enable many more IoT use cases: Setting and reading sensors, personalizing a device before use, developing home automation applications, adding security (passwords, crypto). Especially on type V tags which are now fully supported with a transceiver type of command on both Android and iOS.

Also, another limitation for the developers is the required use of flags. It limits the use of the NFC web app to only very early adopters, and no pilot can be run.

So as early adopters, our feedback is that we are convinced that the potential of NFC webApp is huge. But unlocking a “transceive()” function as well as the use of flags will take it to the next step.

Best regards
Olivier