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

<trackbot> Date: 10 March 2010

<dom> Presen Dominique_Hazael-Massieux

<darobin> I'm having trouble with the local phone system — if I can't get it to work I'll fall back in a minute or two

<dom> ScribeNick: alissa

Administrative

<fjh> F2F 16-18 March

<fjh> logistics, http://www.w3.org/2009/dap/wiki/PragueF2F

<fjh> attending: http://www.w3.org/2002/09/wbs/43696/prague-2010/

<fjh> * Note on Daylight savings time difference between US and EU,

<fjh> see http://lists.w3.org/Archives/Member/member-device-apis/2010Mar/0000.html

<fjh> proposed RESOLUTION: Cancel teleconference 24 March

<darobin> [note that some calendar programs (such as iCal) allow you to anchor meetings in a TZ, in this case use US Eastern]

<maxf> as mentioned in the above email, http://www.timeanddate.com/time/dst2010a.html is a good resource

RESOLUTION: Cancel teleconference 24 March

<fjh> 2c) possible F2F at TPAC, Thur/Fri 4-5 November, http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0070.html

dom: not sure if thurs-fri is best for TPAC meeting
... depends on joint meetings with other groups

fjh: works better for me thurs-fri
... can we indicate tentative preference for thurs-fri?

dom: can we say we're flexible but have a conflict with XML Security?
... and that we want to meet with Geoloc and Web Apps?

darobin: will indicate thurs-fri preference

Minutes approval

<fjh> 3 March 2010

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0059/minutes-2010-03-03.html

<fjh> proposed RESOLUTION: Minutes from 3 March approved.

RESOLUTION: Cancel teleconference 24 March

F2F Agenda

fjh: moved some privacy stuff to the first day to accommodate alissa

<fjh> see http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0079.html

fjh: nobody from Google will be attending

<fjh> Day 1, Tuesday, 16 March (10:00 - 17:00)

<fjh> Day 2, Wednesday 17 March (9:00 - 17:30)

<fjh> Day 3, Thursday 18 March (9-15:30)

no concerns raised about times

fjh: concerned that we're sitting on submissions, try to use F2F to get something going with policy
... more time for contacts as it's an important API

<richt> Though nothing has been proposed (yet) on the mailing list I have an action to write up the OpenProvider proposal before the F2F. It would be nice if we have time to discuss this.

<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-24 -- CLOSED

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

Suresh: ACTION-48 has not been incorporated
... access control definition has not been discussed
... could be done at F2F

