Systeam Applications WG face to face 9 April -- 09 Apr 2014

<zolkis> sooo.... whaaat's hap-p-ening? dialed in, but no reaction. This side of the bridge is connected, but what about the other side? Is that phone plugged in now? :)

<anssik> zolkis: try redialing, should work now

<zolkis> Present Zoltan_Kis

<genelian_> Data Store API spec: http://airpingu.github.io/data-store-api/index.html

Data Store API

<genelian_> Data Store API slides: https://www.w3.org/wiki/images/e/e1/DataStoreAPI.pdf

agenda bashing

<zolkis> anssi: +1

anssik: lets move the charter discussion earlier
... before lunch

mounir: I moved the charter discussion to the morning
... and the afterneen session is starting at 13.30 instead of 13.00

<anssik> excellent, thank you

mounir: done, next topic is Data Store

DataStore

<scribe> scribe: mounir

<scribe> scribenick: mounir

genelian_: we discussed this specification in the past
... with some other editors too
... so, what does DataStore API do?
... in the past, SMSManager, MMSManager and other
... specification had a filtering mechanism described
... but it couldn't fulfil all applications needs
... this kind of API doesn't work well for third party apps
... we had to design a DataStore API for those
... you can see the different methods [on the screen]
... you can add, remove, update and finally sync data
... sync allow you to sync between the DataStore and your
... local storage

genelian_ describes a figure on the screen

gmandyam: how do you handle when two apps want to own the same datastore?

genelian_: there will be only one app

<zolkis> genelian_, raise an issue about concurrent access

gmandyam: so the app would not be installed if you try to own the same store?

genelian_: yes...

mounir: we should not prevent an app to get installed for
... something in the manifest

<zolkis> I would separate whether the app is installed (which is a policy) from handling concurrency

marcos: the readonly access thing scares me

cdumez: but facebook might not want to share readwrite

marcos: but it's a user decision, not a developer decision

cdumez: no, apps might not allow other apps to write their data

<zolkis> manifest and permissions is subject to more work, see also https://github.com/airpingu/data-store-api/issues/18

genelian_ continues reading the slides

genelian_: the local app will keep its own index and have to handle the synchronization
... something else that you need to know is that the app only need
... to maintain the searches criteria
... no need to index the entire data store but only the attributes
... you care about

genelian_ goes trough an example on the screen

<zolkis> it would be nice to give examples for app makers on how to do the indexing

<zolkis> yes

<zolkis> the examples given for messaging are not the best; I have described in issue #18

genelian_ is going trough another example (slide 7)

<zolkis> I suggest we decide that we will use DataStore in Messaging, do the implementation, and modify DataStore on need

<zolkis> ok

discussion around synchronization based on the example on the screen

<zolkis> main points being? :)

marcos: we should have a way to just plug any data source to an IndexedDB

cdumez: so then it would duplicate the hole thing, right?

marcosc: indeed, it will. Maybe it could only duplicate what is needed

gmandyam: IDB has to be sandboxed, right?
... this is different because we have declared access in the manifest

marcosc: at some point it ends up in a database anyway

gmandyam: after we had our f2f, I realised that you guys are using IDB for the apps storage in FxOS
... and then we understood why access was so long

marcosc: maybe if it is readonly you could not duplicate the data?

zolkis: how do you describe what you need?

marcosc: maybe with the initial query to it?

cdumez: I don't really want to force the app to use IDB

<zolkis> the idea of binding to IndexedDB is not bad, but needs a lot of details; genelian_ please raise an issue about this and let's discuss on github

cdumez: how much data they store and how they do should be up to the implementation
... so they can do exactly what they want
... IDB is not about querying, it's a key-value database

<gmandyam> To clarify my point: I think it is a mistake to assume (or require) that a Data Store API be built upon IndexedDB - there are potential performance issues.

mounir: we should move on

<zolkis> gmandyam: I agree, the spec should not require building on IndexedDB, but binding a DataStore to an IndexedDB may be worth exploring

