Open riju opened 5 years ago
I think this is a good idea but I wonder if it wouldn't be a good time thinking about the entire application. Note : I know ZERO about how those applications work today but I would be surprised if they are suited for mobile phones. In my opinion you would rather download a key which then would be used over NFC i a challenge response mode where the challenger must also provide knowledge to the key. This could for example be done through an X.509 certificate. It is not very obvious to me that Web NFC has any role to fulfill here.
It is really a generic physical access key application we are talking about.
We should vet the use cases.
I wonder if the above mentioned companies would be willing to give up their apps that 1. may collect more data than a web page and 2. which allow them to own the whole solution, whereas with Web NFC a part of the solution is implemented in the browser.
However, it's far easier to update a web page than an app. Solution makers could use the Web NFC API and still implement their protocols for transceive()
, only there would be much less code to write, provided we can offer all the features needed. On that I have some doubt as well, as we've been trying to simplify the native NFC APIs a bit.
On the other hand, apps could be scrutinized much more by the app store than a web page, besides it's far easier to take off an offending app than a trapping web page. Of course, origin policy and proper permissions should alleviate some concerns.
I still don't see the point with using a browser instead of an app for opening a door. It is pretty much the same use case as with payments at a POS terminal.
@zolkis and @cyberphone I can say that I want to build a web application where employees of my company can tap their NFC cards on a mobile device running this web app to mark themselves as physically present at a point-in-time. For me, it's much, much easier to use the JS APIs than build a native app, so I want to make sure the web APIs support the MIFARE Classic 1K NFC cards, when the device does. Do either of you know who I can reach out to on the Chrome team about adding support for MIFARE cards within Chrome's implementation of web-nfc?
@zolkis and @cyberphone I can say that I want to build a web application where employees of my company can tap their NFC cards on a mobile device running this web app to mark themselves as physically present at a point-in-time. For me, it's much, much easier to use the JS APIs than build a native app, so I want to make sure the web APIs support the MIFARE Classic 1K NFC cards, when the device does. Do either of you know who I can reach out to on the Chrome team about adding support for MIFARE cards within Chrome's implementation of web-nfc?
Thanks for your interest. Web NFC is going through Origin Trials where developers can try out and give us feedback. For details, do check @beaufortfrancois's article. We will definitely weigh the pros and cons for this feature request soon.
The implementation does support NDEF on Mifare Classic and Plus tags, if the tags are configured to use that. We do not support any proprietary Mifare protocols
Right @kenchris, just verified the tags we tested on is MIFARE Ultralight and we used Ndef.
Ultralight is actually an NFC Forum compatible tag - which Classic/Mini and Plus are not.
Hi @riju , is this feature available now in Chrome browser to transmit digital key to door locks to unlock it? Waiting for your reply.
@mini1989cloud : No. WebNFC only works with NDEF and the hotel key scenario would need a bit more, so right now this is out of scope.
There are a few issues that makes this less useful where the most fundamental is how to get the URL to the Web application for the initialization. It seems that using NFC for handing over a URL to the mobile browser would be a better starting point. The Web application could in turn talk to a native application. This would also work for remote key initialization.
Usage of keys requires a completely new system since only the proper issuer of a key should be able to retrieve their particular key like in FIDO. This scenario seems to be pretty close to ticketing as well.
Web2Native application access: https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf
Since the provisioning of hotel keys can be done entirely remotely I have begun looking into other solutions as well for "physical Web" invocation. This one looks quite interesting: https://www.computerworld.com/article/3490037/ultra-wideband-explained-and-why-its-in-the-iphone-11.html
[ ] Replacing room keys : hotel room keys could be transmitted directly to the guests’ smartphones, replacing magnetic strip cards, so automatic checking, bypassing the front-desk. I will not be surprised if some amount of cryptography is involved in this mobile NFC access control systems to defeat cloning. We need to check which underlying protocols are mostly used and if that makes sense for our web-nfc. Ultralight, Mifare DESFire or even Mifare Classic are most likely to be used but I am not sure about the protocols used by key companies like Assa Abloy. I see Hilton is using native app already which is 166.9 MB, so maybe PWAs can fix. Urban House in Copenhagen and Dutch startup https://www.4suiteshq.com/ are connecting hotel locks to Cloud.
[ ] Automatic access to Wi-Fi
[ ] Housekeeping / Operations / Inventory Management
We are moving towards the domain of card-emulation which were not part of the initial plan, but its good to document our thoughts for future, specially the privacy and security aspects.