See also: IRC log
<scribe> scribe: Dave
<scribe> scribenick: dsr
<scribe> Agenda:
- Welcome
- Round table for introduction, interest, expectations
- Current draft specification status
- What's needed to move it to First Public Working Draft
- W3C Technical Plenary in November
- Plans for work on use cases and demos
- Other opportunities to draw attention to the work on the NFC API?
- Review Action Requests
- Next conf call timeframe
<virginie> mentions that virginie from gemalto just join, as an obeserver
Jacques introduces the meeting. This is our first audio meeting. The group has been growing slowly in numbers.
We've already started some technical work and we want to use this meeting to introduce it and plan next steps.
Introductions around the table, starting with Jacques, intel, and NFC WG chair.
Luc: I am also from intel and have been drafting the specification and work on a demo implementation on top on Linux.
Samuel: I am also from intel and helping Luc with the work.
Virginie: I am here as an observer and am from Gemalto's standardization team.
<lyriarte> Samuel Ortiz is the maintainer of the Linux NFC stack
Dave: I am from W3C and am the staff contact for this group.
David: I am from NACS and we interact a lot with card issuing companies and involved with EMV rollout. For the people on this call, I do not know of any patent issues relating to this WG. My employer is Verisign.
NACS = national association of convenience stores (USA)
s/Versign/Verifone/
Luc gives a quick introduction to the draft NFC API specification, currently an editor's draft.
It enables communication betwen NFC devices and reading/writing of NFC tags, as well as Bluetooth and Wifi handover from NFC.
It is linked from the working group page and from the wiki.
It matches the definitions from the NFC Forum for NFC tags. We invite feedback from the group. We plan to implement real life use cases as a means to test the API design.
Our implementation is based on top of the Linux NFC stack using websockets and also Node.JS.
Jacques: we are not talking about very low level interface, rather for the needs of web apps.
Luc: tag formatting, setting tags read only, and NFC communication.
Samuel: we don't provide direct access to LLCP packets right now as we didn't get the use cases, but it is something we would like to discuss.
<lyriarte> link:
<lyriarte> http://w3c.github.io/nfc/proposals/common/nfc.html
Gilles: I am working for Deutsche Telekom and working on NFC in respect to our handset requirements.
Also involved to an extent in Mozilla and FirefoxOS.
Dave: we need to be use case driven -- if we see new use cases, we can think about adding features later.
David: I agree with the use case driven approach
Luc: the first features will be high level, and adding lower level features later as new use cases emerge seems fine.
Samuel: what's the process for adding use cases?
Dave: I suggest briefly describing the use cases in the specification, and we can add new ones in subsequent updates to the published working draft.
David: it is useful to know the broad groupings of use cases along with a few concrete examples.
Jacques: that sounds fine.
Virginie: can the editor's briefly summarise these broad areas of use cases?
Samuel: essentially tag reading/writing, peer to peer and handovers, but not payment as that will involve a secure element API.
David: I would like to note that the secure element API would enable a lot of use cases in addition to payment.
Gilles: are we planning also to cover the NFC controller?
Samuel: yes, that is needed and could be added as an extension to the API.
We need some feedback from payment companies and companies like Gemalto to better understand the requirements.
Gilles lists some of the features involved in respect to the NFC controller.
Samuel: we are already covering part of that for powering/enabling/disabling the NFC, but we haven't addressed the card emulation mode at this time.
Gilles: I am just highlighting this as my experience in the payment area, shows the need to keep card emulation distinct from other modes.
Each time you have a transaction with the applet, it can raise an event. Everything is going through the SWP to the NFC controller.
Samuel: it should be part of the secure element API which regardless of the technology will have to report such events.
Gilles: when I read the spec/charter it was just a communication path, but there was no mention of the NFC controller. The event is handled by the NFC controller not the secure element. I don't have a clear solution to offer right now.
Samuel: it would be less
confusing for developers if we keep the eventing part of the
secure element API. This is something we can continue to
discuss
... we risk making the secure element API redundant if we
follow you suggestion.
Gilles: we still need a way to access applets in secure elements
Samuel: but you don't need to know about the underlying implementation (e.g. NFC, or SIM, ...)
David raises the info that W3C is interested in starting standards work on payment APIs.
Dave: We're not yet at that position, we plan to hold a workshop as a first step.
David: want to ensure that we don't cause problems by going too far too soon.
Virginie: Gemalto is leading the SysApps WG work in secure element API. We could usefully sketch an architecture as way to keep us all on the same page.
The secure element API in sysapps will start within a few months time, and we will need a close coordination with the NFC WG.
Virginie asks Samuel about the limited support for the NFC controller in the current spec, what is the entry point for that?
Luc: currently it is merged with starting/stopping polling of NFC devices.
We could split this into separate APIs if that makes more sense.
<virginie> http://w3c.github.io/nfc/proposals/common/nfc.html#idl-def-NFCManager
Samuel: we used to have a power property for turning the NFC hardware on or off.
We need to discuss card emulation before we start adding support for that and need your input.
Virginie: I will ask my colleagues to review the draft spec and come back with some feedback.
Luc: I don't have strong feelings one way or the other and welcome feedback.
Gilles: I can provide a use case for the card emulation mode (Contactless service registry). Security requirement to disable card emulation when screen is off.
If you have a lot of services, it is desirable to have a single method to disable them all e.g. when the screen goes dark
Samuel: you are talking about the services provided by applets?
Gilles: yes as well as tag reading and writing.
Samuel: I agree with that.
We also need to limit access to this service switch to trusted apps.
Dave: this relates to the sysapps runtime and security model -- we will need to review that as it proceeds to ensure it meets our needs.
Virginie: if DT or Gemalto bring some use cases, how will the NFC WG handle them?
Jacques: our part of view is to work on the use cases and integrate them into the spec.
<virginie> +1 to go to FPWD as it is now
Samuel: we should first add the current set of use cases into the spec, and work on card emulation and associated use cases for a later update.
Luc: it sounds like card emulation might be simple and could be added sooner.
Samuel: I would prefer to keep things simple for the FPWD and add richer features later when Gemalto has joined.
Virginie: yes, that makes sense to me at this time.
jacques: we should list the use cases we know now even if the spec doesn't cover them all.
Dave: that's fine, we can state that in the draft.
Virginie: to clarify, there will be a SysApps WG face to face in late August and the secure element API will be on the agenda. We can come back to the NFC WG after that.
Jacques: we should plan to meet at TPAC in November.
Luc runs through what he is working on.
He plans to support a demo on Linux and on Android.
Anyone else working on demos?
Dave: MobileAd is in the NCF WG and have said they plan to develop demos.
Jacques: what about the arrangements for TPAC
Dave explains ...
<dezell> DE apologizes - must leave for another meeting. Nice meeting you all.
Dave: events like NFC World Congress - where WG members could talk about the W3C work on NFC.
Virginie mentions other opportunities ...
<virginie> gemalto will speak of web consuming secure element services in Chip to cloud conference 'Security Forum'
Samuel: it would also be worth trying to gain a better understanding of what reasons they may have for not joining so far
Dave: I talked with Google, and it seems to be mainly a lack of visibility. We should use the FPWD to draw them in.
Samuel: what about the NFC forum?
Dave: yes we need to liaise with them, so let's talk
Jacques: mainly to work on integrating use cases prior to FPWD, using the mailing list to progress this.
Luc: adding power off/off is a little change. The rest e.g. Card Emulation would be done later.
Invites people to help him with the editing via GitHub.
Regarding use cases, the email list would be a good starting point for discussion.
<virginie> +1 for monthly basis
Jacques: may be monthly?
Dave: yes sounds good.
Jacques: I will schedule it in July.
Virginie: just one thing, thanks for inviting me as an observer.
Jacques: it has been a productive meeting. Talk to you in one month!
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/Versign/Verifone/ Succeeded: s/Yves/Gilles/ Succeeded: s/to /too / Succeeded: s/TPC/TPAC/ Found Scribe: Dave Found ScribeNick: dsr Present: Dave Jacques David Virginie Luc Samuel Gilles Got date from IRC log name: 24 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/24-nfc-minutes.html People with action items: WARNING: Possible internal error: join/leave lines remaining: <scribe> Samuel: I would prefer to keep things simple for the FPWD and add richer features later when Gemalto has joined. WARNING: Possible internal error: join/leave lines remaining: <scribe> Samuel: I would prefer to keep things simple for the FPWD and add richer features later when Gemalto has joined. WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]