See also: IRC log
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
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
See also: Position paper; slides
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 ]]
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
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
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.
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.
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
lunch
<matt> scribe:Matt
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.
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.
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.
<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
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.
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.
<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!
ADJOURNED