<fjh> ACTION: add definition from ACTION-48 to policy requirements [recorded in http://www.w3.org/2010/03/10-dap-minutes.html#action01]

<trackbot> Sorry, couldn't find user - add

<fjh> ACTION: fjh to add definition from ACTION-48 to policy requirements [recorded in http://www.w3.org/2010/03/10-dap-minutes.html#action02]

<trackbot> Created ACTION-102 - Add definition from ACTION-48 to policy requirements [on Frederick Hirsch - due 2010-03-17].

<fjh> s/ACTION: add.*//

<Zakim> richt, you wanted to ask if we could allocate some time for OpenProvider in the F2F agenda

richt: can we get some time to discuss OpenProvider at the F2F?
...
... proposal WILL GO to the list this friday

fjh: can discuss in conjunction with powerbox

<fjh> reminder - to discuss OpenProvider during F2F, presumably in conjunction with Powerbox discussion

<fjh> teleconf bridge info - http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0060.html

fjh: no speakerphone for F2F, so remote participants will need patience

<Claes> During the Powerbox discussion it would be good to have Google on the bridge

fjh: remote participants should go onto IRC and say when they are planning to call in

darobin: we have an address and a room, it's all on the wiki

Editorial

fjh: maxf proposed separating use cases from APIs

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0064.html (Max)

maxf: implemented the split in systems info
... to do use cases and requirements properly it takes a lot of space
... drawback is that if you want to publish it, you must publish separate document
... but still thing split is better. each editor could decide.

fjh: no preference really

<dom> +1 to splitting use cases out, don't feel strongly that we need to publish them as TR

<darobin> +1 to what dom said

fjh: will decide on case-by-case basis

Policy

it's fine

fjh: editorial change to policy section to make requirements types explicit

<fjh> ACTION: fjh to update policy requirements revising T* [recorded in http://www.w3.org/2010/03/10-dap-minutes.html#action03]

<trackbot> Created ACTION-103 - Update policy requirements revising T* [on Frederick Hirsch - due 2010-03-17].

fjh: prefer use cases in published documents

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

<Dzung_Tran> +1 for use cases in published documents

<jmorris> alissa: discussing apps informing users of what their policies are

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

<fjh> general agreement about talking about substance of policy, not ui (for now)

<fjh> ISSUE-73

<fjh> ISSUE-73?

<trackbot> ISSUE-73 -- Security and Privacy Implications for PIM APIs -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/issues/73

ISSUE-73

David: had been looking at use cases

<dom> ACTION-45?

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

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

David: matching policy parts to abuse case
... e.g., voicemail number changed to premium rate number

<dom> ACTION-45 due 2010-03-12

<trackbot> ACTION-45 Provide use case with threat model scenarios due date now 2010-03-12

David: hope to circulate tomorrow or friday
... trying to show how to resolve abuses with BONDi policy

<fjh> ISSUE-73: see ACTION-45

<trackbot> ISSUE-73 Security and Privacy Implications for PIM APIs notes added

<richt> ISSUE-73 discussion: 'Contacts API typical use cases and privacy considerations' http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0109.html

richt: had a good discussion with dom, should inform abuse cases

<fjh> ISSUE-73: see also http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0109.html

<trackbot> ISSUE-73 Security and Privacy Implications for PIM APIs notes added

richt: auto-filling the form

fjh: still not sure if we've dealt with policy concerns for that case

David: have not considered auto-form filling use case yet

fjh: will want to talk about that at the F2F

David: if we can maintain a list of abuse cases and threat model going forward, we should do that
... don't want to be repeating core threats all the time
... if user makes stupid decision, that's out of the control of the API
... might need a section on user's responsibility to themselves

<fjh> issue-37?

<trackbot> ISSUE-37 -- Domain spoofing and trust in the network layer -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/issues/37

ISSUE-37 domain spoofing and trust in the network layer

<fjh> action-38?

<trackbot> ACTION-38 -- Claes Nilsson to should issue recommendation on the granularity of the security system -- due 2009-12-16 -- CLOSED

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

<dom> Record of the discussions where ISSUE-37 was raised

David: we need to consider connecting to wifi in a cafe or airport and resulting security threats
... persistent connection to mobile provider is more secure at the moment
... tlr disagrees
... there are a couple of demos

<fjh> what is the next action, and by whom?

<dom> [can we rephrase this issue in form of a question that can get an answer?]

David: of domain spoofing

paddy: this boils down to use cases again

David: can add this aspect

<fjh> ACTION: drogersuk to add use case related to ISSUE-37 [recorded in http://www.w3.org/2010/03/10-dap-minutes.html#action04]

<trackbot> Sorry, couldn't find user - drogersuk

<dom> ACTION: roger to add use case related to ISSUE-37 [recorded in http://www.w3.org/2010/03/10-dap-minutes.html#action05]

<trackbot> Sorry, couldn't find user - roger

<dom> ACTION: rogers to add use case related to ISSUE-37 [recorded in http://www.w3.org/2010/03/10-dap-minutes.html#action06]

<trackbot> Created ACTION-104 - Add use case related to ISSUE-37 [on David Rogers - due 2010-03-17].

update to FileWriter

<dom> +1 to send a CfC on FileWriter

darobin: ready for FPWD at F2F?

richt: it's not using namespacing -- do we need it?

darobin: first decision was to do it case-by-case
... more impt to have consistency with file API in this case

richt: not concerned, just wondering if it affects other APIs

<dom> [I don't think that question should block FPWD in any cas€]

darobin: depends on the case
... have not been able to get any agreement otherwise
... agree that it shouldn't block FPWD

<richt> richt: agreed

darobin: style of writing API descriptions -- normative statements can be clunky but we might want them

David: Marcin submitted design patterns document that might be helpful

sorry about the names

<dom> (last update to design patterns was in October)

darobin: hasn't been updated since November?
... can talk to him about picking it up

<dom> Marcin's draft on API Design Patterns

update to Messaging

maxf: looks perfect to me

<dom> [I read through it, I think it's in good shape generally speaking]

nwidell: will not be at F2F

darobin: no issue with publishing it

nwidell: would appreciate comments

darobin: asking for publication will accomplish that - CfC

nwidell: will make editorial changes by monday
... go ahead to CfC now

darobin will send CfC after call

System Info next steps

Suresh: Calendar API has been sitting around for a month now
... action out on harmonizing with IETF, that work is complementary

<richt> I agree with Suresh

Suresh: want to go to FPWD
... will add a note about the compatability issue

darobin will send CfC for calendars as well

dom: mapping may not be complementary
... may not have consistent view of scope of Calendar API

Suresh: we don't cover entire set of cases, it's true
... but have placeholders for most items

dom: agreed

<richt> there's some...interesting...stuff in the Calendar API...will need a thorough review and welcome further comments before or during the F2F

dom: withdraw my comment

<dom> [I don't think all my comments have been integrated in the calendar API; hence why I haven't further commented on it, FWIW]

System Info

maxf: mapping to DCO, thresholds are outstanding issues
... prepped a list of items to discuss at F2F

<darobin> ACTION-100?

<trackbot> ACTION-100 -- John Morris to share information on key important privacy policy aspects relevant to DAP -- due 2010-03-10 -- OPEN

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

<fjh> action-100?

<trackbot> ACTION-100 -- John Morris to share information on key important privacy policy aspects relevant to DAP -- due 2010-03-10 -- OPEN

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

fjh: is action-100 still open?

jmorris: will have something but perhaps not until monday
... walking through different APIs to suggest which privacy issues are most importance
... can get something higher level out earlier and more granular later on

no problem

- DRAFT -

Device APIs and Policy Working Group Teleconference

10 Mar 2010

Attendees

Contents