Closed Nikolpol closed 1 year ago
I think you are correct that we need to use TNF_EXTERNAL_TYPE (0x04) and not TNF_MIME_MEDIA (0x02) for the NFC data retrieval Carrier Configuration Record since its type is iso.org:18013:nfc
which looks nothing like a MIME type (compare with application/vnd.bluetooth.le.oob
for BLE is or application/vnd.wfa.nan
is for Wifi Aware).
I think this needs to be spelled out in clause 8.2.2.2 Alternative Carrier Record for device retrieval using NFC but it currently isn't. I think that's just an oversight in 18013-5. I will reach out to the editor to confirm.
I will reach out to the editor to confirm.
I spoke to the 18013-5 editor and he agrees this is missing in 8.2.2.2. I will provide a comment so this can get fixed in 18013-5 Amendment 1.
Expected Behavior
During NFC engagement HRM with AC (alternative carriers) records are generated by the reader and parsed by mdoc holder to form HSM single AC selected. In the case reader includes NFC to AC list it should use TNF (Type Name Format) == 0x04 (NFC Forum external type [NFC RTD]) In case BLE, WiFi TNF == 0x02 (Media-type [RFC 2046])
Actual Behavior
Google apps use TNF == 0x02 (Media-type) for all AC records including NFC which is wrong
Justification
ISO18013-5 - 8.2.2.1 Device engagement using NFC
declaresSteps to Reproduce the Problem
Requires to analyze TNF AC record in NFC communication log to see that TNF == 0x2 for NFC AC has been used and accepted as correct. Non-Google app with TNF == 0 will lead Google app reports that no AC records was found in case only NFC was selected for communication
Set mdoc holder to use NFC transport carrier Perform NFC static engagement
Set mdoc reader to support NFC transport (which would be included in HRM in this case) Perform NFC negotiated engagement