Workshop on Security of access to device APIs from the Web

Day 2: 11 Dec 2008

See also: IRC log


Lucas Adamski (Mozilla Corporation)
Nick Allott (OMTP Limited)
Martin Andrew (Oxford University)
Luis Barriga (ERICSSON)
Arthur Barstow (Nokia Corporation)
Steven Bellovin (Columbia University)
Arve Bersvendsen (Opera Software)
Johansson Björn (Ericsson)
Stewart Brodie (ANT Software Ltd)
Paddy Byers (OMTP Limited)
Marcos Caceres (W3C Invited Experts)
Coimbatore Chandersekaran (CIO Staff US Air Force)
Anil Dhawan (Microsoft Corp)
Paul Downey (BT)
Max Froumentin (Opera Software)
Anselm Garbe (Aplix Corporation)
Philip Hallam-Baker (VeriSign Inc.)
Marcin Hanclik (ACCESS Co., Ltd.)
Dominique Hazaël-Massieux (W3C/ERCIM)
Kai Hendry (Aplix Corporation)
Rainer Hillebrand (Deutsche Telekom AG, T-Com)
Frederick Hirsch (Nokia Corporation)
Adrian Hope-Bailie (dotMobi)
Dowan Kim (SKTelecom)
Ben Laurie (Google)
Stephen Lewontin (Nokia)
Marcus Liwell (Sony Ericsson)
Michael Mahemoff (Osmose/BT)
Fabio Massacci (Università degli Studi di Trento)
Ford Matthew (Internet Society)
Claes Nilsson (Sony Ericsson)
Patrik Persson (Ericsson Research)
Hoschka Philipp (W3C)
Mark Priestley (Vodafone)
Dave Raggett (W3C/ERCIM)
Tim Renouf (Aplix)
Thomas Roessler (W3C/ERCIM)
David Rogers (OMTP Limited)
Anders Rundgren ()
William Simpson (Institute for Defense Analyses)
Doug Turner (Mozilla Foundation)
Matt Womer (W3C/ERCIM)
Mary Ellen Zurko (IBM Corporation)
By phone:
Olli Immonen (Nokia)
Nick Allot, Thomas Roessler
Phill Hallam-Baker, Matt Womer, Paul Downey


Towards a community-controlled security policy for Widgets (Marcos Caceres, W3C Invited Expert)

See also: Position paper, slides

Marcos Caceres: A child of web 2.0 community driven approach ...
wikipedia facebook and so on, malware is rampant in these systems, ...
botnets by the billion, etc.

Doug: Is this in packaging? How is it enforceable?
... I wanna write a web application and use this packaging ...
... and I say feature name = URI yes or no and ...

Marcos: exception

Doug: this is a feature for widgets specifically, not pages in general

Marcos: yes

Marco: This is somthing that should be part of widget engines just like anything else, as
... today we would use for geo-priv, later gate access to cameras and so on
... also protected by digital signatures

Max: what does the last URL mean

