- From: steven branigan <steven_branigan@hotmail.com>
- Date: Wed, 14 Jun 2017 02:07:05 +0000
- To: FREDFLT via GitHub <sysbot+gh@w3.org>, "public-web-nfc@w3.org" <public-web-nfc@w3.org>
I agree with the QRcodes comment, that technology should be left to GS1, I don't see how it is related to NFC other than QRcodes with RFID combined. Anders, take a look at GS1's datamatrix. Not sure how relevant the rest of this is to this particular discussion but I'm not sure where else to add it. I have a particular use case where the Australasian Rail Alliance (ARA) is planning to be GS1 compliant by January 2019. As part of the GS1 implementation the ARA intend on implementing DataMatrix alongside RFID as a way of both managing and tracking asset lifecycle. DataMatrix is the recommended GS1 asset management, similar to QRcode in many ways, but with much bigger data footprint. The datamatrix is used extensively in the medical device industry globally, think medication, patient wrist tags, medical devices that have a lifespan and need to be tracked, etc. As part of the GS1 compliance push I am leading a project to introduce RFID (and potentially datamatrix depending on whether we are required to have both) as a means for managing asset lifecycles from raw material to installed component (i.e. end to end). This is where my interest in RFID peaks... RFID's are expected to contain relevant data based on the GS1 standard. Data such as batch-codes, manufacture dates, country of origin, etc. should be readable directly from (and writable directly to) the chip. Additional data such as inspection intervals, inspection outcomes / results, contractor installer information, etc. will be accessed from a relational database structure built around the unique RFID identification HEX. Securitisation of the additional data will be done with the traditional session token to encrypt data between client and server for the life of the session. Reading and writing to RFID using a WEB-NFC would be ideal as it would allow us to put the technology into the hands of almost any user with an NFC enabled device. I think the existing read and write WEB-NFC development should be enough to do that but I still haven't tested it completely. When it comes to building a security layer into the WEB-NFC for things like financial transactions I think that is a development that should be left to the developers at the banks to work out. Exposing the RFID's HEX id to a web browser is the paramount cause here I would have thought. Maybe when it comes to RFID that contains data that requires to be secured then the way forward for that is to have the ISO standard for RFID reading / writing devices that requires an additional identifier at the start of the data string, similar to how GS1 barcodes are identified using the function 1 key. Just a thought? See http://xchange.gs1.org/sites/faq/Pages/what-is-the-function-1-character-fnc1-and-what-is-it-used-for.aspx Also, some RFID lend themselves better to large amounts of data, is encryption an option for the data written to RFID? Decryption would happen at during the client-server connection session. That I think is outside the scope of this group but for those who work at larger corporations it might be worth thinking about. Steve B. -----Original Message----- From: FREDFLT via GitHub [mailto:sysbot+gh@w3.org] Sent: Tuesday, June 13, 2017 21:05 To: public-web-nfc@w3.org Subject: Re: [web-nfc] Write-only Web NFC variant proposal Payment systems like Apple, Google, Samsung have their own problems.... and I REALLY don't care about doomed payment industry. We won't reinvent anything there. On the other hand, hardware wallet for cryptocurrencies, that's the future and we are working on it. BTW, I don't even understand why we are still talking about QR Codes here, this was not linked to Web NFC and QR code should only be used for one thing : easy retyping (copy/paste). -- GitHub Notification of comment by FREDFLT Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/128#issuecomment-308082313 using your GitHub account
Received on Wednesday, 14 June 2017 02:09:32 UTC