dsr: should we update the charter?

gmandyam: it might be in scope with contacts

<zolkis> me says too many discussions there, please one speak at the time, and use the speaker queue

wonsuk: in my opinion, it is case by case
... there is no data store api in the charter
... so in my opinion, we should make it more clearly in the charter
... we should change the charter

anssik: can the owner limit the access to other apps to readonly?

<anssik> can the owner manage the privileges the other apps have, e.g. limit others to read only

anssik: it seems that the permissions are managed in the manifest
... but that doesn't scale

<zolkis> anssik, see a proposal in https://github.com/airpingu/data-store-api/issues/18#issuecomment-39950300

genelian_: an owner can specify the whether the data store is readonly or readwrite
... but can't have a fine grained permission model
... regarding which app can access the data store

<anssik> thanks for the clarification

<anssik> that answered my question

<zolkis> I am talking

cdumez: how does that work (sync)? how do you prevent races?

genelian_: if an app call the sync function, you will get the sync changes
... <indistiguishable>

cdumez: that's why there is a close() method?

genelian_: yes

<zolkis> has to go by chat

<cdumez> g+

ack \

<zolkis> clearly there are 2 things to fix: permissions/manifest, and the sync part. I think here we should record all these questions and raise issues, and let's see if we can fix on github

<zolkis> I am not convinced that the replay mechanism is the best for sync

<zolkis> and in issue #18 I described a porposal for a coarse grain permission control through manifest, and a fine grained one via a user agent dialog

<zolkis> [end]

<genelian_> https://github.com/airpingu/data-store-api/issues/18

mounir: zolkis are there issues opens?

<zolkis> more and more :)

mounir: we can't raise official actions given that its not an official WG item

<zolkis> but we should start implementing this and see on the way

cdumez: I will just talk with genelian_ offline, those are editorial issues

mounir: we are way behind schedule, we should speed up and move to the next item
... we sholud do Contacts Manager and have a break after that

cdumez: is someone from telefonica joining?

mounir: I would have assumed so but they are not on the line
... you should start

Contacts Manager API

cdumez: there are a few changes since the last meeting
... one of the bugs was that we were not using Promises correctly
... right now, when we construct a contact, we add the contact
... to the database and create an id
... I think we should create the id after the contact is actually
... saved

mounir: do you have a list of issues to go trough?

cdumez: there is only two issues

<cdumez> https://github.com/sysapps/contacts-manager-api/pull/60

<scribe> ACTION: eduardo should review https://github.com/sysapps/contacts-manager-api/pull/60 [recorded in http://www.w3.org/2014/04/09-sysapps-minutes.html#action01]

<cdumez> Second issue: https://github.com/sysapps/contacts-manager-api/issues/62

<cdumez> http://cdumez.github.io/contacts-manager-api/index.html

cdumez: the issue here is how do we know which DataStore is the default one?
... we need a system one but which one is that going to be?
... the first one?

mounir: the owner field in DataStore should have a special value when the store is coming from the system

cdumez describes his fork of the current ED of contacts api that is using datastore

cdumez: if genelian_ can confirm if this is the idea, that would be great

wonsuk: was that been reviewed by other editors?

cdumez: not yet, it's quite new
... otherwise, I think that Eduardo made the same comment: we are both in favour of updating the api to use datastore
... so that's about it

dsr: are you going to merge this?

cdumez: once this is cleared with eduardo and genelian_ I will make a PR
... but I have trouble getting changes merged these days

<Zakim> mounir, you wanted to ask what the current involvment

<zolkis> cdumez, let's work on DataStore related issues together with the Messaging API (Eduardo also involved)

<scribe> scribe: marcosc

<mounir> scribenic: marcosc

mounir: you say you have a hard time to get changes getting merged

cdumez: yeah, it took like 5 months to get things merged

<zolkis> Intel is going to implement Contacts API on Crosswalk

<anssik> if there's a spec that is complete and good quality we'll implement in Crosswalk

