Draft minutes 2009-10-07

Attached are Draft minutes from 2009-10-07

# Device APIs and Policy Working Group Teleconference

## 07 Oct 2009

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

     Robin_Berjon, Frederick_Hirsch, Thomas_Roessler, Ilkka_Oksanen,  
Kangchan,
Robin, Dzung_Tran, Paddy_Byers, wonsuk, AnssiK, Niklas_Widell,  
Marcin_Hanclik,
Jere_Kapyaho, Laura_Arribas, Richard_Tibbett, Brian_LeRoux

Regrets

     Dominique, Hazaël-Massieux, Marco_Marengo, maxf

Chair

     Robin Berjon, Frederick Hirsch

Scribe

     Anssi Kostiainen

## Contents

   * [Topics][5]

     1. [Welcome][6]

     2. [Minutes approval][7]

     3. [Policy Segment - API Identification][8]

     4. [policy - use of model dialogs][9]

     5. [Policy action review][10]

     6. [API Segment][11]

     7. [Adjourn][12]

   * [Summary of Action Items][13]

* * *

<trackbot> Date: 07 October 2009

<darobin> AnssiK, will you be joining the call today?

<darobin> Kangchan: it's too early, the call starts in 5 minutes

<Kangchan> Robin: Thanks..

<darobin> and the correct syntax is "Present+ KangchanLee" :)

<darobin> Victims list is: wonsuk, AnssiK, Mohammed, Daniel, Rob Ennals

<darobin> Scribe: Anssi Kostiainen

<darobin> ScribeNick: AnssiK

<dtran> +dtran

<dtran> +dtran

### Welcome

fh: everyone, please say "Present+ YourNick"

<fhirsch> TPAC registration and hotel reminder, registration until 23  
October

fh: TPAC extended the lower registration fee period

... there's also a dial-up questionnaire, please fill it in if you  
plan to
call in to TPAC

<fhirsch> Mobile Web Application Best Practices

<fhirsch> [http://www.w3.org/TR/2009/WD-mwabp-20091006/][14]

<fhirsch> ask for reviewed

<darobin> **ACTION:** Robin to review MWABP [recorded in
[http://www.w3.org/2009/10/07-dap-minutes.html#action01][15]]

<trackbot> Created ACTION-26 - Review MWABP [on Robin Berjon - due
2009-10-14].

fh: the questionnaire is actually closed, so send an email to the  
members list
instead

### Minutes approval

<fhirsch> [http://lists.w3.org/Archives/Public/public-device-
apis/2009Oct/0045.html][16]

**RESOLUTION: Minutes from 30 Sept approved**

### Policy Segment - API Identification

<drogersuk> I can hear you all now, thank you W3C office for letting  
me in!

<fhirsch> issue-26?

<trackbot> ISSUE-26 -- How to refer to API -- RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/26][17]

fh: features, attributes, modules discussed in the context of Policy

<fhirsch> question of granularity of access control for APIs

marcin: not sure if agrees on the granularity level

<fhirsch> do we agree on granularity at method level, or group of  
methods
called a feature

<fhirsch> how to deal with modules as a whole

marcin: ... in BONDI we added attributes and constants under feature

<fhirsch> what is approach to attributes

<Zakim> Thomas, you wanted to note that there are different security
considerations for adding a contact or reading one

<fhirsch> note that we may want to raise issue for security related to
events/callbacks

Thomas: question about an API that can access data storage

<tlr> the point is less about storage, but more about the distinct  
security
considerations... This is an example.

marcin: you can do everything on storage

<brianleroux> +Brian_LeRoux

Thomas: for reading and writing or reading, depending on the UC I  
might have
different security considerations

<tlr> thx

<brianleroux> ah, thx

marcin: current filesystem API from BONDI has filesystem.read and
filesystem.write

... all methods and attributes are covered needed to read from the file

... CRUD mentioned

... as in Create, Read, Update, Delete

<fhirsch> marcin suggests that features need to be defined according  
to CRUD,
one feature for each...

marcin: we'll need a CRUD design pattern for all the APIs

... example: open, read and close methods

... reading UC: we should also cover the constants

... opening a file uses reading and writing?

... someone who has access to the file reading UC could open a file in  
a write
mode and open would be succesful in write mode

... what happens if someone opens the file in truncate mode

fh: the issue with callbacks and events

marcin: I don't know how it's expessed with a URI

<fhirsch> Marcin notes may not protect existing events, but restrict new
events and handlers introduced in DAP

marcin: events such as keypress discussed

JereK: if you are given access to a function, callbacks should be also  
allowed

marcin: callbacks that are parameters to event listeners will be handled

<fhirsch> feature may include method plus input arg to be meaningful,  
eg file
open with read or write input argument would correspond to different  
features

<tlr> declarative definition of handlers in mark-up

<tlr> input events

marcin: handlers such as onkeypress

<fhirsch> input events - see email from David Rogers...

marcin: handlers the concern, not the callbacks

fh: there's many ways code can be executed

<marcin> About features, possible principle: "protect information, not  
APIs
that are behind it"

fh: URIs seem to be a good approach, there seems to be a general  
agreement

<marcin> About events: [http://lists.w3.org/Archives/Public/public-
webapps/2009OctDec/0069.html][18]

fh: hierarchical use of features

... one API can invoke another API

<fhirsch> issue-27?

<trackbot> ISSUE-27 -- [Policy] Is revocation in scope -- RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/27][19]

fh: do we want to discuss revocation?

... there are many mechanisms

... wants to raise the issue explicitly

<JereK> charter, section 2.2: "The management of security policies ...  
is out
of scope"

<fhirsch> management is out of charter scope, so I believe we should  
consider
revocation out of scope

drogersuk: kill switches discussed

<fhirsch> but I suggest we can consider authentication in scope

drogersuk: we should leave the policy discussion to the end?

... do we have an e2e view re policy?

<drogersuk> I agree that the detail can be deferred, but we need to
acknowledge it somewhere

<tlr> +1 to deferring

<drogersuk> in a policy overview doc or something

<drogersuk> so policy needs to come from somewhere and then go  
somewhere (good
or bad) - e.g. removal / revocation / kill-switches / management

fh: do the others have comments re deferring to v.next?

<JereK> +1 to defer

<paddy> +1 to more time

<wonsuk> +1 to defer

<drogersuk> I agree with Paddy

<drogersuk> we need to scope

paddy: what's the scope for work we're deferring?

<fhirsch> proposed resolution- defer specifying revocation mechanisms or
expressing them until v.next

paddy: BONDI specifics discussed

<drogersuk> anssik: paddy

<tlr> fjh - agreement: 1. defer, 2. keep some hooks

fh: paddy to provide a proposal for resolution

... I raised another issue on the list based on position papers

... feedback given we should not be so strict

... Geolocation API is a bit different

### policy - use of model dialogs

marcin: Geolocation spec not limited to dialogs

<fhirsch> issue-28?

<trackbot> ISSUE-28 -- [Policy] Requirement for NO security prompting --
RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/28][20]

