ACTION-76: Review and comment the WG Access Control draft at http://www.w3.org/2012/ldp/wiki/AccessControl

* The introduction (section 2) could be extended with the contents of section 3.7 (use case “Identification, Authentication, and Authorization”) as I don’t really see this latter section as a proper use case, but more like a motivational discussion –scope?— and clarifies the questions that the note should (try to) address.

* I would rewrite the first paragraph of section 3.1 using an impersonal style, as it suits better this type of document.

* The example included in section 3.3 (use “Setting Access Control Policies for a Resource or set of resources”) is a little bit complicated: the first POST creates a LDPR that happens to be of an special type (sioc:Account) that also exhibits LDPC semantics (behavior), and then this resource is used as entry point for creating further resources whose access can be later controlled. I would rather start by clarifying the needs for defining ACPs for any kind of LDPR (regardless it is a container or not), and then discuss the specificities on ACPs for LDPCs and ACPs for the members of LDPCs. I think this would clarify the scenario and maybe rise further requirements that may not be clear according to the example included.

* The motivation of the use case defined in section 3.4 is clear enough and demonstrates the need for the ACP discovery mechanism. However, the last sentence may make the reader wonder if such mechanism is only useful for debugging purposes. It might be worthy to point out another scenario where the functionality is beneficial (i.e., one that shows that the functionality is a key interoperability enabler).
Also, are there any security drawbacks derived from this functionality, any reason that would discourage the provision of such discovery mechanism?

* I would rewrite section 3.6 as follows:
A bug database exists for some product. A user wishes to create a new bug report on a security issue ( by POSTing it to a collection ). However, as by default bug reports are publicly readable, the user wants to make sure it has limited visibility to give the software vendor time to fix it. The usual two-step process of creating first the resource and then changing the access control permissions is not enough for enforcing the user needs, as there is a delay between the creation and the permission setup that makes the created resource publicly available. Therefore, in this situation there is a need for defining the access control policy at resource creation time.

* In section 4 I miss requirements on the authentication side (which underlies the identified use cases) and access control models.

* I would move section 4.2 to section 5, as it does not make sense to introduce technology to requirements traceability matrix before presenting the technologies.

* Regardless I am not an expert on the matter, in section 5 I miss descriptions of several popular technologies that are relevant to the topic such as OAuth, SAML/ID-FF, XACML.