<dsr> scribe: dsr

<Zakim> anssik, you wanted to note Contact, ContactField, ContactTelField etc. are exposed to the global, in total 6 interfaces

Anssi: we need a decision on exposing Contact, ContactField, ContactTelField etc. to the global

cdumez: so you're fine keeping it this way with global constructors?

Anssi: I think we can keep it as is, you have good reasons ...

<zolkis> Bluetooth PBAP support?

Zoltan: a question would be to create a bluetooth profile
... we have some use cases for this, I know bluetooth is in phase2, but ...

<zolkis> 2 ways to implement:

<zolkis> either integrated in Contacts/ Messaging

<zolkis> or we design separate API's

wonsuk: do you know what is needed for adding bluetooth support?

zoltan: it depends on the middleware, e.g.bluez

<zolkis> we are using bluez/obex for implementing PBAP

<zolkis> I will change my client :)

<zolkis> I finished commenting.

cdumez: contacts was previously limited to one data source, but with the switch to using the datastore API we can use many

<zolkis> actually there could be a separate store for each device connected via Bluetoot

<mounir> ACTION: cdumez should investigate how the Contacts API should integrate with Bluetooth [recorded in http://www.w3.org/2014/04/09-sysapps-minutes.html#action02]

cdumez: so in principle, an app could take contacts from bluetooth and put them into the shared datastore
... I was hoping that the datastore API could be published

<mounir> 10 mins break

<anssik> +1 to the proposal to investigate how we might hook Bluetooth into the existing APIs or whether a standalone lower level Bluetooth API makes more sense

Messaging

<zolkis> here, no voice

<zolkis> Messaging needs to be updated with DataStore. No other major outstanding issues

<zolkis> So, this one is quick: no major obstacles on Messaging. Questions?

Mounir: what's the implementation status?

Laszlo: we working on it ...

<zolkis> I am implementing it for Tizen and we have an Android implementation (both on Crosswalk)

Wonsuk: in respect to tizen, we're interested in the implementation, but before making the decision we're looking for a stable version of the spec with consensus at W3C

Gene: we haven't yet updated our implementation

<zolkis> looks like my phone call is hung at the bridge, and I cannot dial in!

<zolkis> trying

<zolkis> any other comments on Messaging?

<zolkis> moving to Telephony?

<zolkis> no pun intended :D

yes, that's the idea

Telephony

<anssik> zakim drop anssik

<zolkis> ok, here is my report: http://lists.w3.org/Archives/Public/public-sysapps/2014Feb/0034.html

<zolkis> short summary: added use cases, fixed CDMA issues + described design choices made in the API, made conf calls much simpler, moved telephony services into informative appendix (making its implementation optional)

<zolkis> on implementation: it has low priority right now (except Call History), but the plan is that we implement the API

Mounir: please q+ with your questions

<zolkis> I propose we do this on IRC - sorry for this

<gmandyam> (1) I appreciate all of Zoltan's efforts in revising this API - it is a difficult topic, (2) From QuIC perspective - we would like to see commitment from the companies in the room to implement AND expose this to 3rd party developers under the right permissions model, (3) If there is no commitment to do this, then the group should not continue working on this API

<zolkis> In the use cases, I made clear we have 2 separate classes: one is relevant to browsers and runtimes about "is there a phone call in the system", but that is a system info API

<zolkis> then, the original use case of supporting 3rd party dialers is being challenged now

Mounir: implementation status?

<zolkis> I have made the Telephony spec really close now to the Mozilla API, to ease adoption

Marcos: as far as I know, Mozilla has no plans to implement the telephony API

Mounir: what about Samsung?

Lazlo: no

Mounir: so no one other than Intel has any plans to implement this in the short term?

<zolkis> I think we could keep this API in the works, until it's stable, let us try it in an implementation, and then we can retire it at least knowing we have done a good job :)

<zolkis> Personally I would be fine with 3 use cases concerning telephony:

Mounir: Zoltan, is Intel interested in exposing the telephony API to 3rd parties?

<zolkis> 1. start the native dialer with a number + dtmf

<zolkis> 2. is there a call in the system and what resources is it using

<zolkis> 3. call history as DataStore source

Mounir: for FirefoxOS telephony is for internal apps only, not 3rd parties

<zolkis> mounir: I need to check with Wayne, but when we started this work, the idea was to expose this to 3rd party developers

<zolkis> yes, use case 1 does not require a telephony API

<zolkis> and use case 2 can be done in a system info type of API

Some discussion about which organizations support the tel: URL scheme

<zolkis> use case 3 is a must, and it would be good to standardize

<zolkis> OK. But this API is about a different thing.

<gmandyam> All implementations seem to support tel:URL the way it was intended.

Mounir: how can you access call history from Tizen?

Chris: There is an API for this in Tizen

<zolkis> so, the question is, could we keep the Telephony API in the works?

<zolkis> We are interested in it, and nowadays I am the only one who is doing some work on it

Mounir: anyone have any questions specific to the telephony API, please ask now, or otherwise we can move to the charter and future work topic

<Zakim> wonsuk, you wanted to in the aspect implementation, dose Mozilla has a plan for that?

<zolkis> ok

<zolkis> thanks

<zolkis> please reset the phone... :) it is having ghost calls