<Zakim> Thomas, you wanted to speak to a scope point here

Thomas: having too many conversation on security UIs

... non-modal UIs discussed

... we should not specify APIs which require modal dialogs

... modal dialogs are blocking

<marcin> +1 to non-blocking / asynchronous methods

Thomas: UA differences to be taken into consideration

fh: easy out for security policy to use modal dialogs

<tlr> +1

### Policy action review

<fhirsch> action-15?

<trackbot> ACTION-15 -- Marcin Hanclik to review/compare device  
capabilities
and features -- due 2009-09-30 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/15][21]

<fhirsch> action-15 closed

<trackbot> ACTION-15 Review/compare device capabilities and features  
closed

marcin: sent an email re the action above

<fhirsch> action-23?

<trackbot> ACTION-23 -- Paddy Byers to open an issue and start a  
discussion on
features/device capabilities -- due 2009-10-07 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/23][22]

fh: capabilities and features under discussion

paddy: will send an email to the list

fh: any topics on policy I have missed?

... otherwise let's move on to APIs

<paddy> Scope excludes UA requirements relating to support for  
revocation,
including support for specific certificate profiles, OSCP profiles, or  
any
requirement to support certificate status/CRL checking.

<paddy> Scope includes ensuring there is provision within any formats or
policy or trust model that may be necessary, under reasonably  
foreseeable use
cases, to allow such requirements to be specified independently.

**RESOLUTION: Scope excludes UA requirements relating to support for
revocation, including support for specific certificate profiles, OSCP
profiles, or any requirement to support certificate status/CRL  
checking.**

... Scope includes ensuring there is provision within any formats or  
policy or
trust model that may be necessary, under reasonably foreseeable use  
cases, to
allow such requirements to be specified independently.

### API Segment

<darobin> [http://dev.w3.org/2009/dap/api-reqs/Overview.html][23]

darobin: please review the requirements so that we can publish it as a  
Note

... Working Draft actually before a Note

JereK: system information sensor access lumps sensors under sysinfo

... should those be split

... aka Sensor API

darobin: what should be in the first version of the requirements  
document

... the 1st version we put out do not have to be perfect

... ok to push the document out with the sensor issue?

<paddy> +1 for dedicated extensible sensor API

JereK: NFC mentioned

<drogersuk> NFC is a write and read transducer

<drogersuk> sensor and 'actuator'

Thomas: WD should be published ASAP

<Claes> +1 for extensible sensor API

<brianleroux> +1 to publish

darobin: any concerns re fast publication?

<brianleroux> +1 for sensors

fh: it would be valuable to get feedback, and publishing a WD is a  
good way to
accomplish that

**RESOLUTION: publish a Working Draft of the Requirements document  
before
TPAC**

darobin: proposing a doing quick actions review, if no specific issues

<brianleroux> hey, sorry my call dropped

<brianleroux> yes to file and camera

<fhirsch> action-19?

<trackbot> ACTION-19 -- Brian LeRoux to leroux to review contact,  
camera,
file-system -- due 2009-09-30 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/19][24]

