See also: IRC log
<trackbot> Date: 10 February 2010
<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
<fjh> proposed RESOLUTION: minutes from 3 Feb approved
RESOLUTION: minutes from 3rd Feb approved
<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
+1
<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) ?
<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
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
robin: Eric from google will be joining the group and will contribute to the work
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