<zolkis> what seems to happen is that Asterisk (behind Zakim) has one side of the bridge up

<zolkis> someone needs to restart the daemon

<zolkis> or allocate a different conference

<zolkis> yes, the service times out

<zolkis> so, let's go on and we rely on the scribes

<zolkis> or everybody types :)

<mounir> Zakim drops [Paypal]

<opoto> new dial in: +12153674444 (US) +358981710447 (Finland) conference ID: 84905672

<opoto> (can provide other countries on demand)

<zolkis> Thanks a lot opoto! I dialed in, waiting for the leader :)

<zolkis> I hear your conversations :)

Discussing the charter and current work items

<zolkis> link to charter?

<mounir> http://www.w3.org/2012/09/sysapps-wg-charter.html

Mounir: let's start with telelphony, but before that ...

<mounir> http://www.w3.org/2012/sysapps/

<anssik> http://www.w3.org/2012/09/sysapps-wg-charter.html

<anssik> s/http://www.w3.org/2012/09/sysapps-wg-charter.html//

Mounir summarises the current situation

scribe: we would like to add DataStore, but in general we need implementation support for the specs
... if telephony is only used by internal apps, then interoperability is not an issue

Mounir: I would prefer to drop the specs where we aren't seeing broad implementation interest
... We all have different silos, and what we're trying to do is to define APIs for use by all the different silos, but we are very far away from succeeding with that
... Moving such APIs to W3C standards has low benefit, so maybe we should focus on APIs that have broader interest

Anssi: Mounir that was a good summary. Specs designed around the web security model have been shown to move faster (in DAP WG)
... the App LifeCycle spec is currently dormant waiting for progress on ServiceWorker

<anssik> https://www.w3.org/wiki/Headlights2014/W3C_Workshop_on_Web_Apps_and_Marketplaces

Anssik: Dave a couple on months ago asked about interest in a workshop on permissions and marketplaces and that could be a valuable activity
... For SysApps, we should focus on a very small number of specs that could be moved forward efficiently
... with interest from the implementers

<anssik> +1

<anssik> I'm very interested in trying to address the permission model problem in the browser context

Mounir: we might want to tackle permissions on web APIs. Moving to a standard is a huge benefit in terms of developer confidence, but this doesn't apply to APIs used by internal apps

Zoltan: I definitely see value in messaging and telephony APIs, and making sure that this work is usable
... Since I am the only one working on telephony, we could shut it down, but it is a usable API and now that we have done the bulk of the work, it would be a shame to drop it

Mounir: usually when W3C WG's drop work items these are turned into WG Notes which means that the work is not being worked on anymore but is available as a reference

