Re: CfC: Policy Profile: XACML FPWD

Le mercredi 09 juin 2010 à 17:07 +0200, Robin Berjon a écrit :
> The draft can be read at:
> 
>   http://dev.w3.org/2009/dap/policy/Profile.html

Some comments on the draft — I'm not sure if they should be considered
as blocking for publication as FWPD; some of them are quite important, I
think (prefixed with **); my feeling is that most readers would be
entirely lost when trying to read that document and understand how and
if it apply to something relevant to them.

* I think the title needs to be changed at least to "XACML Profile for
Device APIs Policy" (rather than "Device API Policy Profile: XACML"),
but an entirely different title might be in order

* the abstract needs a better explanation than "a policy framework for
device APIs"

** the document is called a XACML profile, is said to use XACML20, but
there is absolutely no explanation as to what this means in practice,
what are the difference with XACML 2.0 or how it relies on it; I guess
some text from the framework could be moved to it or re-used, but I
think some more explanation on the relationship would be needed in any
case

* the start of the document is very abrupt, with very little context to
understand e.g. 2.1. "Values and Types"

* the definition of the syntax for encoding certificate fingerprints
isn't linked with anything, and the words "certificate" and
"fingerprint" don't appear anywhere else in the document

* the intro talks about the status of the document ("This document is an
editors draft...") — that should be removed

* there should be (presumably) cross-references to the Framework
document

** having examples would help making the document readable

* 2.3 "subject match" seems like a subset of "2.2 attribute match", and
as such should probably be a sub-section of it; also, it's not clear why
"subject match" need its own section when "resource match" and
"environment match" don't

* 2.11 "Signed Policy Document" is so vague about what a signed policy
is that it's pretty much useless

* The functions defined in 2.12 don't have actual names attached to
their definitions; they seem to be defined as "equal", "glob", "regexp"
in 3.1.8, but it seems it would be useful to add their names along with
their definitions

* in 2.12.1, "Thus an empty bag is not equal to anything" — the logical
connection of the "thus" is not entirely obvious to me

* defining the names of the modifier functions defined in 2.13 would be
useful

* the conversion from string to URI should probably mention
normalization/canonicalization considerations

* a normative reference for the URI components to the URI RFC would be
seem to be in order

* in 2.13.3, "Each URI in the bag is converted to a string by taking the
URI’s scheme and authority components" - should this be "converted to a
string bag"? if not, it's not clear to me how the two strings are
supposed to concatenated

** the effects defined in 2.15 assume that prompts are the end game of
the policy framework, when most of our work in APIs has been to avoid
these prompts; does this means that the policy framework will only be
used for APIs calls that would actually require prompts?

* the definition of session, both for widgets and Web sites, seem rather
brittle; the definition of sessions for Web sites should probably be
aligned with the one in sessionStorage
http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute

* 3.1 "schema" would be usefully completed with an actual schema (XML
Schema or RelaxNG)

* 3.1 doesn't give any guidance on how an implementation would deal with
documents that don't follow some of the rules defined in the schema

** the document doesn't have a conformance section, so it's really
unclear what kind of tools and products are expected to conform to that
spec, if there are several level of conformance, etc

** I'm concerned about the risk that this part of the work find willing
implementers — interchange of declarative policy decisions doesn't seem
to be widely asked for at this time, and most similar projects seem to
focus purely on a manifest approach, leaving policy decision to another
layer. I'm raising this now since this clearly informs the discussion on
whether the scope of the document is appropriate or not; I would at
least suggest calling this out in the SOTD or/and in an issue in the
document.

Dom

Received on Tuesday, 15 June 2010 12:43:07 UTC