W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2010

Re: Discussion regarding policy framework choices

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 07 Jul 2010 15:58:13 +0200
To: Frederick.Hirsch@nokia.com
Cc: public-device-apis@w3.org
Message-ID: <1278511093.7409.838.camel@localhost>
Le mercredi 07 juillet 2010 à 15:40 +0200, Frederick.Hirsch@nokia.com a
écrit :
> First, WARP is very simple dealing with network access in aggregate,
> does not have the granularity of access control as does XACML.

At it stands, indeed, but it could be extended for more granular access.

But I think comparing the current framework with WARP is like comparing
apples and oranges (or Apple and Orange, for that matter): WARP is
addressing self-declaration from content authors, when the proposed
policy framework is addressing regulation of access to APIs from
(mostly) operators, handsets manufacturers and possibly third-party

Thus my point was to first look at what are the limitations that content
authors would like to see lifted from the Web APIs environment (which is
what WARP roughly addresses today), before looking at how to have
operators and others exchange policies on whether to allow for these
restrictions to be lifted (which is what the policy framework

> 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 think looking at 4 or 5 of the most relevant APIs would probably give
us a pretty good starting point; in any case, I'm not sure we can
address the framework's goals without looking into this question at some

>  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'm not sure taking one spec in isolation will bring a very useful
perspective on what I mean, but I guess I could start with a couple of
APIs to make it clearer, indeed. I'll try to get to that before the F2F.

> 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.

I think XACML is extremely bloated for what we want, and doesn't provide
a profiling mechanism, which to me points toward creating a new language
for the policy framework (but which again is a separate topic from what
I was suggesting). The main reason to stick with XACML would be to rely
on the existing implementations and frameworks that have been built
around it, and see whether they would be beneficial in our environment —
my early investigations on this weren't very positive.

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

To be clear: I think what I'm proposing is to clarify the points on
which the policy framework would apply, and modify the framework
accordingly; it may be that much of the current framework would be
re-usable after that analysis.

Received on Wednesday, 7 July 2010 13:58:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:45 UTC