Anssi: these can be restored to a Working Draft if the WG deems it appropriate

Zoltan: I think we could gracefully retire the telephony spec, it is now ready for implementation feedback, there were a lot of companies interested.

Anssi: we should give a clear reason when we republished APIs as WG Notes

Olivier: we should clarify 3rd party use cases, without these it is not worth standardizing

Mounir: raw socket is an interesting API, but no one is implementing the spec, so this isn't promising for a standard

<zolkis> well, Intel has implemented the Raw Socket API, so "no one" is not accurate :)

<zolkis> I agree: we are too early with this work. Is there any way to freeze the work without dropping them?

Marcos: I think we are 5 years ahead of the curve, and that gives us the time to explore this space in proprietary ways, and to understand what works and what would really be worth standardizing

Dave: what are developers saying?

<anssik> zolkis, W3C Note is technically freezing, you can resume

Mounir: when developers write apps for each packaged platform that don't care so much about standards, but they do care when they start developing for the web platform

lgombos: the concerns raised are quite generic, there is a concern about implementations, my comment on that is that we have all these proprietary APIs, developers would like open standards and these could be layered on top of the proprietary platforms

Marcos: what is the benefit?

lgombos: some benefits are for developers and some for the platform vendors
... over time there will come other benefits

<zolkis> lgombos: that is a very good point: platforms do benefit from this work

Mounir: that's the wrong reason, ...

lgombos: we can't expect the same volume of comments as for HTML5, as a lot of the system apps will be niche

Wonsuk: it is important to create a better ecosystem for industry, we should look at which APIs will have a higher priority for the Web

Marcos: we know that offline apps are very important

Wonsuk: that's clear

Marcos: the installability of web apps, we've worked on manifest for that
... we need support for large web apps, and are getting there
... we need better performance e.g. for games

lgobos: it is really hard to progress individual APIs unless we progress work on security and permissions

Mounir: indeed

<zolkis> but these can be done in parallel... it is possible to detach a lot of things from security and permission model

Mounir: I think it will be really hard to reach agreement on the model for packaged apps
... unless people around the table are willing to change their platforms
... everyone around the table have native Apps and want to make APIs like those for their native apps, but it would be better to focus on extending the web security model

Anssi: I have a bunch of statements for the group to consider.

1. do we agree that apps must run on origins, and be part of the Web

2. I think we all believe that web apps need access to more advanced capabilities and features than they currently have

3. do we agree the users of these apps must have control over the capabilities these apps have, and that users can revoke these rights

4. this is about how we integrate with the host OS, manifest is part of the solution, home screen, etc.

5. offline is crucial for web apps to compete with native apps, service workers is the solution, sysapps wg may not need to do much here. Users must be able to trust web apps

6. the current permissions models are broken and we need to fix that, one promising approach is to ask users in context of use

what do you guys think?

Mounir: I generally agree

Marcos: re (1) origins/part of the web, I am not clear what the scope that leaves for things running under AppURI
... everything else I agree with

Dave: do we want to fomalize the agreement on those points?

Mounir: we need to change course, and to drop some work items. We could recharter to make this clear, and a 3rd way would be to completely change the way work is done, e.g. closing the WG in favor or a Community Group

<wonsuk> +1 for Anssi's opinion especially for #1 about origin!

Mounir: making the web more appy not the apps more webby

Zoltan: we don't really have a scoping problem, more an implementation problem
... I don't understand why we can't use the manifest as part of the permission solution

<anssik> zolkis, see my point 6.

<zolkis> yes, I agree with anssik point 6

Mounir: we don't currently really know how to address the permissioning problem, so progress could take many years

<zolkis> and the other points, too

Mounir: I don't think it is just a matter of dropping work items and continuing with the rest

Zoltan: we should return to ? when we have working implementations

<zolkis> yes, coming...

<gmandyam> If we don't focus on trusted apps alone, we should ensure that there is delineation between what is done in this group and what is done in DAP

