I think that 3. Security considerations needs some more contents. I have added some suggested additions around <<...>> markers below: [...] This section describes some additional considerations that have to do with the networked nature of a RESTful architecture<<, together with the administrative capabilities setout by this profile>> 3.2 Authentication HTTP status code 401 (Unauthorized) [HTTP] MAY be used to indicate that an operation on a resource is denied because the <<requestor>> is not authenticated Note: replaced user by requestor because the profile is likely to be used by non-human users as well Authentication means: You can mention Digest authentication, but then other mechanisms should be mentioned as well, in a non normative way. Example: federated authentication via SAML token 3.3 Authorization I suggest to add something along the lines: <<Implementations can perform authorization based upon the identity of the requestor, as well as on any appropriate additional, trusted, attribute>> (hence the importance of mentioning federation above) "This specification RECOMMENDS that authorization be implemented using XACML" is a correct statement but still is too vague. I suggest that you have a specific section on constrained delegation that the implementations must support, in order to authorize appropriate administrative actions (such as: delete all versions of a policy set, to your example). The REST profile does not need to mandate constrained delegation, but this model IMO should be recommended on all PAP actions I hope that this makes sense. Thanks, Jean-Paul Buu-Sao, TSCP