SysApps Face-to-Face #2 -- 29 Aug 2013

<scribe> scribe: Josh_Soref

<scribe> scribenick: timeless

DataStore

marcosc: zkis, you did some work showing that you could map contacts to this?

<room> draft API for W3C System Applications Messaging API, using DataStore concept

zkis: i removed the storage access methods -- they're provided by datastore
... i moved the sms/mms objects to navigator

<zkis> https://etherpad.mozilla.org/whatever-you-want

marcosc: how does the system know where to put the data for sms?

zkis: we'd need to agree to this
... i've renamed `name` to `type`

marcosc: how do you query this?
... does the datastore represent all objects?
... i don't see a cursor

zkis: the datastore doesn't specify underlying storage

mounir: the UC is to exactly not do that with Datastore
... if you want to get all contacts w/ FirstName=John
... you export all data from the Datastore into your own IndexedDB
... and that IndexedDB has its own structure / indices

marcosc: aren't you duplicating data?

Everyone: Yes

marcosc: it's screaming for other functionality
... IndexedDB is already a pain
... you're stuck w/ half the functionality you need
... data synchronization
... but nothing else

<Zakim> Josh_Soref, you wanted to answer

Josh_Soref: The idea is to make everything except synchronization painful
... to force you to pull all the information into your storage system (probably IndexedDB)
... you construct your IndexedDB (or whatever) to have wihchever indices you need

zkis: I want to be able to expose sim1, sim2, and phone as distinct sources of data

mounir: i don't want filtering in the datastore

marcosc: are we renaming DataStore to DataSource to indicate that it's not really a primary write api

Josh_Soref: yes

mounir: there's no UC for having isolation of data

Josh_Soref: BlackBerry Balance and Samsung's competition into the area shows that there is demand for isolation
... where an application or type of application have multiple things, one which they're ok w/ sharing to everyone, and one which users (or their supervisors) only want to share w/ some limited set
... chaals is not in the room (and not on the bridge)

zkis: is there something we can draw on?

marcosc: yes

[ Marcos wanders off to get something for scribbling ]

<chaals> [Yes, being able to identify data from different sources has use cases.]

<chaals> [SIMs are "often" (for rich users with lots of money to spend) effectively related to location (for poor users they are related to cheapest way to connect to someone)]

<chaals> [either way, knowing which source "taxi", "john" and "jo*" come from is extremely useful in practice]

marcosc: i think that (what chaals said) makes sense
... Adding .. if you have two sims and you add, and you can't target the sim, what does that mean...
... is that missing/useful?
... if i want to add Bob as a Contact for sim2
... how would i do that?

zkis: let's solve reading first

