See also: IRC log
<scribe> scribe: Josh_Soref
<scribe> scribenick: timeless
<room> WebAPI/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.
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
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
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]
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> 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
// 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]
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
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/
<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
<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
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
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
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) Succeeded: s|https://wiki.mozilla.org/WebAPI/DataStore|-> https://wiki.mozilla.org/WebAPI/DataStore WebAPI/DataStore| Succeeded: s|https://etherpad.mozilla.org/un9XkdXeKh|-> https://etherpad.mozilla.org/un9XkdXeKh draft API for W3C System Applications Messaging API, using DataStore concept| Succeeded: s/can someone drop the link for the MozPad?// Succeeded: s/Gene Lian/Gene_Lian/ Succeeded: s/Present+ Gene_Lian// Succeeded: s/satorage/storage/ Succeeded: s/Datastore/IndexedDB/ Succeeded: i/boundary/gmandyam: Where is the security boundary? Succeeded: s/from mounir/from Mozilla/ Succeeded: s/... you could send pull requests// Succeeded: s/topic: Event Pages// Succeeded: s|http://anssiko.github.io/runtime/app-lifecycle.html|-> http://anssiko.github.io/runtime/app-lifecycle.html Application Lifecycle and Events| Succeeded: i/time-block/Topic: Order of business Succeeded: s/mounir/scribe/ WARNING: Bad s/// command: s/http://localhost/~akostiai/sysapps/runtime/app-lifecycle.html/http://anssiko.github.io/runtime/app-lifecycle.html/ Succeeded: s/thatlater/that to later/ Succeeded: s/as agreed/lgombos: as agreed/ Succeeded: s/lgombos/scribe/ Succeeded: s/did you guys/did your guys/ Succeeded: s/)L/)?/ Succeeded: s/AAA:/dsuwirya:/ Succeeded: s/Right - I'm calling with German number// Succeeded: s|https://www.cibc.com/ca/features/mobile-payment.html|-> https://www.cibc.com/ca/features/mobile-payment.html| Succeeded: s/scribe: as agreed/[scribe] as agreed/ Succeeded: i/gprintemps/scribe: mounir Succeeded: s/itme/item/ Succeeded: s/NC/NFC/ Succeeded: s/QQQ/Reader Mode/ Succeeded: s/juts/just/ FAILED: s/juts/just/ Succeeded: s/+q/q+/ Succeeded: s/]/ ]/ Succeeded: s/mounir/scribe/ Succeeded: s/mounir/scribe/ Succeeded: s/spec/draft/ Succeeded: s/thing/things/ Succeeded: s/../.../ Succeeded: s|http://www.w3.org/egov/IG/charter-2011|-> http://www.w3.org/community/egovernance/ Electronic Governance CG| Succeeded: s/revieeers/reviewers/ Succeeded: s/avaialbale/available/ Succeeded: s|s/juts/just/|| Succeeded: s|http://lists.w3.org/Archives/Public/public-html/2013Aug/0104.html|-> http://lists.w3.org/Archives/Public/public-html/2013Aug/0104.html Re: Fwd: Proposal for output device selection| Found Scribe: Josh_Soref Found ScribeNick: timeless Found Scribe: mounir Inferring ScribeNick: mounir Found Scribe: Josh_Soref Found ScribeNick: timeless Found Scribe: mounir Inferring ScribeNick: mounir Found Scribe: Josh_Soref Found ScribeNick: timeless Scribes: Josh_Soref, mounir ScribeNicks: timeless, mounir Present: Jungkee_Song Claes_Nilsson Anssi_Kostiainen Sakari_Poussa Wonsuk_Lee Gene_Lian Mounir_Lamouri Laszlo_Gombos Chaals(IRC) Jonghong_Jeon Agenda: http://www.w3.org/wiki/System_Applications:_2nd_F2F_Meeting_Agenda Got date from IRC log name: 29 Aug 2013 Guessing minutes URL: http://www.w3.org/2013/08/29-sysapps-minutes.html People with action items: dsr marcosc mounir[End of scribe.perl diagnostic output]