Re: Discussion regarding policy framework choices

Dom

I have some concerns with the approach you mention.

First, WARP is very simple dealing with network access in aggregate, does not have the granularity of access control as does XACML. Thus I'm concerned that the path you suggest will result in a re-invention of XACML. At the same time, I agree with simplicity and suspect we do not need all the power of XACML so might want a simpler profile of it.

Second, going method by method in all APIs could take a long time, especially if we attempt to research every possible effort being done. I am all for re-use, which is why I'd rather hear an argument why the XACML work is not appropriate.  Are you willing to demonstrate the approach you suggest, with for example, the geo-location specification?

I also do not understand why we cannot use a variant of the XACML standard (either 2.0 or hopefully soon 3.0) rather than a variant.

Finally, I think the framework specification could use some work to make it clearer - there is actually a lot there but the presentation does not make it as clear as it  could be.

I guess I'm questioning the approach of starting from the beginning, given that we have contributions that reflect existing work on the topic.

regards, Frederick

Frederick Hirsch
Nokia



On Jun 23, 2010, at 8:29 AM, ext Dominique Hazael-Massieux wrote:

> Le mardi 22 juin 2010 à 23:15 +0200, Frederick.Hirsch@nokia.com a
> écrit :
>> I think we need to have a discussion regarding the choice of policy framework for standardization.
>> 
>> So far I've seen four options in the working group
>> 
>> 1) Simple markup with clear separation of trust from decision
>> 2) Profile of XACML 2.0
>> 3) New markup as submitted by BONDI, similar to  XACML 2.0 but different in schema and processing rules 
>> 4) No policy language at all.
> 
> My personal preference based on the recent discussions would be to delay
> the work on the format for policy interchange, until we have a better
> sense of an actual policy model.
> 
> In practice, I think it would be useful to start with cataloging
> existing in-browser JavaScript APIs that are restricted (which would be
> a necessary step in any case for the “api-feature” stuff of the policy
> format), with a description of these restrictions, and some leads as to
> how these restrictions would need to be removed in a privileged
> environment. It might be removing a prompt, it might be making new
> constructors or factories methods available, it might be removing
> same-origin restrictions, etc.
> 
> Based on that analysis, we could look at incorporating our findings in a
> revision of the WARP spec to include more fine-grained declarations of
> features/parameters, possibly seeking alignments with other similar
> efforts (Firefox Jetpack extensions, Chrome extensions, Android
> manifest, etc). I think such an effort could in fact also be useful for
> purely Web-based applications, to facilitate the building of user
> interfaces for dealing with set of permissions.
> 
> And once we all that well identified, I think we might then be in a
> position to work on a policy interchange format, should that appear to
> be useful.
> 
> Dom
>

Received on Wednesday, 7 July 2010 13:42:03 UTC