[1]W3C [1] http://www.w3.org/ Device APIs and Policy Working Group Teleconference 10 Feb 2010 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0050.html See also: [3]IRC log [3] http://www.w3.org/2010/02/10-dap-irc Attendees Present Robin_Berjon, Frederick_Hirsch, Dzung_Tran, Aurelien_Guillou, Thomas_Roessler, Suresh_Chitturi, Paddy_Byers, Ilkka_Oksanen, Anssi_Kostiainen, Niklas_Widell, Marcin_Hanclik, Richard_Tibbett, Wonsuk_Lee, bryan_sullivan, Claes_Nilsson Regrets David_Rogers, John_Morris, Daniel_Jesus_Coloma_Baiges Chair Robin_Berjon, Frederick_Hirsch Scribe Suresh Contents * [4]Topics 1. [5]Administrative, Agenda Review, Scribe selection 2. [6]Minutes approval 3. [7]Policy 4. [8]APIs 5. [9]Messaging APIs 6. [10]File API 7. [11]heads-up on WebApps Rechartering * [12]Summary of Action Items _________________________________________________________ Date: 10 February 2010 Administrative, Agenda Review, Scribe selection [13]http://www.w3.org/2009/dap/victims-list.html [13] http://www.w3.org/2009/dap/victims-list.html Aurelien, you are not listed on the scribe list. Would you pls be able to scribe today? aguillou: i'm not sure to be able to scribe today, as my english level is not very good. aabb is me +1.408.216.aabb is Suresh blassey? ScribeNick: Suresh Minutes approval proposed RESOLUTION: minutes from 3 Feb approved Resolution: minutes from 3rd Feb approved Policy action-16? ACTION-16 -- Bryan Sullivan to help review/compare device capabilities and features -- due 2009-11-02 -- OPEN [14]http://www.w3.org/2009/dap/track/actions/16 [14] http://www.w3.org/2009/dap/track/actions/16 Bryan: leave it open action-16 due 2010-02-24 ACTION-16 Help review/compare device capabilities and features due date now 2010-02-24 Due date: Feb 24 action-45? ACTION-45 -- David Rogers to provide use case with threat model scenarios -- due 2009-11-10 -- OPEN [15]http://www.w3.org/2009/dap/track/actions/45 [15] http://www.w3.org/2009/dap/track/actions/45 action-48? ACTION-48 -- Suresh Chitturi to propose a definition for API access control, and a possible model for policy enforcement -- due 2010-02-10 -- OPEN [16]http://www.w3.org/2009/dap/track/actions/48 [16] http://www.w3.org/2009/dap/track/actions/48 suresh notes access control from requirements, policy enforcement for design note suresh action for 2 wks action-77? ACTION-77 -- John Morris to provide a discussion of requirements for privacy -- due 2010-01-19 -- OPEN [17]http://www.w3.org/2009/dap/track/actions/77 [17] http://www.w3.org/2009/dap/track/actions/77 Due date for Action-48: Feb 24 action-48 due 2010-02-24 ACTION-48 Propose a definition for API access control, and a possible model for policy enforcement due date now 2010-02-24 action-79? ACTION-79 -- Paddy Byers to integrate his use cases in policy requirements -- due 2010-01-13 -- OPEN [18]http://www.w3.org/2009/dap/track/actions/79 [18] http://www.w3.org/2009/dap/track/actions/79 action-48 due 2010-02-24 ACTION-48 Propose a definition for API access control, and a possible model for policy enforcement due date now 2010-02-24 available for call in 2 wks action-79 due 2010-02-24 ACTION-79 Integrate his use cases in policy requirements due date now 2010-02-24 Dan Applequist's TAG message about privacy per api or grouping [19]http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0 032.html [19] http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0032.html [20]http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0 067.html [20] http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0067.html fjh: Essentially TAG recommends the privacy to be dealt on per-API basis Do we want to indicate use cases/requirements related to the REST Incorporate material from currently open actions we need to incorporate open action results Issues noted in document, next steps? fjh: trust, granularity, access control need to be adddressed ... rename to "common security" or similar from "policy"? ... trying to understand how to go forward? move to FPWD? doesn't seem like we are there yet, and what to do with REST issue? paddy: we need to see a concrete proposal realy.. need concrete proposal for REST approach, also address concerns raised by Paddy re RESTful APIs and OAuth darobin said on the ML: "Our friends from Google have been working on something here " fjh: the email discussions are vague and unless we get a concrete proposal we cannot move forward robin: there some offline documents from Google, that can be useful related to OAuth, etc. fjh: if we are taking REST approach, i would like to see it mentioned in requirements document bryan: trying to understand the shift in the direction here ... charter explicitly talks about device fjh: the REST approach is to let access based on rest apis but the functionality could be on the device this is what the charter says: "Devices in this context include desktop computers, laptop computers, mobile internet devices (MIDs), cellular phones, etc. " bryan: Are we going to rework everything based on REST approach, e.g. dom objects, session storage, etc note that REST approach could be limited to contacts/PIM, could be implemented without web server or actual protocol exchangs on device benefit to allowing local and or network access I suggest that even with OAuth, device will still require access control policy regardless thomas: The abstraction here is about javascript objects..... tlr notes that we cannot wait very long for REST proposal tlr notes we need to decide on network based abstraction versus local tlr allows OAuth authorization delegation question - how would OAuth address local non-delegated case? tlr agrees with fjh that Oauth does not eliminate need for policy file tlr: OAuth would be useful indegredient for REST approach fjh, you wanted to ask about criteria tlr: The REST approach makes sense in some cases and in some cases not fjh: having a criteria is helpful ... local device access is core to our work policy work is still required regardless of the approach, do you agree? focus on policy exchange versus defining policy itself tlr: some mechanism needs to be there, but can't tell to what extent we need to specify fjh: from proposals like BONDI, we have concrete cases for policy based on trust... ... but how long can we wait? tlr: if we do not have a champion, we cannot progress fjh: Robin has worked on it, but how much longer should we wait? robin: we do not have all the API drafts, e.g. gallery that could help us make the decision fjh: would two more weeks be sufficient? bsullivan notes that we need detail on how OAuth would work for device context from REST proponents paddy +1 this do not want to see backtracking paddy notes we do not want to be stuck, need to move forward, need concrete proposal paddy: all the policy has been paralyzed due to the diversion with REST proposed resolution: if the wg does not have a concrete REST/OAuth proposal in 2 weeks we will move forward with existing policy and API plans +1 not sure we want to require HTTP within device for local access, sounds not so good tlr: critical decision is whether we take the RESTful approach ... OAuth is a follw-up proposed resolution: if the wg does not have a concrete REST proposal including policy concerns, in 2 weeks, we will move forward with existing policy and API plans tlr: i do not want to link the two together i.e. REST and OAuth waiting for robin proposed resolution: if the wg does not have a concrete REST proposal including policy concerns, in 2 weeks, we will move forward with existing policy and API plans robin: two weeks is realistic, i believe ... perhaps, sending an email to the list making the resolution visible fjh: can we make the resolution here then? proposed resolution: if the wg does not have a concrete REST proposal including policy concerns, in 2 weeks, we will move forward with existing policy and API plans if the wg does not have a concrete REST proposal including policy concerns, in 2 weeks, we will move forward with existing policy and API plans RESOLUTION: if the WG does not have a concrete REST proposal including policy concerns, in 2 weeks, we will move forward with existing policy and API plans Sorry, need to drop off proposed resolution: Change title of policy requirements to "Device API Security, privacy and policy requirements" RESOLUTION: Change title of policy requirements to "Device API Security, privacy and policy requirements" Niklas: if we take the REST approach wouldn't that change the landscape e.g. more interested participants s/???/Niklas I agree - that was my point re the charter, this changes the nature of what DAP was envisioned to do. good point I didn't know W3C was in the business of defining web services...but it is an interesting solution to the problem niklas notes concern that REST would expand the scope, bring in additional stakeholders, and increase risks for project ..except for SOAP but that was the defintion rather than specific SOAP services It would be good to keep usability for Javascript programmers note that REST would expand the work even if in scope of charter Claes: just trying to understand the group's understanding, from practical viewpoint it opens the scope up brian notes that OAuth will not solve problems, usability issues, allows repeated authorization but not initial authorization bryan: from my reading, there is no support in Oauth for automatic authorization tlr notes consent step could be be policy enforcement step tlr: there is no reason why the user needs to be in the path, but let's discuss the Oauth after we decide on the approach Agree with Paddy that this is a design choice. paddy notes that REST API has design choices regarding abstraction for local resources and/or remote fjh, you wanted to note that REST proponents are arguing that OAuth is only one +1 agree with paddy. Currently DAP is abstracted from whether it is a web service or not. It is a lower level design choice. ACTION: fjh to update title of Policy requirements document [recorded in [21]http://www.w3.org/2010/02/10-dap-minutes.html#action01] [21] http://www.w3.org/2010/02/10-dap-minutes.html#action01 Created ACTION-94 - Update title of Policy requirements document [on Frederick Hirsch - due 2010-02-17]. Suresh: i am little confused here, we seem to be going in circles, shouldn't we just stick to the charter and the current approach rather than waiting... have deadline for concrete proposal so we will await that if REST is viable, then we can look at it what's the value added of using REST style APIs in a developer point of view (from JS) ? APIs OAuth sounds like a concrete proposal to me (maybe a bad one, but concrete nevertheless) robin: any idea when we can publish something? joined back Messaging APIs will have a more complete draft to the list by next week sorry random call drop nwidell: will have a more complete draft on messaging APIs to the list by next week File API robin: Eric from google will be joining the group and will contribute to the work heads-up on WebApps Rechartering robin: recommend the group to pay attention to these discussions apologies but I have to drop off bryan: also recommends to follow the discussion on re-chartering APIs with no taker: Gallery, Tasks, Application Launcher, User Interaction, and Communication Log bandwidth problem i think:-) I thought the Gallery was put to rest due the the proposal of Media metadata Annotation bandwidth robin; perhaps we can revisit this issue at the F2F I am sorry for late about Gallery API, but i think i can prepare the initial draft until the end of this month. there is an echo [22]http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0 002.html [22] http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0002.html robin: any other topics? in 2 weeks should start planning for f2f as part of decisions any other business? dropped out... meeting adjourned Summary of Action Items [NEW] ACTION: fjh to update title of Policy requirements document [recorded in [23]http://www.w3.org/2010/02/10-dap-minutes.html#action01] [23] http://www.w3.org/2010/02/10-dap-minutes.html#action01 [End of minutes] _________________________________________________________ Minutes formatted by David Booth's [24]scribe.perl version 1.135 ([25]CVS log) $Date: 2009-03-02 03:52:20 $ [24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [25] http://dev.w3.org/cvsweb/2002/scribe/