Device APIs and Policy Working Group Teleconference -- 10 Feb 2010

<trackbot> Date: 10 February 2010

Administrative, Agenda Review, Scribe selection

<fjh> http://www.w3.org/2009/dap/victims-list.html

<fjh> Aurelien, you are not listed on the scribe list. Would you pls be able to scribe today?

<aguillou> 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

<darobin> blassey?

<darobin> ScribeNick: Suresh

Minutes approval

<fjh> proposed RESOLUTION: minutes from 3 Feb approved

Resolution: minutes from 3rd Feb approved

Policy

<fjh> action-16?

<trackbot> ACTION-16 -- Bryan Sullivan to help review/compare device capabilities and features -- due 2009-11-02 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/16

Bryan: leave it open

<darobin> action-16 due 2010-02-24

<trackbot> ACTION-16 Help review/compare device capabilities and features due date now 2010-02-24

Due date: Feb 24

<fjh> action-45?

<trackbot> ACTION-45 -- David Rogers to provide use case with threat model scenarios -- due 2009-11-10 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/45

<fjh> action-48?

<trackbot> ACTION-48 -- Suresh Chitturi to propose a definition for API access control, and a possible model for policy enforcement -- due 2010-02-10 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/48

<fjh> suresh notes access control from requirements, policy enforcement for design

<fjh> note suresh action for 2 wks

<fjh> action-77?

<trackbot> ACTION-77 -- John Morris to provide a discussion of requirements for privacy -- due 2010-01-19 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/77

Due date for Action-48: Feb 24

<darobin> action-48 due 2010-02-24

<trackbot> ACTION-48 Propose a definition for API access control, and a possible model for policy enforcement due date now 2010-02-24

<fjh> action-79?

<trackbot> ACTION-79 -- Paddy Byers to integrate his use cases in policy requirements -- due 2010-01-13 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/79

action-48 due 2010-02-24

<trackbot> ACTION-48 Propose a definition for API access control, and a possible model for policy enforcement due date now 2010-02-24

<fjh> available for call in 2 wks

action-79 due 2010-02-24

<trackbot> ACTION-79 Integrate his use cases in policy requirements due date now 2010-02-24

<fjh> Dan Applequist's TAG message about privacy per api or grouping

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0032.html

<fjh> 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

<fjh> Do we want to indicate use cases/requirements related to the REST

<fjh> Incorporate material from currently open actions

we need to incorporate open action results

<fjh> 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..

<fjh> need concrete proposal for REST approach, also address concerns raised by Paddy

<AnssiK> 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

<AnssiK> 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

<fjh> note that REST approach could be limited to contacts/PIM, could be implemented without web server or actual protocol exchangs

<fjh> on device

<fjh> benefit to allowing local and or network access

<fjh> I suggest that even with OAuth, device will still require access control policy regardless

thomas: The abstraction here is about javascript objects.....

<fjh> tlr notes that we cannot wait very long for REST proposal

<fjh> tlr notes we need to decide on network based abstraction versus local

<fjh> tlr allows OAuth authorization delegation

<fjh> question - how would OAuth address local non-delegated case?

<fjh> tlr agrees with fjh that Oauth does not eliminate need for policy file

tlr: OAuth would be useful indegredient for REST approach

<Zakim> 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?

<fjh> 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?

<fjh> bsullivan notes that we need detail on how OAuth would work for device context from REST proponents

<fjh> paddy +1 this

<fjh> do not want to see backtracking

<fjh> 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

<fjh> 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

<fjh> 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

<fjh> 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

<Claes> Sorry, need to drop off

<fjh> 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

<darobin> s/???/Niklas

<bsulliva> I agree - that was my point re the charter, this changes the nature of what DAP was envisioned to do.

good point

<richt> I didn't know W3C was in the business of defining web services...but it is an interesting solution to the problem

<fjh> niklas notes concern that REST would expand the scope, bring in additional stakeholders, and increase risks for project

<richt> ..except for SOAP but that was the defintion rather than specific SOAP services

<fjh> It would be good to keep usability for Javascript programmers

<fjh> 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

<fjh> 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

<fjh> 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

<tlr> Agree with Paddy that this is a design choice.

<fjh> paddy notes that REST API has design choices regarding abstraction for local resources and/or remote

<Zakim> fjh, you wanted to note that REST proponents are arguing that OAuth is only one

<richt> +1 agree with paddy. Currently DAP is abstracted from whether it is a web service or not. It is a lower level design choice.

<fjh> ACTION: fjh to update title of Policy requirements document [recorded in http://www.w3.org/2010/02/10-dap-minutes.html#action01]

<trackbot> 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...

<fjh> have deadline for concrete proposal so we will await that

if REST is viable, then we can look at it

<ag> what's the value added of using REST style APIs in a developer point of view (from JS) ?

APIs

<maxf> 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

<nwidell> 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

<paddy> apologies but I have to drop off

bryan: also recommends to follow the discussion on re-chartering

<darobin> APIs with no taker: Gallery, Tasks, Application Launcher, User Interaction, and Communication Log

bandwidth problem i think:-)

<Dzung_Tran> I thought the Gallery was put to rest due the the proposal of Media metadata Annotation

<bsulliva> bandwidth

robin; perhaps we can revisit this issue at the F2F

<wonsuk> 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

<Dzung_Tran> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0002.html

robin: any other topics?

<fjh> in 2 weeks should start planning for f2f

<fjh> as part of decisions

<fjh> any other business?

<scribe> dropped out...

meeting adjourned

- DRAFT -

Device APIs and Policy Working Group Teleconference

10 Feb 2010

Attendees

Contents