- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 15 Sep 2010 14:53:22 +0200
- To: Frederick.Hirsch@nokia.com
- Cc: public-device-apis@w3.org
Le mercredi 15 septembre 2010 à 00:32 +0200, Frederick.Hirsch@nokia.com > Thus the architecture simplifies to the following: > > 1. Identified APIs (or all APIs) > 2. trust domains > 3. capabilities allowed for each trust domain, either across all APIs or on a per-API basis I’m not convinced that we even need (3) at this point; I’m not quite sure what this would buy us, especially as I don’t think any browser currently deployed use that sub-level framework, and that W3C Widgets don’t refer to them either. > This corresponds to the Nokia contribution. Looking at Nokia’s security framework for widget runtime engines: http://wiki.forum.nokia.com/index.php/Widget_Platform_Security it looks like the capabilities are very coarse (e.g. lumping together any kind of “user data”), which wouldn’t match what we have currently defined in our APIs, and would in fact go against our minimalization approach. I think that this defect is likely to happen for any sub-API granularity (which I understand capabilities are). > So, I'm ok with the simplification of not referring to features and > focusing on trust domains + capabilities + API naming (method + class > name I assume). > > I'd be interested whether Paddy and Laura agree. > > It would be great in my opinion if you can take another pass. I’ll take a stab it (hopefully this week), but be warned that capabilities may be a casualty in that process :) Dom
Received on Wednesday, 15 September 2010 12:53:35 UTC