Giri: I think the example of DAP WG is good, if we want to support web apps, we are likely to overlap with the DAP WG,so we need to be careful about that.

<zolkis> So do we want to deal with solving the permissions problem? Every platform will need to do that, we do it one way in Crosswalk, may be good or bad, time will tell. I think we could get relatively easily to the point of a good enough mechanism, and leave the rest to the user agents.

Giri: We should be addressing APIs with a different security context than DAP is addressing today

Mounir: your concern is mostly about what if we (SysApps) decide to completely change everything

Dave: rechartering would provide an opportunity to clarify the group's vision and roadmap

Mounir: is there general support for discuss that further (on email)?

cdumez: if we we go to the web, then we may only need read access for contacts, and could go back to the DAP contacts API

Dave: surely we want to enable much richer kinds of trusted web apps

Mounir: if web intents come back, they could be a good solution for contacts
... if we think we can find ways to give web apps richer capabilities that would be good

Marcos: DAP tried a number of different ways and failed in a good way
... If we show solutions that work well on proprietary platforms, we will then be ready to standardize based on what works

Dave: it sounds like we are risk of fragmenting the web with proprietary silos

Mounir: what is more dangerous is standardizing APIs that aren't widely adopted

APIs for packaged apps fits the proprietary model well

<mounir> mounir: it's more dangerous to add APIs with the idea that they will b implemented

<mounir> ... than adding proprietary APIs to proprietary platforms

<mounir> ... which are not the web

<mounir> ... for example, push API in firefox OS is accessible from hosted apps

<mounir> ... which are in the Web

<mounir> ... but it's hurting the web

<mounir> ... if push was only for packaged apps, Mozilla could experiment without hurting the web

Marcos: we should first sort out core issues before working on device aps

<gmandyam> Any recharter discussion should engage the framework providers (jQuery, Cordova/PG) - they are familiar with what developers need in a trusted framework

cdumez: how about phonegap, this is really popular, so clearly there is a need for APIs that work across OSes

Mounir: SysApps has been going for 2 years, but we aren't seeing people changing their implementations each time the spec changes

Marcos: things are too experimental right now

cdumez: phonegap is a minimal API that covers the intersection of all platforms

Giri: my concern with phonegap is that it is too bottom up
... it would have been nice if the phonegap guys had stayed involved and provided us with their developer feedback

<Zakim> anssik, you wanted to note the group is currently chartered with an end date of 1 October 2014 -- I assume we'd like to recharted mid-term rather than wait 6 months?

<anssik> current status re https://www.w3.org/wiki/Headlights2014/W3C_Workshop_on_Web_Apps_and_Marketplaces

<anssik> do we think this workshop would provide valuable input to the rechartering of this group?

Anssi: I wanted to note the group is currently chartered with an end date of 1 October 2014 -- I assume we'd like to recharted mid-term rather than wait 6 months?

<anssik> if so, could we run this workshop in a more unconference-style (e.g. no formal position papers, expression of interest statements)

Anssi: do you think a workshop would be a good way to set our new course, and to run in an unconference style?

Marcos: we could do a meet up

Anssi: yes that would be fine

Mounir asks Dave if W3C workshops could run unconference style

Anssi: we should name the workshop differently

Mounir: how about web apps and permissions

Giri: or even "trusted web app"

Anssi: SysApps only has 6 months to run, so is it better to recharter now that wait

Dave: better to change course earlier than later

Anssi asks about plans for a whitepaper, this should allow for joint contributions

Dave: yes, this is intended to be a data gathering exercise

Zoltan: starting completely from scratch seems a bit harsh

<zolkis> but sometimes needed

<mounir> RESOLUTION: the group agreed that we should reconsider the future of the group

<mounir> ACTION: mounir will start a thread about the future of the group on the mailing list [recorded in http://www.w3.org/2014/04/09-sysapps-minutes.html#action03]

Zoltan: break for lunch, we will restart at 2pm PST

<anssik> thanks everyone, this was a great brainstorming session

<marcos> Can someone let me in from the side door? :)

