A short write-up about the story of NDEF ID vs Web NFC Id vs Web NFC record. We tried for long time to use the NDEF ID for storing origins. If we only deal with that, we would not need a Web NFC record. This would be great for interoperability. There are 3 issues with that: - Jonas wanted that Web NFC messages are distinct enough, so not that much interoperability is desired eventually. - The NDEF ID is 255 bytes long, which can store an ASCII serialized origin, but cannot store paths. A few people considered paths important for watches and filtering. If we ever wanted to have that, the format needed to be generic enough to contain it, so we needed Web NFC records. The Web NFC Id is the origin + path. - Jonas wanted allowed-origin policies. For that we'd need Web NFC records anyway. In the meantime we figured out that on every platform to be supported, we can have support for writing multiple NDEF records per message, so having a Web NFC record did not have any obstacles. That's how we ended up using them, in a bit simpler form than in the first proposal, since in the meantime we realized that NFC content cannot be trusted at all for integrity, so we can't base any origin based policies on the content of the NDEF messages. Even if we defer the problem to an app store, still the terminology would not be correct from security point of view. That is why we need some other word instead of "origin" of a message. Best regards, Zoltan
Received on Monday, 7 September 2015 21:00:54 UTC