The NFC Forum recently released a set of new specifications. It consists of the new Connection Handover 1.4 Candidate Technical Specification, the Verb RTD 1.0 Technical Specification, and the Logical Link Control Protocol (LLCP) 1.3 Technical Specification. The new specifications are available now for download.

I’d like to provide some insights into the newly-released documents.

Connection Handover 1.4 Candidate Specification

The NFC Forum originally published the Connection Handover Technical Specification in 2008. It enables two NFC devices to pair with each other to exchange data on an alternative wireless communication channel (e.g. Bluetooth or Wi-Fi). There are already many solutions in the market that implement this specification – allowing, for example, users to pair an NFC-enabled smartphone with a Bluetooth headset or loudspeaker with a simple tap. Readers who own these devices know how easily a Bluetooth pairing can be performed with NFC.

At the NFC Forum, we’re always looking for new use cases and ways to improve the end-user experiences. That’s why, in 2014, we added the mediated handover mechanism to the Connection Handover 1.3 Technical Specification. It allows easy pairing between two stationary devices – for example, a large television and a pair of loudspeakers — that cannot be easily touched together. In this scenario, the mediated handover mechanism allows an NFC-enabled phone, for example, to be used as a transport medium for the necessary pairing data between these two stationary devices. All the user has to do is, first, tap the television set with the NFC phone, then tap the loudspeakers to pair them.


Source: Samsung

Now the NFC Forum is again extending the Connection Handover Specification with version 1.4. It defines a new mechanism that allows the end user to also specify an action or service to be performed with the transferred data.

For example, if a user has a photo on his NFC-enabled smartphone or tablet, then he can also request to print this picture when tapping the NFC device with a printer. The exchanged NDEF message not only contains the information to pair the printer with the NFC device, but also explains that a picture will be transferred for printing. This makes the user experience even smoother and simpler.

As another example, let’s say an end user has stored a photo on her NFC-enabled phone and wants to send it to the bigger screen of a tablet. She can decide if the photo will only be shown on the tablet or if a copy of the photo is to be stored on the tablet when she taps it with the phone. Again, this gives the user greater power in a single tap.

The Connection Handover 1.4 is currently released as a Candidate Technical Specification so that the market can review the new proposed mechanism and provide feedback on the specification. How is the new service information coded inside the NDEF message? With the new Verb RTD 1.0 Technical Specification. It enables developers to define which kinds of services are sought or provided by the NFC device. The Device Information RTD 1.0 Technical Specification, which was published last year, is also used by the new Connection Handover 1.4 Candidate Technical Specification to share information about the remote NFC device.

The new mechanism enabling the specification of services for transferred data is defined in a very open manner, thereby inviting market players and other standard bodies to easily define the services for their use cases which can be used by this new mechanism. We welcome all members of the NFC ecosystem to begin exploring ways to take advantage of this new capability.

LLCP 1.3 Technical Specification

After a validation period of one year for the LLCP 1.3 Candidate Technical Specification, the NFC Forum has formally published the LLCP 1.3 Technical Specification. During the validation period it was confirmed that the new secure data transport mechanism introduced by LLCP 1.3 is well defined and generates no interoperability issues between two devices implementing this new specification.

With LLCP 1.3 onwards, the peer-to-peer communication between two NFC devices using the LLCP protocol is automatically protected against eavesdropping. Therefore, the NFC applications need not implement any additional mechanisms to activate this protection as the secure data transport is automatically established by the two NFC devices implementing LLCP 1.3 or higher.

This mechanism improves the security of NFC communication, making it impossible for a third party to spy, for example, the exchange of business card data or a phone number when two users tap their NFC-enabled devices together.

LLCP version 1.3 uses an Elliptic Curve Diffie Hellman key exchange – a state-of-the-art cryptographic mechanism – to agree on an AES session key to cipher the exchanged LLCP packets.

These new features and capabilities demonstrate how the NFC Forum continues to add value to its specifications in response to market needs and in support of continuing adoption by businesses and consumers.