ACTION-21?

<trackbot> ACTION-21 -- Bryan Sullivan to send comments about Arve's
requirements for ISSUE-6 -- due 2009-09-30 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/21][25]

darobin: AOB

... straw-poll on device object

drogersuk: about Contacts API, are we taking Nokia, BONDI and PhoneGap  
inputs
as is or start from the scratch

darobin: we're starting with requirements gathering

... the draft was to kick-start the work

<drogersuk> so it could be 'another' API to add to the mixx

darobin: took parts from both Nokia and BONDI

<brianleroux> drogersuk: the more we look at the better / PhoneGap is an
aggregate of all the mobile smartphones

drogersuk: concerned on the length of time it'll take to produce the  
specs

<brianleroux> however, for example, I quite like googles contacts api  
for
gmail, etc

<drogersuk> what about design patterns for example?

darobin: we can start with existing inputs, but both have issues so it  
would
not actually speed things up

drogersuk: design patterns should provide the basis for all the APIs

darobin: patterns easier to derive from concrete work

drogersuk: we should draw from the experience from the inputs

darobin: not sure how we're not using prior art to our advantage

drogersuk: to dive into specific API and doing it again could end up  
in doing
more work

darobin: argument understood, not clear what is proposed to address it,
publish patterns beforehand?

marcin: re design patterns, in BONDI we have tried to identify the  
patterns

... similar document could be delivered to DAP

<drogersuk> can we agree a clear strategy in terms of API design?

<darobin> **ACTION:** Marcin to provide a design patterns document  
before TPAC
[recorded in [http://www.w3.org/2009/10/07-dap-minutes.html#action02] 
[26]]

<trackbot> Created ACTION-27 - Provide a design patterns document  
before TPAC
[on Marcin Hanclik - due 2009-10-14].

drogersuk: wants to see a strategy how we'll deliver the APIs instead  
adademic
discussion on API design

darobin: AOB

Bryan: would like to see design patterns done fast, there's market  
momentum
which would benefit us moving fast

drogersuk: looking at the inputs and conflicts in them

darobin: we have three primary inputs, in some cases four

<richt> q

darobin: it would be a bruising process if we start looking into  
inputs in
details

drogersuk: can we identify areas where we agree on

darobin: beneficial approach for generic patterns

<drogersuk> in APIs too, not just the patterns

darobin: we as a group don't want to do the same mistakes as what's
potentially present in the input

### Adjourn

## Summary of Action Items

**[NEW]** **ACTION:** Marcin to provide a design patterns document  
before TPAC
[recorded in [http://www.w3.org/2009/10/07-dap-minutes.html#action02] 
[26]]

**[NEW]** **ACTION:** Robin to review MWABP [recorded in
[http://www.w3.org/2009/10/07-dap-minutes.html#action01][15]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][27] version 1.135 ([CVS
log][28])

$Date: 2009-03-02 03:52:20 $

    [1]: http://www.w3.org/Icons/w3c_home

    [2]: http://www.w3.org/

    [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Oct/0066.html

    [4]: http://www.w3.org/2009/10/07-dap-irc

    [5]: #agenda

    [6]: #item01

    [7]: #item02

    [8]: #item03

    [9]: #item04

    [10]: #item05

    [11]: #item06

    [12]: #item07

    [13]: #ActionSummary

    [14]: http://www.w3.org/TR/2009/WD-mwabp-20091006/

    [15]: http://www.w3.org/2009/10/07-dap-minutes.html#action01

    [16]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Oct/0045.html

    [17]: http://www.w3.org/2009/dap/track/issues/26

    [18]: http://lists.w3.org/Archives/Public/public-
webapps/2009OctDec/0069.html

    [19]: http://www.w3.org/2009/dap/track/issues/27

    [20]: http://www.w3.org/2009/dap/track/issues/28

    [21]: http://www.w3.org/2009/dap/track/actions/15

    [22]: http://www.w3.org/2009/dap/track/actions/23

    [23]: http://dev.w3.org/2009/dap/api-reqs/Overview.html

    [24]: http://www.w3.org/2009/dap/track/actions/19

    [25]: http://www.w3.org/2009/dap/track/actions/21

    [26]: http://www.w3.org/2009/10/07-dap-minutes.html#action02

    [27]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

    [28]: http://dev.w3.org/cvsweb/2002/scribe/

regards, Frederick

Frederick Hirsch
Nokia