W3C home > Mailing lists > Public > public-nfc@w3.org > May 2012

RE: draft charter for a W3C NFC working group - gemalto comments

From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
Date: Sat, 12 May 2012 22:57:48 +0200
To: Dave Raggett <dsr@w3.org>
CC: "public-nfc@w3.org" <public-nfc@w3.org>
Message-ID: <1126F161F6F1B24FABD92B850CAFBD6E0102BDD4BF5B@CROEXCFWP04.gemalto.com>
Hi Dave, 
My comment below, marked as [VG - gemalto]. 
Regards,
Virginie
gemalto

-----Original Message-----
From: Dave Raggett [mailto:dsr@w3.org] 
Sent: Friday, May 11, 2012 4:20 PM

On 11/05/12 14:22, GALINDO Virginie wrote:
> Dave, and all,
> 
> As gemalto, we welcome the W3C investigation on NFC and have some 
> comments on this draft charter :
>
> - by treating only NDEF format, there is a de facto exclusion of 
> payment/transaction applications, as this format is not suitable to 
> such interaction.

My assumption is that payments would be handled via Web Intents with a generic payment API between the web app and the payment solution. This allows the user to select her preferred means of payment and avoids hard wiring the web app to specific payment solutions.

[VG - gemalto] This could be a possible technical solution, which has to be further analysed. As Bryan Sullivan mentioned yesterday, the current state of web intent does not mention such payment feature. We should be able to discuss this usecase in the NFC WG (Or System Level WG, if we want to merge both), even if in the end, it is transferred to Web Intent. 
Another remark on that one, just to make sure I got it, would you develop the same Web Intent feature for a signature usecase ? The technical components are exactly the same, but the service is slightly different : a device in reader mode is offering a webpage where the user can sign a transaction/document, the user is approaching from this device a contactless card with signature capabilities (either for legally binding signature, such as identity card for government services, or 'normal' digital signature for corporate signature, for example). In this case, you are managing the same kind of data format as payment usecase to convey your data between the contactless card and the web app (APDUs). 

> One of the immediate use case that we see, is the interaction between 
> web pages running in a NFC device and a contactless card which is 
> swapped closed to this device to perform a transaction.

I would like to understand the technical implications in more detail.
Wouldn't it be the case that the web app could use the regular NDEF API to read NDEF formatted data, whilst the payment specific driver invoked via Web Intents would use the payment specific protocol?

[VG - gemalto] Yes, this would be right if we choose the Web Intent road, and if Web Intent is also designed for signature (see my remark above). 

> - On the recent requests related to LLCP, I would recommend that the 
> API deals only with the actual data transported thanks to LLCP, and is 
> not LLCP specific. One of the rationale for that is to tailor a future 
> proof API, which is not specific to the link layer (LLCP in that 
> case).

I understand that LLCP can be used for TCP/IP connections, and as such could support existing Web APIs for HTTP (XHR), Web Sockets or more simply HTML MessageChannel. The only requirement is that the communication channel is bidirectional and reliable in the same sense as for TCP/IP.

 [VG - gemalto] OK

> If you wish to make the WG charter consistent with my comments, you 
> may implement the following changes :
> - Section 2 - scope of the API includes APDU message management
> - Section 3 - card emulation mode exclusion is removed

I would very much like to understand the implications for Web APIs. We already have implementations based around NDEF and are confident in developing a standard for that. It would be helpful to know about the corresponding implementations at the level you describe.

[VG - gemalto] For the management of APDU messages, you basically need to have a NFC controller able to extract APDUs from the ISO 14443 messages and transmit it to the Browser, which would then make it available to the web app with a specific container. This treatment of APDU messages is already something that NFC controller do support. But let me come back with a drawing in the coming days, detailing the different needed technologies, it will be easier to explain. 


Best regards,
--
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Saturday, 12 May 2012 20:58:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 May 2012 22:57:28 GMT