<dom> this could be used for a "Web App", by linking a given page to a config file (e.g. <link rel="config" href="config.xml" /> with the <feature> elements declared there?

Marcos: it means this represents a feature (geolocation) with a particular level of precision (100m)

??: This is both a least priv mechanism and a api mechanism, by inspecting the manifest can determine the level of features required

Marcos: yes

Doug: There are going to be some APIs like camera which have stuff built into them that don't have a privacy concern until they are in another system, this is going to get messy, have a manifest that talks about web runtimes, may be a good feature for the Web in general not just widgets

Adrian: a good model that could also be used on the web, wonder about feedback, what aspect of feature that should be visible.

Marcos: our concern has been how to get access to the information

Adrian: Does it handle privacy 'this is my location keep as long as you like

<matt> PHB: I saw units at the end of the URL for geolocation. I think there's no need for other units other than SI. I also think the device should be able to lie to the widgets.

<matt> PHB: When I load a game on my daughter's machine, it asks for system privileges, for no good reason. If this is going to be practical on the large scale, you need to be able to say "You have it", but then you don't.

<matt> marcos: I don't think that goes in the spec.

<matt> PHB: No I think you do.

Paddy: In case of API you can say I need this feature, in the case of a manifest you can say these are the features I need. Don't want to allow an inspection API that allows device to find out everything it is allowed to know.

ArtB: General question are we doing a widget spec or a web spec. We have a charter to focus on a narrow spec. Want think beyond widgest but finish

Marcos: this supports multiple software security models.

Doug: two points, not sure at this point what the value is of a declared set of featues for a widget, couple that with the social screen this will be resolved by itself. If you have a webapp that is going to get signed, you are going to have a machine that determines that the feature is required. Social screening works.
... every firefox addon has been reviewed

PaulD: +1 the metadata

<pauld> cites Cory Doctorow's Metacrap: http://www.well.com/~doctorow/metacrap.htm

Web Runtime Policy Based Security (Steve Lewontin, Nokia)

See also: Position paper, slides

Steve: Q&A

??: What is you view on Web applications verify? dynamically accessed web content

Steve: Use the location from where the content came as the primary trust attribute
... yes TLS, hard to tell if content has been modified, particularly on movable USB drives, signed code artifact around is the only trusted scalable solution

Martin: Questions related to BONDI,
... do you want to contribute to there

Steve: open to participate in other solutions, want open-y-ness

Art: no, nothing else to add

Marcos: Who actually designs the policy

Steve: good question as policies are not easily designed.
... Whoever designs policy should be person responsible if something goes wrong.

??: update

Steve: We don't provide a method of update but there are many ways to do that

Security Model for browsing and widgets by Olli Immonen

See also: Position paper; slides

BONDI: A Web based security model fit for purpose by Nick Allott (OMTP Office), David Rogers (OMTP Office), Geoff Preston (OMTP Office)

See also: Position papers; slides

fjh: Have you considered taking the XACML variant to the OASIS TC?

Nick: Have considered doing that but not as a dependency

fjh: Is this big or small, seems small

Nick: small.

Paddy: Have identified issues, would like to take them back to XACML?

Anil: Discussed identification of target APIs? Have you considered mapping out API surface area? Is that in scope?

Nick: yes

Anil: Are you thinking of W3C compliant widgets or W3C Bondi compliant widgets?

Nick: Not trying to create a parallel universe here. Complementary.

Art: just thinking of whom your recipient in W3C might be for this work

Nick: why we are here
... have relatively well speced scoped for certain widgets,
... but not all, don't know where is best for others,
... Geolocation, persistence.. different locations in W3C.
... W3C community needs to decide what goes where.

Max: you are going to use many different specs as sources,
... how are you going to keep consistency between them
... even in W3C geo is at odds with others

Nick: For all of the different APIs have different companies working on them so consistency is already an issue.
... Consistency review led to changes

<dom> (it would be interesting to send that feedback about inconsistency between fileio and geo to the relevant w3c groups)

Nick: conflicting constraints want consistency but existing ones are deviating slightly.
... working model is to have 1:1 mapping where a W3C pproach exists.

DougT: IPR?

Nick: WTAI stuff been around for 7 years.

Thomas: what is relationship of your proposals to OMA specs?

fjh: From psotion of project manager how would this look,

Nick: lets break it down into, there is open source implementation
... and then there is the standardization veneer on the top
... want to get as many pieces ratified in W3C structure as possible
... so come in with spec and canidate code that works.

Art: Managing expectations, get worried about accelerated security standards.

Nick: that's life
... there are real implementations being rolled out that may or may not be secure.
... when we say accelerated we are trying to apply any strategy we can to accelerate.
... open source is one such

<fjh> should also consider bringing XACML modifications and profile work to OASIS XACML TC.

Doug: one of the things not clear on is, phone status is interesting as I have a mobile browser
... have no idea if DCCI is right thing to use for phone support, might be completely differently, is the opposite way to we did geo
... geo knows a lot about the web, little bout geo
... DCCI is opposite, are you going to implement it all?

<fjh> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

Nick: we defined a set of requirments, existing, mapped to DCCI requirements, thats the basis, real problem, on the ontology as it stands at the moment is location, there is also the geolocation API

DCCI is general purpose API, there is also a specific api that gives more detail.

there is redundancy but that is just the way things are

Tlr: how does dynamic API relate to DCCI

Nick: from memory there are some provisions for API discovery to say if things are there or not.

Paddy: principle is that bondi or any other org is not going to be the only party that defines api. will be many others.

<dougt> dom: +1

art: have any of the interface specs that bondi has cretd today have dependence on DCCI

NickL: Only the phone status

matt: have advantage to sing one api, might want to have an event handler for all events and use DCCI for that

<marcos> it's an architectural frankenstein... "brains!"

<matt> [[ DCCI could also be more valuable if you don't believe marcos' assertion that there won't be millions of these ]]

<fjh> http://www.amazon.com/Extech-RHT10-Humidity-Temperature-Datalogger/dp/B001AFFVWQ/ref=pd_bbs_sr_5?ie=UTF8&s=hi&qid=1228989978&sr=8-5

WebVM - Security policy for device API access by Paddy Byers (Aplix), Kai Hendry (Aplix)

See also: Position paper; slides

PB: WebVM is a plugin that allows API access to devices. It's use cases are both widgets (packaged web apps) and web pages.
... WebVM supports binding to java APIs and making them available as javascript APIs
... hence, it is extensible as the JavaAPIs, like JSRs, are defined elsewhere and they can be available in javascript...

PB presents the architecture at large...

PB: webVM sits as part of the standard architecture that browsers already use
... there is a security manager that intervenes in the process....
... wrt security, webVM supports a fine-grained security model which is somewhat similar to what has been discussed this morning

PB describes how the whole thing stitches together wrt digital signatures and identifying where a package came from.

PB: we need to support existing security models that are currently in use in the software world. But with the possibility of extending on those.
... it's still up to the user to decide if they trust the software, but with the combined trust model that is provided by using signatures and that the software won't do more than it says it will do.
... need to support multiple signatures. The problem is that operators or distributors will delete any signature that authors put on the software. This is problematic from the standpoint of non-repudiation

(who authored the widget in the first place is lost)

PB: the problem is that the permissions are not fine grained enough in current models. Eg. gmail asking for web access, instead of access to just gmail.com
... with a common base, fine grained permissioning can be shared across apps and stored persistently... but at the same time, it gives user more control by allowing the user to override the declared permissions
... in the model have at the moment, the page that contains the application/content determines the rights
... there is problematic because if the page is compromised then malicious code can get access to those rights
... on widgets, they rely on the id (which is a URI).... operators can grant rights based on the certs.... need to support multiple signature profiles for right access
... for when java code, instead of the javascript, tries to do something that would be deemed security sensitive on the platform, it is not allowed because permissions are based on the page context and not by Java.

(the above being part of the WebVM security model)

PB: hence the java packages can be treated as being secured by the WebVM model as a whole.
... the XACML-inspired model, is a tree, it has a target for rules, rules have conditions and effects.
... there were certain things in XACML that we were not able to do. We added support for undefined values. We added combining rules, and other rules like ones related, for example, particular phone numbers... we submitted this to the BONDI project.
... for standardization, a security model should not be hard coded into the spec...
... we are not trying to solve every problem, but we can cover a lot of use cases.

AB: this remote provisioning functionality, is that something is going to specify?

PB: it's something that bondi has worked on. But we havent worked on how you identify the authority to configure parts of the policy
... we don't distiguish which parts of the policy tree are controlled by which authority

Security model for widgets based on the MIDP security model, and a security model for web applications based on TLS/SSL and XMLDsig by Marcus Liwell, Claes Nilsson (Sony Ericsson)

See also: Position paper; slides

ML: Widget security models... different views between web pages and widgets...
... the main difference is the different installation procedure... but to the user the are as the same.
... for the case of widgets.... support for digital signatures. Protection domains... we want to see some sort of declarative model to declare what capabilities it want to use
... untrusted and trusted widgets. Untrusted widgets, without origin, then they cannot be trusted on the device. A trusted widget being one with a signature that can be mapped into a security domain.
... having predefined policies that trusted and untrusted widgets can map to. But also giving the end-use some authority/access-rights over the policies

ML presents a declarative model for device API access.

ML: then we come to Web Applications. One way to identify the web app is via TLS/SSL
... the web app is verifiable via it's origin and cert
... we want to see some alignments between the widget and web apps world.
... we want the users to view them as the same.

<tlr> I think I heard a use case today for having several distinct signature classes defined in the widget signature spec. *at* *least* "author" and "intermediary" (aka operator)

some random questions... end of presentation

<tlr> maybe "role" of the signer

Software Components for Secure Mobile Web Application Platforms by Patrik Persson and Björn Johansson (Ericsson Research)

See also: position paper; slides

PP: Software components for Secure Mobile Web Apps Platforms

PP: we work for Ericsson Research... we are not part of the product section...
... lab phones are ugly on purpose :)
... prototyping a completely widget-based terminal
... based on widget spec, linux, etc

PP: need separation of concerns
... we are dodging the policy issue... looking at sofware component models instead
... ...software component models... such as DCOM, COM, etc...
... because we rely on IDL, this is a fairly language independent
... using IDL to some converter, we can produce a javascript equivalent
... translating this into javascript makes a lot of sense...
... of course, there are limitations such as memory pointers, etc. So we avoid those

PP presents the basic architecture

PP describes how it all works together... [but the scribe is confused]

PP: advantages include good separation concerns, language independence, using COM gives us a single point of entry to the platform. Once we secure that, we have something good. But there are some challenges: maintaining runtime identity, dynamically downloaded shim layers, performance, and user experience.

DA: I have 2 questions, how do you declare intent within the package?

PP: that is the way we do it. The granularity, we use part of the w3c config document stuff. But we have a UUID that is verifiable at runtime so we know the interface that is being invoked.

NA: does UUID mean you need some kind of registration authority?

PP: no

DA: about shim layers... do you think standardization can help with the creation of that shim layer?

PP: we come form the platform side of things... I see the user for the device manufacture to be able to avoid locking down the final APIs. I see the need for a well defined shim layer.

Security by contract for the embedded Internet by N. Dragoni (University of Trento), F. Massacci (University of Trento)

See also: Position paper, slides

FM: ... you can't completely trust everyone, not even someone like google because everyone can be hacked...
... describes 4oD
... it installs P2P software
... it's not shady software... or is it?
... it's hidden license agreement...
... that you legally allow your machine to be used this way... and you have a problem talk to your ISP.
... the user can't even protect them selves by suing because it's in the license agreement
... so what is to be in a contract. It has to be machine readable.
... should be embedded in the manifest
... same as in widgets 1.0

<fjh> how about n3 :)

FM: declarations in a simple format.. if BEFORE/AFTER api..
... ... and then it runs or the user takes the risk.

<fjh> ws-policy intersection relevant to matching task, eg. how to intersect policies needs to be understood?

<fjh> http://www.w3.org/TR/2007/REC-ws-policy-20070904/

FM: what platform stakeholders want... no violation of the platform policy (don't go ringing strange numbers), What developers want... for the enforcement policy to not break the application, etc.... what user s want is that the application is safe and good for them...

FM shows demo

FM: here we have a chess application that is untrusted
... ... you can select the policy you want..
... eg, no sms,
... ... so we deploy and run. The application is not signed...
... ... so the policy is set up.
... it shows info about the application. the user agrees and the game runs
... so now we play chess over SMS

NA: makes a chess move.

FM: if I try to move. An error dialog pops up and kills the application because of the security violation

NA: any questions

AvB: my worry is, there is evidence that the user will most likely screw up policy selection.

PHB: the reason was the active x would nag you, and then nag you again, and so on till the user clicked yes

dougt: how do you see these applications getting on the devices?

FM: I see that you would get it from operators, but it could be from anyone.

themes so far today

NA identifies some common themes that have emerged

<hendry> widget and web differences?

<arve> I'd personally like that we keep in mind that tools are never going to save us

scribe: policy management is important but difficult.

<dougt> arve: +1

<matt> I'd also like to add that centralized authorities are unlikely to save us either, see Aurora Feint/address book debacle

PB: when I got to my banking website, when the banking website presents me with a iframe I still trust it. There are still lots of problems on the Web. Is there prerequisites that we need to solve on the Web first? Are we just going to throw our hands in the air and say "nothing works securely"?

TLR: so, to reiterate, there are problems with web browsers today, do we need to solve those first?

NA: we don't need to answer that now, but leave it for later today

AB: what are the topics for this afternoon?

AvB: the tools wont save us! :D
... discussion about declarations, authors will copy and paste...

Lucas: sure, community might help, but sandbox is really important here.

<fjh> suggest WG consider using existing standards, such as XACML. May wish to share noted needs with OASIS TC to determine fit with most recent XACML work, possible profiling in that TC might be possible.

<arve> Unfortunately WebIDL wouldn't work as a policy language

<arve> it lacks certain capabilities you are going to want

<arve> (esp. regarding network)

<fjh> Doing general policy work might be hard, some work has been done in this area in WS-Policy (eg how to determine intersection of policies with alternatives etc)

<matt> arve, I think the suggestion of WebIDL was not suggested for policy, just the interface definitions


<matt> scribe:Matt

Brainstorming on Conclusions

tlr: Agenda, now until 3:30 one session, could be the end then or go from 4-5 as well.

<pauld> cited XML 2006 talk on policy languages: http://2006.xmlconference.org/programme/presentations/63.html

tlr: A number of themes have come up.
... What ever gets done should be the same for the Web as for widgets.
... I'd like to deep dive on that.
... In the policy related presentations we had about identifying actors and sites. Deep dive on that.
... How do we identify and name the actors?
... Another thing we said: API's identified and defined in machine readable format
... marcos said it could just be a URI with some known constraints, for instance.
... API discovery.
... Policy management.
... Themes in the discussion on this: declaration of intent
... -- apps identifying the APIs used at install time.
... exchanging policies as well.
... On policy management, I'd like for us to be able to report on the level of interest there
... UI and usability arguments have been brought up numerous time. Difficult to standardize..
... Coordination of any work that might come out of this workshop. Whhat do we need to consider within this environment? What about the work within the W3C?
... I'd like the report to reach some conclusions on there as well.
... Are there points that have been missed?

DKA: Anything on those topics, can we think about charter fodder, think in terms of deliverables that we can work on, either in an existing group or another.

tlr: Yes, that is what I meant by scope, thanks.

Web and Widgets, should they be the same?

DKA: It's a philosophical more than technical point.
... Widgets work should be extending the Web into being able to operate offline.

<pauld> +1 to DKA

DKA: The work on APIs should be extending the Web into being able to securely access capabilties on a Web device.
... How do we make sure the work we're doing extends the Web rather than 'break' it.

Lucas: I think of widgets in terms of context of the widget. If it's in a page on a browser, or if it's on the desktop, or with total system access...
... You can get into the semantics... I don't think widgets on the desktop need to be fully privileged

Paddy: Arve said <something> there's no argument that the APIs shouldn't be the same between the two.
... In BONDI we identified two differences. The way in which you express a dependency on an API....
... Two differences: 1. <missed> 2. If you have a policy the <also missed>.

Adrian: I agree, the only difference being the declaration aspect. Widgets have a way of providing identity that Web apps don't. Perhaps the widget model is more secure or more established. More possibilities.

If a widget run time is created with the same constraints as the browser, then they're essentially identical.

arve: If they're identical or not is philosophical in one way, but also they are something more: full fledged applications written in the Web as a platform.
... As such, I'd say all Web applications/pages are a subset of widgets

<dom> "browsers are widgets" -- dougt

ArtB: We could rathole on this discussion (and surely will).
... If in your mind there is some reason to differentiate between these two things, and it will maniftest itself as different work items I'd like to know

PHB: I'd be cautious of us saying "Let's limit our scope of inquiry because that will make our work shorter"... Groups that chop stuff out arbitrarily tend to take longer as the scope expands.

DKA: I think this is an important question because: are we designing part of the Web or are we creating a new way to write Java apps on your phone.
... I think it's much more interesting and relevant if we do the first.

tlr: I'm biased that the first one is important.
... If people here think it's more the second one, then maybe we shouldn't make assumptions.

dougt: There is a third category beyond Web and Widgets, Desktop like applications, like AIR, and fx Prism.
... The Web in the browser on your desktop... The Web in your browser on your phone...

arve: Is there a difference between AIR and widgets?

Lucas: Ratholing some more: we probably shouldn't redefine applications as widgets.
... At Adobe they wanted to call AIR applications widgets.
... There is that space between a Web app and a Desktop app, and that's a big space. I don't think it's productive to define widgets.

dom: Paddy identified two ways in which widgets are different than Web apps: 1. a manifest and 2. trust model.
... The fact that widgets have a manifest could easily be extended to a Web site.
... In terms of defining a security model for this stuff, does it matter or not if these two are different? In one case you have well-defined distribution and identity model, and in the Web you don't have that policy.

Paddy: one way people make a difference between applications and web sites is that applications go through an installation process

Lucas: The difference betweeen Web app and applications isn't meanignful... <?>

<hendry> diff is implicit installtion process

Lucas: <something about implicit installation process>

<DKA> For the record: I was using "Java Apps" as an example of a "closed ecosystem" of mobile applications (i.e. not "The Web").

tlr: Packaging, trust model, identity... these are the three things we see.

dougt: I think these are more the same than different.

tlr: I would say don't introduce technology in the widget space that makes it unnecessarily difficult to use in the Web space.

ArtB: If that's not a design goal then marcos should clarify it.

smb: There are a fair number of problems with marrying the Web and the desktop. The properties of trust are very different. Where decisions are made, etc...
... Windows 95 help files for instance.
... They were in MS hypertext-like things.
... They had helpfiles that were capable of executing dangerous code.
... Download an .hlp file and it could format your hard drive.

<pauld> same could be said of Word documents, a popular conduit of malware

smb: XP SP 2 tagging stuff in file metadata that came in from the net, so that it wouldn't be treated as trusted content...
... That allowed you to distinguish stuff that could be trusted and that which can't.
... We need a very bright line at the trust boundary.
... Cookies, stored one per file... could be stored on disk with trusted JavaScript in it.

tlr: We seem to be assuming as a given that we will see application like things written in HTML and JavaScript. Is there an additional trust boundary that we can put in?

<dom> "Applications-like things written in HTML and Javascript" -- tlr

tlr: We have a Web page that has an origin there, and that's the only thing we know about it's origin. Can we trust it and give it capabilities.
... Are we taking the policy for granted? <?>
... What I heard in Aplix presentation: we have different types of identity. We can base the decision on signature. The Origin is the only thing we have on the Web.
... Is that all there is to be said about identity or are there other points that need covering?

<pauld> marcos: at the moment a widget may not have a manifest and therefore no identity

marcos: Should we mandate an identity in widgets? If a widget doesn't have an id, should it run? As it is now if it doesn't have an id it'll still run. <?>

PHB: If we're blurring the desktop and the Web and becoming more complacent, then that's bad.
... We don't want to treat the Web the way we have the desktop.
... How ever, I don't mind if we go the other way, where the controls from the Web come to the desktop.
... The desktop is also the accumulation of things we receive from external sources: be it a CD ROM or a download.
... So I'm fine to blur it if it means more rather than less.

smb: I agree, but I know when I put a CD in, vs a drive by download.

tlr: Where are we in terms of identification?
... Are we getting to a requirement for the widget specs to include additional ID?
... Something manifest based that is on a finer scale than an origin.

Lucas: You can view <something> as the wrong APIs in the wrong context, or the failure of the installation experience. There's not a requirement for a Web page to have a strong identity. I'm not sure why widgets <missed again>. Then we have to consider signing the manifest, which would be expensive as well.

marcos: we have the ID.

Lucas: But it's useless, just assume the ID of some popular widget and then they can't revoke it...

smb: You can always have a default with a minimal safe API. No ID necessary.

Lucas: Right. That's the basic Web-type sandbox.
... That's what sandboxes are for. Safe widgets would basically be Web pages.

Paddy: You can compare this with midlets that aren't signed by anyone, and run in a mediated environment.
... There's no reason, if you have a mediation that always occurs.

Lucas: That's going to have a impression on user experience.

<dom> [I think the premises of this workshop is "great powers come with great responsibilities" - we only need to put more requirements on content/developers if that content needs more power (and thus make incur more risk to their users)]

Lucas: In the Web model you still have some things that need to succeed.

tlr: There are different forms of identity that can hopefully be translated into a proper kind of framework.\

adrian: There is a level of trust, regardless of whether it's Web or widget, that determines which policy is invoked. It doesn't effect the framework at all.

API identity and naming

tlr: The declaration of intent probably seemed to be the common agreement.
... Web apps and perhaps widgets, that want to use extended APIs should find a way to declare their intent to use these APIs, and that should probably be declarative.
... But someone said in the Web apps case that you need to use an API to declare what APIs you use...
... Is there any disagreement with the need to start witing up a declarative model for Web apps and Widgets to declare their intent to use a certain extended API.
... Repeat: I heard there was almost total agreement that there should be a way for widgets (at the very least) to declare what APIs they're going to use.
... Does that extend to Web apps or is this a place where they should diverge?

dougt: We saw a setup where you had the list of features and a yes/no, we talked about who was supposed to manifest that... it seems like it'd be a good thing to have when we construct their run-time.
... When we construct it at runtime, then we could selectively add it based on manifest.
... In the Web you put the object in there, and you notify the user as expected <??>
... This is almost a P3P model for widgets.
... Minimizes the surface area of any potential attacks, but not sure how good it would be for the Web.

Claes: It'd be useful for Web applications to declare as well

The dialogs for when the Web application is invoked for the first time, but in a declaration you can confirm before use

smb: I think there's a lot of good reasons for having this on the Web as well. Yesterday I said about a high assurance declaration, but you've got a sandbox around this thing, that only exposes those interfaces and that's it...
... There are usability issues, but at least you have a concrete basis that it can do this and nothing else.

mark?: I'd agree with smb, that as well as giving the UA and the user this assurance of the sandbox, it also let's the developer define the constraints of the sandbox. Then as a developer, even if there is a case where my widget runs malicious code accidentally, then I know it'll still be safe.

tlr: This might map into deliverables. What APIs and how do you declare them? What concrete framework can we come up with for this declaration?

Nick: Can we reuse that same mechanism in the Web context as well.

Anil: As long as we give the UA enough flexibility to chose the user experience, then providing the building blocks is good.

<fjh> +1 to smb - using manifest to limit apis instantiated, thus those not in manifest cannot be used even in attack

Anil: Let the implementors decide how they are used.

<hendry> +1

Lucas: Is there consensus around the run-time must ensure that the application can only run the APIs that are declared.

Nick: Yes, otherwise it's the run-time with least privilege.

<hendry> to anil :)

??: there's nothing restricting the container from evaluating policies in run-time.

smb: But thenyou lose the interest of having a declarative manifest

tlr: You can look in the manifest in at least two ways. A convience for the run-time, and the other is a way to sandbox and protect the user against abuse

pauld: A good real example is FaceBook, having an application on FB ends up with every possible control being ticked and then people dare not tick those off because they want the app to work.
... what we saw in Caja is at run-time figuring out what it's doing, then look at the policy...
... If the policy isn't set up, then looking into metacrap up front... it just isn't going to work.

Paddy: There is a difference between static and dynamic situations here... In the widget case you see the declarations well-ahead of making the calls.
... If you're signing them, you can use that declaration as input to signing them.
... In the case of a Web app, that may be a case of fetching the doc and then fetching the declaration. It doesn't add any strength to download a second document. It's metacrap.
... There's no way to do this with the Nokia APIs... the permission check is made at the time. <??>

Fabio: We have two interpretations of intent, at worst I need all of these. If you declare this is all you need, then you might want to mandate sandboxes, but another interpretation is that "at least I need this much".

Anil: I think we're debating implementations.
... Who would be anti such a declarative set in the manifest?
... Implementors can figure out what to do with it... the manifest could be useful: 1. if my widget needs a camera then you can stop at install time. 2. security, if it's unsigned and declared up-front, the UA can do things.
... I think we should avoid implementation details.
... I'm sure BONDI will have best practices all around this, with differences for Web apps and widgets.

tlr: I agree, but I note that there are two use cases that Fabio pointed out that may be useful.

Lucas: Putting a bunch of privileges in the manifest is I think a UI problem.
... If you have a manifest, you can provide guidance at installation: "This app can steal your data!" or "This app can't really do much".
... If we don't do that ahead of time all we can do is a piecemeal approach, such as "This thing wants to use the network".
... I think we need a manifest like this in human readable format ahead of time.

smb: There are scenarios where A but not B is secure and B but not A is secure.
... Read top secret file, but write to a normal file for instance.
... From the security perspective it's a contract between implementor and the system, and the system will hold you to that.
... As a software engineer why shouldn't I declare?

tlr: I hear implemenation disagreements here.

Anil: In the Web app case, since things are a bit more dynamic, then there may be cases where the requirements change. How would we handle that with a declarative policy? In the widget case that's probably less of a problem.

tlr: That's an interesting and important question that will show up in the report.

Where should concrete APIs be addressed?

<pauld> in reality, Facebook apps ask for everything, in case they later need it

Nick: Where should the API work go?
... accepting the fact that we have multiple APIs, does there need to be consistency?
... A few drivers for that: 1. developers life simpler 2. security implementations might impose some things on API design. 3. discovery

dougt: The APIs you're talking about, the developer would be able to query which devices are present? What's the scope there?

Nick: The immediate one is "Is it there?"
... As an app developer, there's variants of a camera API and you want to find which one is there.

tlr: I think we heard this morning that concrete API proposals will be coming the way of the W3C. Where should we do this work.
... Are there design patterns, code requirements on device APIs, and how should that be reflected?

ArtB: we might want to be a bit careful about the meaning of device APIs.
... Geo is a device API in my mind. Are we putting requirements on that group?
... Are we putting requirements on the Web API work that's in the charter of WebApps? What is a device API?

tlr: Is there a concrete API that you're referring to?

ArtB: The WebIDL spec has some useful information.

tlr: Maybe there is no interest in this, other than a note in a workshop report.

ArtB: Who is going to do the work, what is the priority?

Nick: Specific example: multiple APIs with a shared security framework. What is the way that's done, and is it standardized? Standard exceptions/errors, etc. Should it go in the WebIDL spec, should it be...

marcos: It'd be good to have a WG Note that outlines the principals that we want in the Web APIs. Asynch APIs, extensible parameters, etc. Who would do that work? I don't know

tlr: I hear at this point that it's coming up in discussions.

marcos: OpenAJAX Alliance also wrote <something> and submitted it to <someone>, if they want to submit it as a Note that's a good idea.

<dom> Mobile Device APIs Style Guide from Open Ajax Alliance

Concrete APIs

Nick: Contacts, messaging, where do they fiit in current w3c scope? Which charter do they fit into?

tlr: What interest is there in diving into other APIs.

steve: Been working on a set of APIs for a while now. Working on them being NOT Nokia specific and getting them into the w3c.

Matt: That sounds like a reasonable thing to submit to stimulate further discussion.

ArtB: Submission to the appropriate WG or a Submission to the w3c.

Policy Description

tlr: Let's recall the use case that Paddy had in mind...

smb: Not going to define a policy language sitting here. Interacts with the naming of the API, think they have to be designed together. Some of the criteria specified, I think you want some semantics associated with the name for instance. Look at something and know how it relates to previous policies for instance.

Steven: Why does that interact with API naming?

smb: The manifest you're downloading will say: "I need to interact with the get location GPS thing or JPEG 2004 thing", and you say "What is that?!". You want it to be comprehensible.

Steven: You can name capabilites in a reasonable way, and map them to the actual things.

smb: You run into trouble with two names for the same thing, but yes...

Paddy: We have a framework, widgets can be given certain rights, and we have a language describing those things... any use case with exchanging policy... there were big differences, trust domains, or fine grained concerns, or what have you.
... Even if you don't want an interoperable way to do that, you ...

ArtB: I agree that we have all these different models so we need to step way up as far as I'm concerned. I think the use cases are where we need to begin. What are the requirements? Frederick has pointed out that there is prior art, etc.

Paddy: Wasn't saying use cases weren't important, just in <a narrow pllace>

pauld: I think if we can agree on something like: You say camera and I say camera and we mean the same thing.

fjh: I think policy language gets very complicated.

pauld: It's like a schema language. You start with a list and end up with a turing complete machine...

fjh: I'd argue it's actually quite difficult to develop a good policy framework

pauld: That problem is being solved in many ways... when I say "camera" but you talk about "optical device".. well, that doesn't work.

andre: Would you say this is linked to the development of <some> API.
... No matter who the provider is of the Geo API, as long as the interface fits with the specification, then the policy should have some way of saying that it fits with that specification.
... For any API you have that fits that specification, then your policy matches that as well.

Nick: You implicitly put constraints on the interface design. Any implementations should not have different security constraints around it.
... The contacts API for instance, one might have to go into the network to retrieve it which has some cost.

<fjh> policy language may be easy to write, but it might be harder in practice to compare policies for intersection or determine if policies are equivalent, or deal with cases of and/or/not etc. doing from scratch could be a larger project,

ArtB: Are we going to start building dependencies here?
... The manifest stuff right now is straight forward. From an architectural perspective, I'm concerned about dependencies.

tlr: I think we can do the policy framework conceptualization before we do the language and before we figure out differences between Web apps and widgets...

dom: Straw poll of standardizing in the policy framework domain? spending resources and time developing standards for that?

fjh: When you say policy framework, are you talking about access control policy or contracts or...?

tlr: The conceptual framework that may fit whatever you want. Who are the actors, what decisions may be made, e.g. origins, frameset, identity.
... If this summary doesn't make sense, please say it now...

ArtB: I think we lost some details. They are important.
... Are you skipping the use acase and requirements.
... I'm not sure what the question is anymore.

tlr: We have in the discussion that at the advanced level, fully fledged policy exchange frameworks. These frameworks make assumptions on what the framework and policies are, they make assumptions about identity and constraints...
... The minimum work item would be about articulating this, but shying away from the <identity?> and it would enable the ability of applications to work in a reasonably consistent environment.
... The framework for applications to speak relatively the same language.

Nick; Using these frameworks, I've established a trust relationship with my favorite app providers, I go to another operator, am I able to preserve those settings? that would imply an exchangable policy.

pauld: Even within browsers on the desktop, you can have a session, establish trust, move to another browser and not have that trust. Going across operators is rather ambitious.

tlr: Who is interested in expending resources and time to extend the policy mechanisms that Nick just described?

fjh: Where does this fit with the OASIS group?
... I'd help with that sort of thing, but I think we need materials to run by them.

<dom> hands raised from rep of Mozilla, OMTP, Vodafone, Marcos C Inc. :D; a maybe from Nokia

tlr: Who would be participating in such a group?

<hendry> aplix too dom

<dom> "yes" from Nokia

ArtB: Isn't the security context looking at UI considerations?

tlr: I saw shaking heads on UI considerations. what about policy management?

Nick: Policy is who can do what where and when, while management is being able to change those policies.

ArtB: Is policy management in scope for BONDI?

Nick: <??>

ArtB: You're making a clear distinction between policy and management?

Nick: We're trying to.

tlr: Coordination briefly.
... Break for 20, little more scoping on policy description, and then coordinatino needs, then go home.

And So We Enter The End Game

<pauld> scribe: pauld

tlr: more scoping the policy description and coordination cases
... Nick mentioned portability of policy in the broadest sense

fjh: wants to raise related work which has been done in XACML, the mechanism, and how to use the mechanism, which are we talking about?

steve: strict adherence to the current XACML shouldn't be a requirement, a subset seems to be desirable

fjh: yeah, you don't want the charter to preclude you doing something intelligent!
... you want to evaluate it and use it if it's suitable

steve: is XACML good enough for defining trust policies?

tlr: the second of the points, how to use whatever mechanism we come up with for expression is more interesting, not so much the expression mechanism itself
... are we on the same page, writing a policy which is actually about enforcement is important
... discovery in scope, or out of scope?

DKA: in scope, but not core. It's a supporting use-case

Lucas: out of scope only in so far as implementation, happy to define the format, but not how to do the discovery

<dom> reminder: "DCCI" is not an insult in most countries

dougt: this could descend into DCCI!

<dougt> sorry for the hate.

<dougt> it was my upbringing.

tlr: in discussing policy mechanisms, I'm hearing taking discovery into account is OK, but it mustn't drive things

Lucas: use-case, not core

marcos: policy can override a manifest

steve: I'm looking at the heading of the slide, we're talking about "discovery" but it's deeper than we're going

Paddy: it might be in scope, that's enough to say, no?

<dom> should we start qualifying things out of scope with RFC2119 keywords?

<dom> so that we can argue on "MAY" or "SHOULD" a bit longer

tlr: describes oriented landscape of PKOS, privacy and other communities, not currently doing normative work
... other points we should talk about?
... portability is important

steve: capability and permission semantics and evaluation algorithms important to me

art anything to say about the management piece?

tlr: not feeling energy in the room to discuss management, but if you have work, say now!

art is there consensus management is out of scope for the W3C

steve: doesn't seem to be a W3C thing

tlr: anything else out of scope?

steve: I put JavaScript sandboxing out of scope

dougt: you see that as an implementation detail?

steve: policy should be flexible enough to control the sandbox

tlr: work currently in HTML describing access policy for method invocation and attribute referencing
... HTML5 coordination is required
... method and attribute scoping seems out of scope, but availability or otherwise of methods to a sandbox - is that in scope?

steve: there is some possible overlap, e.g. inheritance of privilege to iframes

tlr: interaction with HTML5 DOM - SOP etc in scope.
... fundamentally different capability models - out of scope
... impact of SOP, framesets etc on device APIs - in scope
... enforcement of policies through hiding, security exceptions etc, - in scope

Adrian: is this tied to JavaScript, some manifest requirements, e.g enabling camera, may not require JS

tlr: *waves hands* we can craft appropriate text for that
... crafts list of Scoping on Slide
... no more features?
... coordination: we have PLING, XACML TC, HTML5, Webapps, geolocation, XML Security
... geopriv

DKA: Mobile Web Best Practices
... and BONDI?

Nick: it's implicit
... OpenAjax
... we've covered all the bases, except Policy Management (lost point in loud boat hooting)
... the devil is in the detail of course

tlr: the scope we're talking about is for something new, not something you can sneak into an existing WG
... Nick and I will come up with minutes and a workshop report
... will circulate them amongst the attendees before publishing, though the logs have been made public

<DKA> +1 thanks to Dom

tlr: formal thanks to Dom for pulling this workshop together, wouldn't have happened without you. Also many thanks to Vodafone and Daniel Applequist for hosting, thanks to Nick for co-chairing!


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/02/09 16:17:09 $