<chaals> [If you can't decide which SIM to add to, you have a fail]

zkis: partitions ...
... as a platform provider, i want the freedom to define how to put the sim data -- together, or separately
... i want the freedom for merging/not merging online sources

gmandyam: zkis, where would end user dialog boxes appear?
... an application that wants something from the dataS*
... targeting something that's application specific
... where would a dialog pop up, what would it say?

zkis: dialogs pop up, that's a policy
... for accessing this data, you need this permission
... if an application gets Facebook, or All, that's by app

<inserted> gmandyam: Where is the security boundary?

Josh_Soref: The security boundary is at Navigator.getDataStores(type)
... whether your signature entitled you to all, or you get prompted
... and whether you permanently grant that source to that client-app

gmandyam: ok
... I think this does handle the Gallery API UC too

marcosc: ok
... i think that was good
... we made good progress there

genelian: on UCs
... we have a "special type of SMS"
... a "silent SMS"
... fairly similar to regular SMS
... when radio interface receives a silent SMS, the system doesn't reflect that
... can the DataS* api manage that?

zkis: that's binary/port targeted
... and the system won't dispatch it to this API

marcosc: are they stored?

zkis: they are not serialized to the sim, they are associated with it and dispatched or dropped immediately
... what's next?

marcosc: sounds like it's a good thing
... we know there are issues
... can we retrofit apis to fit this?
... kind of maybe

zkis: can we make a resolution to use it in the spec?

mounir: i don't think we should resolve to use the api
... unless people agree to the UCs
... i think we have fundamental requirement differences

zkis: so you're suggesting dropping the whole thing?

mounir: i think we should think about it and see how we should go

zkis: who looks into it, how, how does this work?
... i could do work on messaging/telephony, or work w/ chris/eduardo on contacts

marcosc: i could work on it

mounir: chris could update contacts
... eduardo updates messaging
... what if some people want to implement, some don't
... some think it's a good idea, some don't
... if you want to do updates, i'm not going to forbid you
... i don't feel consensus

zkis: let's vote

thinker: datasource for other apis ... contacts/messaging
... we have a lot of api to define similar

marcosc: yes/no

mounir: you can't do yes/no... yes for what?

[ Argument between mounir / marcosc -- both of Mozilla ]

zkis: if you're giving this to the community
... and letting it be changed

mounir: the requirements you have are not the requirements we have
... i won't commit to that

zkis: it's adding one property

mounir: it's changing the meaning

anssik: we could commit to refining the UCs

zkis: i need a clear answer from Mozilla

wonsuk: i don't think we made a consensus now
... how about more time for discussion
... not all participants are here at this meeting
... i want feedback from other editors
... and we can make a decision later on how to handle this API
... i'm not sure the scope

zkis: first we need UCs and Requirements

wonsuk: we mentioned Messaging/Contacts
... gmandyam mentioned Gallery

gmandyam: and mounir said sim card was out of scope

<anssik> +1 on clearly defining UCs and Reqs and then let the wider group review them

marcosc: ok, we'll take it to the list
... it isn't ideal
... i think it's fair to give the other editors a chance to look at it

dsr: i heard yesterday that we wanted to simplify the other specifications
... rather than saying in-scope/out-of-scope
... -- i'll type the rest

<dsr> We talked yesterday about simplifying a number of our specifications by refactoring them, that in turn implies understanding whether our respective requirements for those specifications are compatible or not. This should drive the work not questions of scoping for a datastore API.

Event Pages

anssik: wondering how we'd like to use the session. we reviewed what we proposed w/ kenneth_
... i'd like to propose real time updating the proposal
... it's on my github
... you could send pull requests
... people could point to the spec/section.
... let's not use github issues

<room> https://etherpad.mozilla.org/event-pages

<anssik> Application Lifecycle and Events

Order of business

mounir: the next time-block will have two sessions in parallel

marcosc: in 45 minutes we'll have a Sockets meeting concurrent to this meeting
... this block will run for two hours
... we have half an hour afterwards
... my idea was that each group would give a summary of what they concluded -- then
... i don't really expect this to be minuted

Event Pages

anssik: there's a question of whether we're basing stuff on Workers or ...
... it's on the etherpad

marcosc: "Runtime" is weird, why not "App"?

mounir: because chrome does that

[discussions happenning without scribing]

<chaals> [OK. I'll ask someone what happened]

Break outs

Event Pages has moved to the other room

The main room is now informal

Sockets has moved somewhere

<anssik> https://etherpad.mozilla.org/event-pages

<anssik> http://localhost/~akostiai/sysapps/runtime/app-lifecycle.html

<anssik> s/http://localhost/~akostiai/sysapps/runtime/app-lifecycle.html/http://anssiko.github.io/runtime/app-lifecycle.html/

<anssik> http://anssiko.github.io/runtime/app-lifecycle.html

<dsr> http://gnosis.cx/publish/programming/sockets.html

<dsr> http://nodejs.org/api/net.html#net_socket_write_data_encoding_callback

<dsr> https://developer.mozilla.org/en-US/docs/WebAPI/TCP_Socket

http://stackoverflow.com/questions/2014033/send-and-receive-a-file-in-socket-programming-in-linux-with-c-c-gcc-g

// You need a loop for the write, because not all of the data may be written

// in one call; write will return how many bytes were written. p keeps

// track of where in the buffer we are, while we decrement bytes_read

// to keep track of how many bytes are left to write.

void *p = buffer;

while (bytes_read > 0) {

int bytes_written = write(output_socket, p, bytes_read);

if (bytes_written <= 0) {

// handle errors

}

bytes_read -= bytes_written;

p += bytes_written;

}

http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html

If fildes refers to a socket, write() shall be equivalent to send() with no flags set.

http://pubs.opengroup.org/onlinepubs/009695399/functions/send.html

ssize_t send(int socket, const void *buffer, size_t length, int flags);

RETURN VALUE

Upon successful completion, send() shall return the number of bytes sent. Otherwise, -1 shall be returned and errno set to indicate the error.

<dsr> http://linux.die.net/man/3/send

<dsr> If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, send() shall block until space is available. If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does have O_NONBLOCK set, send() shall fail. The select() and poll() functions can be used to determine when it is possible to send more data.

<dsr> http://nodejs.org/api/net.html#net_socket_write_data_encoding_callback

https://github.com/joyent/node/blob/master/src/stream_wrap.cc

https://github.com/joyent/node/blob/master/src/tcp_wrap.cc

<mounir> zaki, who is on the call?

<mounir> [lunch break because Intel guys want to eat]

Agenda

mounir: i had this slot for SysInfo, but the person who was going to call in isn't here
... we'll move that to later
... we could start w/ dev outreach

Dev outreach

mounir: we're missing feedback a lot
... we're missing Implementation Feedback
... we're missing Developer Feedback
... we don't know if APIs are following a good path
... we don't know if developers will like them or not
... we were wondering if dsr could talk to the W3 dev-rel team
... do people here have feedback from dev-outreach?
... or would they be willing to do dev-outreach?

dsr: sure, i can contact the dev outreach team @w3
... but there's only a few of them
... wondering what we can do from our website
... or elsewhere to reach out directly

marcosc: no...because...
... when we publish stuf
... Lea Verou sends things out
... it reaches quite a few people
... but one-to-one outreach
... perhaps we want to encourage developers to contribute UCs
... or contribute examples of what they've written

mounir: i've considered getting a Twitter account
... for SysApps, and maybe tweet
... web developers have and use twitter
... marcosc and I tried to get people from public-script-coord
... but we didn't get much

marcosc: some were good, some were not so good

mounir: people said very little
... it's hard to get feedback w/o anything working
... i'm more optimistic from developers using FirefoxOS APIs

opoto: would it help
... if we had some way to rapidly share prototypes
... so it isn't something fully compliant, but something to play w/

<wonsuk> +1 for opoto

marcosc: coincidentally
... we've tried to do that from the beginning
... the original Alarm had a reference Impl
... mart has rewritten that, there's a JS impl
... there's a pull request yesterday
... I hope to be able to write a raw sockets api on top of Node
... but we need help
... writing real or lightweight impls
... they don't take too long to write
... especially on top of node or FirefoxOS

Josh_Soref: can i put in a plug for Cordova?

marcosc: i spoke w/ Fil Maj
... they were keen to do stuff

mounir: implementations behind flags is not enough
... we don't get feedback until we push stuff to a release build
... i've tried to get more developer feedback
... by pushing apis in a limited ecosystem
... we did that for Contacts API for example
... we fixed a lot based on that
... Contacts API is only available in FirefoxOS to signed apps
... which let us get feedback from some developers
... we weren't in a position that we couldn't change the api later
... which is a big issue w/ experimenting
... marcosc, can you ask the mozilla dev-outreach group?
... dsr, the same to w3?
... and i'll create a twitter account and tweet

<mounir> ACTION: marcosc will contact the dev-rel team at Mozilla to do some dev-outreach [recorded in http://www.w3.org/2013/08/29-sysapps-minutes.html#action01]

<mounir> ACTION: dsr will contact the dev-rel team at W3C to do some dev-outreach (marcosc recommends contacting Léa Verou) [recorded in http://www.w3.org/2013/08/29-sysapps-minutes.html#action02]

<mounir> ACTION: mounir will open a Twitter account for sysapps and publish some stuff to get developers attention [recorded in http://www.w3.org/2013/08/29-sysapps-minutes.html#action03]

<marcosc> http://2013.lxjs.org/

Coordination and infrastructure

<scribe> scribe: mounir

marcosc: it seems that the github system is working well
... something I have done is adding people to some groups so they got more emails
... is that something that bother people?

[discussion about what to do with ACTIONS recorded]

mounir: I will take care of the actions

marcosc: have ppl got troubles?

mounir: it is still hard to follow what's happening without being following a github repo

marcosc: following what is happening in github is not much
... I try to look at pull requests to check if things should move to the list
... but we don't want to slow down things

wonsuk: what about test cases in github?

marcosc: it is too early
... we need to go to last call
... we did some tests for app uri scheme but this is because that went to LC in webapps
... jmajnert will tell you that there are a lot of tests in widget, it takes a long time to write test suite

dsr: why not add test even if it is not complete?

marcosc: we do TDD (Test Driven Development)... 1 sec...

[showing his AlarmPI tests]

[he lost himself in his GH page]

<Zakim> mounir, you wanted to ask if we could get PR emails in the list

mounir: what about having PR emails in the mailing list?

marcosc: I do not know if we can filter PR/commits/issues?

mounir: I will have a look

marcosc: ... unless they added this feature recently

<lgombos> cq+

[marcosc speaks about tests and webkit]

<lgombos> [scribe] as agreed yesterday once the test are getting mature we should push them to the official w3c test repository

<dsr> See http://www.w3.org/QA/2013/08/event_report_test_the_web_forw.html for recent testing the web forward event

anssik: why not send tests to web-platform-tests?

marcosc: I guess we should do at least one
... Marta and I could send something just to see how it goes
... and I told tobie that we will do so

Device Capabilities

<anssik> http://www.w3.org/2012/sysapps/device-capabilities/

anssik: we have something in our charter for this
... lets look at the charter

[showing the charter on the screen]

[reading the charter]

anssik: some of our guys from China have been looking at this
... we have something in Chrome behind a flag, not really this spec but something similar
... we tried something similar in DAP, it was called System API
... IIRC, that spec was shelved because we were not comfortable exposing that API to the Web because of the fingerprinting concerns
... I do not think we should look into this in details
... it has been written by people fairly new to the W3C process so do not mind the spec language
... what I would like to ask the group is if this is in scope and what are the UCs?
... we would like to hear feedback from other implementers if there is interest
... basically the overview of the specification is that this is a simple API to get system information
... things like information about the available memory, the device available storage space, CPU, number of cores
... as an example, one of the UC is to figure out how to split the tasks amongst workers
... to do that, you need to know how many cores the client has
... what timeless said is that we can already do that today by running computation in N workers and see what is the value of N that is the most efficient
... this is split in different methods, like getCapabilites() that return a list of booleans
... for example, there is 'multiTouchCount' to know how many touch point there is

marcosc: it seems that all of these should go back to the API that defines those things

anssik: yes, the editor pointed that at the beginning of the specification
... that was my guidance, this is probably not needed

gmandyam: have these spec editors confirmed that this information can be retrieved? for example, there are things here that need to be read from the modem but we never got request to expose that from our customers
... you talk about use of wifi for indoor location or gps for indoor location but you might be using a combination of two
... this is not something that is exposed by the modem
... did your guys look at if this information is queriable?

anssik: I am pretty sure they did not look at your chipsets, this is why we have the discussion here

gmandyam: is that implementable from an Intel stand point?

anssik: yes

gmandyam: is it useful?

anssik: it is another discussion

gmandyam: I am not sure we will get the two implementation support here

anssik: we should think about if there is use cases if any and then we should see if this is implementable

jungkees: I do not know if this is appropriate at this time but I have a comment regarding the WebIDL design
... in 5.1, there is a mistake [did not catch the details]

<jungkees> interface DeviceCapabilityProfile should be rather defined as a dictionary as interface object would not be needed in JavaScript binding.

<gmandyam> For what I was referring to (PMIC-targeted API), see the Trepn description at https://developer.qualcomm.com/mobile-development/performance-tools.

<room> http://www.w3.org/2012/sysapps/device-capabilities/#devicecapabilities-interface

[discussion that no one scribed :(]

gmandyam: I think the editors should make the difference between the things that are meaningful and those that are not
... I understand the UCs but they should step back and see how developers actually use these things

anssik: we should come out with compelling UCs first...
... it seems that some improvements should be done
... in some APIs but this is out of scope for this WG

<gmandyam> For instance, exposing the no. of active cores: this is dynamically managed in typical multicore CPU's based on e.g. loading, thermal mgmt., power mgmt.. It is not clear a developer can leverage this info, and may actually harm their app performance based on knowledge of such info.

<gmandyam> The editors should go beyond the typical W3C description for use cases, and consider exactly how developers would use each system capability exposed through this API.

wonsuk: following DAP experience, we should have UCs
... and split in different specs if needed

lgombos: do you expect to change Chromium as you go or are you going to wait until you have a better version of the spec?

spoussa: the Chromium API is changing all the time so it is not stable anyway
... it is a subset of that
... they seem to have UCs for those APIs

genelian: I notice lots of capabilities in the profile and it seems that it is mostly a yes/no value
... what if the system has more complex answer like if it doesn't want to expose some capabilities?

anssik: generally, developers do this currently with feature detection
... by looking if the objects exist or try to use the API before assuming if something is present
... generally, web apis should be feature detectable but that is not the case in all APIs

RESOLUTION: the editors of the Device Capabilities API should come back to the group with a new specification with some UCs

Secure Elements presentation by Gemalto

http://www.w3.org/wiki/images/6/6f/SysApp_-_Secure_Element_API_-_intro.pdf

opoto: this is an introduciton to collect some feedback on this subject
... this API is identified in phase 2 of the WG
... for those of you not familiar with secure elements, there is smart cards
... with contact or NFC (one, the other or both)
... these smart cards are used in many application domain such as ID cards
... from governments or corporations
... In these secure elements the chips is running a Java Card VM
... and the communication with the SE is a standardised API (ISO)
... these are used everywhere including mobile world
... there are also some SD cards that embed secure elements
... some of them with contact-less interface
... some device embed hardware secure elements
... which offer secure service such a tamper-proof storage, crypto op, ...
... we would like to allow web services around SE
... the environment in which we want to use these SE are PC, mobile, tablets, ...
... in the PC world it might be more common to have smart cards
... on mobile you will mostly find either sim cards or nfc
... also, some embedded secure elements
... one of the main UC for SE is for doing auth
... the SE is able to host a credential such as a key
... based on these secrets, it is able to authenticate a user
... the user can present a smart card instead of typing a user/password
... which, we know, is bad regarding security
... the user would have to type a PIN code
... and then, it will compute a cryptogram that certified that the user is genuine
... this is the scenario that you could have in a web application
... you could also have a system application such as a VPN using this kind af auth mechanism
... in addition to auth, you would also be able to do signing, for example in email clients
... to digitally sign an email with your SE
... these are typical UCs that we would like to address

zolkis: how can we make sure that this is a genuine UI (regarding the PIN code)?

opoto: this is something that is addressed by the trusted execution environment in the mobile world
... the environment is trusted, from the input to the display
... you would need some secure execution environment

<gmandyam> Contrast UC 1 in the presentation to what FIDO Alliance supports

<dsr> http://www.fidoalliance.org/how-it-works.html

gmandyam: it seems to me that what FIDO is doing could cover UC #1 [from the presentation]

opoto: FIDO alliance cover some of those scenario but they do not cover some other UC like authentification with a SIM card

gmandyam: fair enough but we want this to go further than SIM card
... but what you are proposing is specific to SIM card

opoto: no

<Josh_Soref> +1 to gmandyam 's concern that this seems to be specific to SIM card

opoto: maybe there is some overlap with FIDO alliance but I do not think they are covering all the UCs

dsr: I think we should look at the low level vs high level API here
... we have some low level APIs [some examples]
... but some high level API like [can't hear]

<dsr> Cites experience with HTML object element which proved valuable e.g. for Flash, and we now have standardized a high level API for specific cases e.g. the HTML5 audio and video elements

<dsr> ack

opoto: another interesting UC is for mobile commerce
... what is currently used today to pay is either a very simple payment scheme where you only provide your account/CC details
... with no verifications
... or the payload that a bank propose
... but with this, you could directly pay with a SE that embed the payment application
... it could be a NFC visa card in your mobile
... the SE could communicate with this card to sign the transaction

<gmandyam> AFAICT, there are multiple standards bodies working on API's that access the SIM. OMA OpenCM API for example, which has web bindings. GlobalPlatform is taking up API's for SE's, and this standards body has much stronger expertise in this area than the W3C.

opoto: another UC is for updting the context of a SE
... for example, in a public transportation card like London's Oyster card
... with this API what would be interesting would be to buy tickets on this card online
... you should be able to pay online and load content in your SE
... another UC is out of bound authentification
... this is when you use a second device to authenticate
... for example, you use your PC and you want to authenticate with your mobile
... Instead of entering the credetials on your PC, you use your mobile
... so you do not disclose any information on the PC
... which is very useful if you use a computer that you do not trust in an internet cafe, for example
... those are only a few examples of what can be done with this API
... if you want to see some demos, feel free to ask us
... of course, this is not something new, there are already some organisations that worked on this
... in particular the SIM alliance group, to define an Open Mobile API to define a SE API
... this API has been implemented in several mobile environment
... A similar API has been defined and used in other organisations such as Tizen and Webinos
... those are Web APIs similar to the one from the SIM Alliance
... those APIs are available in many devices
... in particular the SIM Alliance one is available in many Android devices
... there are 180 devices released with a SE API
... but on those devices, it is not a Web API but a native API
... so what we want to do here is to have similar API but for the Web
... so, what we propose it to start drafting a specification

<dsr> SE API essentially exposes APDU access as defined by ISO/IEC 7816-4 and widely supported in SIM and smart cards etc.

opoto: with UC and requirements

<Josh_Soref> BlackBerry 9900 (OS 7.1) Secure Element/NFC

opoto: Tran, from Intel said that he would be volunteer to participate to this specification

<Josh_Soref> BlackBerry 7.0 NFC API

<Zakim> mounir, you wanted to say that we have a payment api/tf for that

<Josh_Soref> W3 Payments Task Force

gmandyam: just to clarify my early comments: we know that we need SE access but the question for this group is whether we need to expose this API to third party developers
... and when I discussed this internally... this was one of the most difficult API to implement internally
... and when I asked how many developers wanted to use this in a third party application, there was none
... all users are pre-installed
... so I am asking you Olivier, what is the demand?

opoto: well... for sure, this API does not exist
... so no developer use it
... we are offering something, so it is not easy to know who would use it

dsuwirya: this is a chicken and egg problem
... you can't know how many developers use the API if it is not available
... government, companies, might use this API if it is an available API
... for public use, it is more for eGov UC like eServices, to pay your taxes, etc.
... this is an application that would be published by the government for citizens

<kjwallis_> Mobile payment with app accessing secure element on SIM card

dsuwirya: at the end it is going to be a signed packaged app, it is not a regular app

opoto: this is why we want this work to be done to the sysapps WG
... we want the applications using this API to be trusted
... also, we want that only authorised applications can access the SE

<gprintemps> We need also a way to receive events fro SE

mounir: you are dodging the question by saying it is a chicken and egg problem
... you said that there are many native implementations

dsuwirya: this is going to be a niche market
... Gemalto has interested clients
... it is not a matter of number of developers

<gprintemps> All operators will be interested by these APIs

dsuwirya: without this specified, it is not possible to have an application to access the SE

dsr: the workshop regarding payment is happening next year
... at this point, it sounds likely that we will be using packaged applications to do this

<gprintemps> Purpose is not only payment but to have a generic channel to discuss with SEs

<Marta> it it likely they will use it or it is not likely?

<dsr> the secure element API would be useful for payment solutions built as sysapps.

<timeless> scribe: Josh_Soref

<timeless> scribenick: timeless

mounir: what are member positions on this?

[ Silence ]

mounir: this seems like a niche
... we have other things to do
... we should probably focus on other things to do
... i'd be interested to know who would implement it
... i doubt mozilla would implement it
... if people would be interested in implementing it, it might help

<dsr> I forgot to add that secure elements will be important for corporate apps for enterprises.

wonsuk: as the Samsung representative

<gprintemps> Why will Mozilla not implement it?

wonsuk: we want to support this
... we already have SE API in Tizen

gmandyam: what does that mean?

<inserted> scribe: mounir

gprintemps: I mean, we will not implement it anytime soon

<gprintemps> This APIs can also be used by non web os devices

<timeless> scribe: Josh_Soref

<timeless> scribenick: timeless

mounir: speaking as Chair
... if we take this work item
... there will be one group working on it, Tizen
... they'll do it
... and much later someone will come and say "i completely disagree"
... i'm trying to save bandwidth for the group
... we have many things to do
... we have many things Mozilla and Tizen are interested in working on

gprintemps: I'm discussing w/ manufacturers
... and also OS providers
... non web providers
... not just Tizen/Mozilla
... but other vendors like Google and Microsoft
... i'm pretty sure that this API is really useful
... you cannot
... it's useful because you can create an application that can run on different OSs
... the main problem we have is that we have to rebuild our application for each OS
... HTML5 is the key for having NFC technology working on different OSs
... w/o a W3 API
... for access to SE
... w/o it, we'll never have wallet on WebOS
... w/o it things won't have a thing for iOS/BlackBerry/WebOS
... as opoto mentioned
... having the same application on iOS, WP, BlackBerry, WebOS, Firefox, Tizen
... it's a key for us to develop an app based on NFC
... not P2P
... not ...
... i'm talking about Card Emulation mode
... all apps based on Card Emulation mode
... won't be built in HTML5 w/o this
... the risk is fragmentation

<Zakim> mounir, you wanted to say that NFC is another api and that we need other bits before working on SE if interoperability is the important thing

gprintemps: the main risk is fragmentation

mounir: I think W3C is working on NFC in another WG, maybe NFC
... i think SE is below NFC

<gmandyam> NFC WG: http://www.w3.org/2012/nfc/

mounir: i think we can do NFC w/o defining an SE api
... Interop is important
... we want a web application is a web application that works everywhere
... SE API is quite not the priority
... if we don't have a runtime that mentions a security model
... if we don't have a packaged application system

gprintemps: i'm in the NFC group
... we're only doing P2P and Reader Mode
... but they're scoping out Card Emulation mode
... in NFC WG we're focusing on Reader-Writer Mode and P2P
... if W3 wants to handle NFC
... we want to handle all 3 modes
... not just Reader-Writer and P2P
... using NFC for transactions
... but for opening doors
... for loyalty cards
... for them, we need access to the Secure Element
... it's key because it can contain the application
... it can contain the ZZQ
... it's secure
... it's something we don't have
... why on the PC, can't you put the credit card in your reader
... all laptops have readers
... why can't we put our card in the reader
... why can't we put the numbers in?
... for banks it isn't secure
... this is for bank cards, loyalty cards, etc
... we need a way to store these in a secure way
... i'm not talking about UICC
... i'm talking about all SEs

marcosc: does anyone here have a laptop w/ a secure element

dsr: i have one

[ People show marcosc are card reader slot ]

dsr: some systems have card readers too
... i'm hearing we don't have consensus
... but there's interest in looking at UCs
... and identifying the target commuunity

mounir: i want to see the NFC and Web Payment groups looking forward
... likely they could specify in those groups if they want those bits

opoto: the NFC does not cover all the UCs
... #1 that i mentioned was online authentication
... the scenario that you have a smart card and a pc w/ a reader
... and you authenticate w/ PKI in your smartcard
... it's neither payment nor nfc

dsuwirya: the biggest UC is the SIM card access in the mobile
... PKI usage
... authentication/signature
... is not something addressed via NFC
... that's an app using UUIC directly

<Zakim> dsr, you wanted to suggest we continue work on use cases and the target developer communities and to mention corporate provisioning of SIM or microSD cards with enterprise SE

dsr: it isn't just about NFC
... for Enterprise

<marcosc> [Marcos impressed by "the future" of computing] :)

dsr: you could provision apps through the SIM/uSD

wonsuk: we need to gather UCs
... and gather feedback from members
... i don't want to reject/pending for this work

mounir: i don't think we have enough traction to go through the entire process
... we already have enough issues for the items we're working on

marcosc: we have a good opportunity for Tizen(Intel, Samsung) to provide implementation feedback
... pioneer w/ web tech and then we can learn for free
... it isn't that people disagree that it's great stuff
... but getting it to work and showing it working
... Mozilla doesn't have any IPR
... there's nothing we can contribute
... we can provide API design help
... but it feels early to standardize

Josh_Soref: +1

marcosc: as a web tech, it feels a bit immature
... we don't know how it's going to work
... there's potential to do this innovation
... we should standardize after innovations happen

Josh_Soref: +1

mounir: you mentioned authentication
... Google, Facebook, Twitter had issues w/ authentication on the web

<Zakim> mounir, you wanted to ask for auth feedback

mounir: do you know if they think it's a solution for this?

opoto: this isn't something we discussed with those players

[ Strike 1 ]

mounir: honestly, you should talk to them, and get them (Google, Facebook, ...) to come back and say that they want this
... everyone would run to implement that

Josh_Soref: +1

opoto: Google/Facebook are big companies
... but this is likely to be used in corporate or more restricted environments
... as Gemalto, we know customers are interested in those technologies
... we have products based on proprietary solutions
... we'd like to replace them w/ standards based solutions
... there are governments interested w/ those authentication mechanisms based on web
... we have products based on this

timeless: w3 does have members who are goverments or represent governments
... if you can get some of them to appear on the table, we will listen

<genelian> link?

opoto: we have Intel, Samsung, Gemalto,

<anssik> http://www.w3.org/Consortium/Member/List

Josh_Soref: there are government members

mounir: we should write a resolution...
... i feel we should consider later
... maybe w/ more feedback from NFC and Payment effort

<anssik> Electronic Governance CG

mounir: and see if we can get more people around the table interested in doing
... does that sound ok?

dsr: sounds like we need more participants from stakeholders in this group
... and we'll need more implementations than just Tizen

anssik: on editing
... i think the editors here aren't editors elsewhere
... so on resourcing, i don't think you block much
... so i don't see that as a major issue
... from a scope PoV
... i don't think it's a big thing
... but from priority, i wouldn't be working on that
... i'll be working on event pages

mounir: obviously, every company can do what it wants w/ its resources
... if opoto and dtran want to work on it
... they're welcome to
... my point is we shouldn't take that spec as an official draft of SysApps

<gprintemps> DTAG can help

mounir: ala Runtime, where no one had looked at it and given feedback

anssik: how about starting w/ UC and Req
... marcosc has good experience

marcosc: we have a presentation

anssik: would it help to refine the UCs?

marcosc: i'd prefer they iterate
... i'm guessing most experience is from Java Apps/UIs

anssik: if you could gather those

marcosc: there might be UI constraints
... there might be Java interfaces
... there's all this stuff about Flooding the little chip
... those are important things
... those constraints or whatever that need to be taken into consideration

Josh_Soref: +1 to worrying a *lot* about those constraints

marcosc: you can prototype using
... you could throw up a web view in android
... and use the web view to expose the JS object
... do a prototype on that

mounir: you can do a chrome/firefox extension

marcosc: oh, yeah, do it in Firefox
... "i'd recommend you do it in Firefox"

[ cough ]

opoto: we have experience in Firefox

marcosc: does it expose JS API?
... you have implementation experience?

opoto: yes

marcosc: that can be enough for standardization
... we could give you a bit of feedback
... that's a good rapid way to do it
... you could throw up a document
... you can do that to get it going quickly
... that would be good

<jungkees> +1 for this direction Marcos suggested to start over

<dsr> How about that Olivier and Tran continue to iterate the use cases and prepare a draft API for review as and when SysApps reviewers become available

<spoussa> +1 for dsr proposal

<mounir> RESOLUTION: Olivier and Tran should continue to iterate the UCs and prepare a draft specification for review when SysApps reviewers become available

mounir: we're nearly done
... does anyone have anything to add?

zkis: we were going to talk about Bluetooth/other phase two items?

mounir: we don't have any specs in LC?

marcosc: app: is almost in LC

mounir: at that point, if we add stuff
... we're just adding work
... but i don't feel we're going very fast
... it doesn't seem like a good idea
... but if someone in the group wants to trade a phase 1 for a phase 2 item

zkis: if there are new people working on them?

marcosc: which new people?

mounir: it's always valuable to have a draft sent
... that doesn't hurt
... we can look at it
... Mozilla has an API
... it sounds like Google has something
... if everyone is in sync
... you had someone next to you working on that
... does someone @Mozilla/Google have anyone to work w/ you on that?

zkis: another topic we spoke w/ sicking at the last F2F
... it sounded like there was interest in standardizing a way
... how audio/notifications are handled while a call is in place
... i have a draft for extending the notification API
... and a spec for extending output device recognition
... mozilla has a draft on this too
... sicking mentioned this would be interesting to work on that
... i have draft specs on it
... it would fit the charter
... when should we pull it out/start discussing it

mounir: re the charter
... i believe if it isn't in the list in the specs that are listed
... then it isn't in charter
... IANAL

[ thus it would require rechartering ]

mounir: rechartering is painful
... you could open a wiki page for things to add for the next charter
... i know webapps does that

dsr: we can try to recharter anytime we like
... but it's expensive

jungkees: in the morning during the runtime discussion
... we gathered a lot of items/issues
... i want to volunteer as a coeditor of application/lifecycle events
... at the beginning of the year
... i was working on a proposal w/ a similar idea
... i have the idea, and i'd like to help sort out the issues
... if it would help, i'd like to

anssik: +1

<Zakim> Josh_Soref, you wanted to say HTML is working on extra displays

<spoussa> can we have a link of that work ?

Josh_Soref: WebRTC was worrying about additional output devices
... and realized it was beyond their scope
... so they spoke w/ HTML
... who said it was indeed something HTML should do
... and the work was transferred there
... no pointer-- sorry

<zkis> indeed, the work affects HtmlMediaElement

marcosc: i heard notifications
... that should be sent to WebApps

Josh_Soref: +1

marcosc: if you have enhancements for that
... it would be better to put it there
... i've thought about similar things
... it would be useful in Web Notifications
... it was supposed to support html
... including video/audio

<anssik> Re: Fwd: Proposal for output device selection

Next F2F

mounir: the next meeting is @TPAC

anssik: was that Th/F?

dsr: i've asked about changing that
... it may take a few days to find out

mounir: we agreed to try to move the F2F to M/Tu
... to avoid overlapping w/ WebApps
... we scheduled to avoid overlapping w/ DAP, but DAP canceled

<JonathanJ1> http://www.w3.org/2013/11/TPAC/#GroupSchedule

mounir: we'll see the agenda and discuss later
... thanks everyone

dsr: thanks for hosting us

[ Applause ]

mounir: thanks for scribing

wonsuk: thanks Josh_Soref

[ Applause ]

mounir: thanks Facilities for the Heat

<genelian> thanks for Josh_Soref +1

<JonathanJ1> thanks for Josh_Soref +1

- DRAFT -

SysApps Face-to-Face #2

29 Aug 2013

Attendees

Contents

DataStore

Event Pages

Order of business

Event Pages

Break outs

Agenda

Dev outreach

Coordination and infrastructure

Device Capabilities

Secure Elements presentation by Gemalto

Next F2F

Summary of Action Items

Scribe.perl diagnostic output