<mounir> scribe: mounir

<scribe> scribenick: mounir

Secure Element API

opoto: Garner Lee and Siddartha Pothapragoda are here from DT
... they are implementing something close to Secure Element on Firefox OS
... following the presentation we made during TPAC, we had
... some feedback like security of the API
... for example, how to control access?
... there were other technical points
... that I will cover quickly because they might be too deep
... for the interest of most people here
... when you open a channel, you can specify an AID (application ID)
... we have added methods to transfer an arraybuffer
... there are different usage
... like a JS API building things and sending them to the application
... there may be more important usage like the service side
... commands created in the server and transferred to the client
... via the web app
... we have those two methods now to support those usages

(the Secure Element draft is being shown and read at the same time: http://opoto.github.io/secure-element/)

opoto: the errors have also been changed to exceptions
... the main evolutions come from the access controls
... the good thing with secure elements is that there are
... different security mechanisms to access them
... like pin code
... (etc.)
... there are an additional way issues by GlobalPlatform (showing thing on screen)
... they provide a Secure Element Access Contol
... that filters out requests from client application
... if they are not allowed by an access rule in the secure element
... the implementation of this access control requires that the runtime cooperates

marcosc: what's the license of that specification? because I it is asking me creepy things
... is there royalties? is it free to re-use?

(sparse discussion about whether or not it's free of use...)

opoto is describing how the previous feature works using a schema

opoto: it also means that it is only useful if the runtime is not compromised

gmandyam: for the purpose of this API, the access control
... implementation in the secure element isn't important to the
... developers

opoto: for these access controls to work, there need to be a
... trusted identifier for the application
... this is where we need to define something specific for this
... specification
... How do we get the trusted identifier for the application?
... the proposal here is based on the signature
... it distinguishes applications based on there protocal
... https vs app, hosted vs packaged
... it is using the signature application based on the
... Widget specification
... in the manifest
... I was told that we could use the distributor signature
... instead of the application signature instead

marcosc: you don't need to have the signature in the manifest

opoto: where would we get the signature from then?

gmandyam: the distributors could inject that in the manifest

opoto: altough we define something in the manifest, or we use
... a well-known location
... I have added this option to have an entry in the manifest
... to have an author-signature file
... for HTTPS applications, I propose to only use the URI
... as the identifier

brad: what about I have a script sourcing evil.com?

opoto: in this case, we are not signing the files themselves

brad: but even a packaged apps could do that?

mounir: the default CSP policy of packaged apps prevent that

siddartha: what about web applications that get updated
... over the air after installation?
... for example, I have a wallet application using secure element
... but at some point I update the application
... with a new manifest
... what would the repercusion be on the signature?

opoto: actually, I did not give a detailed enough explanation
... the se_author_signature is not the signature, it's the

<dsr> In principle, the subresourceitegrity spec could be used for hosted apps for scripts. See http://w3c.github.io/webappsec/specs/subresourceintegrity/

opoto: hash of the certificate that was used to compute the
... signature

<Github> [13tcp-udp-sockets] 15ClaesNilsson opened pull request #67: Updated README.md with correct API name and correct link to rendered spe... (06gh-pages...06gh-pages) 02http://git.io/Agh9Uw

<Github> [13tcp-udp-sockets] 15ClaesNilsson closed pull request #67: Updated README.md with correct API name and correct link to rendered spe... (06gh-pages...06gh-pages) 02http://git.io/Agh9Uw

<Github> [13tcp-udp-sockets] 15ClaesNilsson pushed 2 new commits to 06gh-pages: 02http://git.io/sY0u0w

<Github> 13tcp-udp-sockets/06gh-pages 14b64b3ea 15Claes Nilsson: Updated README.md with correct API name and correct link to rendered specification.

<Github> 13tcp-udp-sockets/06gh-pages 14d17dc8a 15Claes Nilsson: Merge pull request #67 from ClaesNilsson/gh-pages...

brad: what's under that signature?

opoto: the same origin and same path prefix

brad: if you say that only application in a scope can access to some things
... you can't make that scope more granular than origin
... basically, https://foo.com/safe/index.html and
... htts://foo.com/~foo/evil.html can access each other
... so if the former has access to the secure element, the
... former could have acess too

<dsr> (Same origin policy as per RFC6454)

brad: I would drop this entire hierarchy thing and say that
... the hierachy is only scheme + host + port (origin)

<bhill2_> http://seclab.stanford.edu/websec/origins/fgo.pdf

(mounir and brad rephrases what was said)

opoto: one thing to note here is that we used the signature of the application
... there could be another option
... which wolud be to use the URI of the application
... as the identifier of the application
... the SHA1 of this URI as the access identifier
... it might not give much security in some cases
... like packaged applications

(discussions about how the Firefox OS origin field in manifest can make that possible)

opoto: for https apps, there are options to sign the entire
... content of the application
... for example, using the latest packaging format (in www-tag)
... the runtime could download all the content and
... sign it

<bhill2_> ISSUE for Secure Element unofficial draft "Resources which URL is not hierarchically below this URI MUST NOT be granted the application's access" implies a finer-grained access control structure than the web grants. No more than RFC6454 Origin isolation can be achieved in general.

<bhill2_> does this group not use trackbot?

bhill2_: we do not

<bhill2_> how can I assure my issue is formally recorded?

<bhill2_> github issue?

bhill2_: yes

brad: what if I am in a corporate system where I have injected
... CA by my employer?

opoto: the idea is just to put the barier a bit higher compared to what is accepted with https, here we enforce that the certificate is valid and issued by a trusted CA
... we do not enforce how the trusted store is managed here

siddartha: is there a test suite that you can run against to
... comply against GlobalPlatform?

opoto: I think there is a test suite but not specific to SE API

siddartha: so the intent of this specification with respect
... to GlobalPlatform is that compliance is required or preferred
... ?

opoto: it is mandated (reading that it is a MUST)

Jinsong: what the relation between this API and the SIM Alliance API?

opoto: this is very close, also the SIM Alliance API is also based on this notion of reader, sessions and channels
... you can implement this API on top of the SIM Alliance API

siddartha: I have a question but we could take that offline too

mounir: lets get technical details discussed offline

brad: I'm not sure that GlobalPlatform solves the privacy issues
... what's the story here?

mounir: as you mentioned Olivier, given the discussion we had
... earlier today, we might want to delay the decision wrt
... whether we work on this until the general discussion happens

dsr: shouldn't we move this to the sysapps github area?

mounir: I think we should keep specs we work on there
... and we do not officialy work on that

<scribe> ACTION: update the sysapps homepage to make it clear to the world what the group is up to [recorded in http://www.w3.org/2014/04/09-sysapps-minutes.html#action04]

Next F2F

dsr: W3C is ogranizing TPAC in October, we need to give some estimate

mounir: I think one day would be the most we should do, if we do something, so lets say a day that we might cancel

dsr: sounds good
... also, what about this unconference
... we might want to set a timeline and define who should be invited

mounir: what about June?

dsr: early July would be a problem?

mounir: not for me

dsr: location?

mounir: Europe maybe?

dsr: who should be invited?

mounir: browsers. We should see if Apple, Microsoft and more Googlers could go

<zolkis> to Europe? you'd rather see them at tpac

genelian: what about the current items? should we continue implementing them?

mounir: yes, it's fine to do that
... the problem is that it seems that there is no interest to implement
... so feel free to implement and solve our concerns ;)

<zolkis> why are you saying that? well, maybe Intel doesn't count since not browser-maker, just runtime?

<dsr> mounir closes the meeting after thanking Brad for hosting.

- DRAFT -

Systeam Applications WG face to face 9 April

09 Apr 2014

Attendees

Contents