Hi Caleb, I am not sure that I fully get the point about your proposal. If I understand it well, you want to allow users with PR to save document content without giving them PR. I agree this could have some benefit, but this is not really a full cure for existing issues. BTW, this is not really the list for discussing security matters in details, may I remind you that we have security(a)xwiki.org for that particular purpose. So I will avoid those details in my reply. At the moment, I do not see the benefit of using a bit for the purpose. I am pretty sure that XObject could be used as well, with the advantage of not introducing any new needs in the data model. Maybe we could even reuse the current RequiredRightClass for the purpose. For example, we only provide PR when PR is required by that XObject, and on save, we delete such object or warn/request confirmation to keep them as appropriate when the content author change the state of PR. This is quite easy to introduce, and have some benefit, but it is far from solving the numerous issue we have with PR, in particular when using sheets, or advanced rendering techniques. Caching the PR state has no benefit, since the security cache already does so. On the more general aspect about the state of security of XWiki, it has been admitted so far, that exploit by user with Edit right is not considered so harmful and a priority. If we decide now that the priority of such exploit is more critical, and I had always been part of those who are paranoid about security, so I am +1 for that, we need to put the security aspect higher in our roadmap, and some of the actual committers to concentrate on that aspect. As you know, I have fully reviewed the Crypto API, and managing signed scripts in XWiki is now technically speaking, just next door. The reason we still have not them is mainly about because the introduction of this feature is a major change, and so far, I have not been able to drive enough attention to it, so to receive feedback and create brainstorming on how we'd like signed script to behave. By itself, signed scripts will provide script integrity and trustable authorship, but we still have to define how we allow script to receive privilege like PR based on the signer(s). Basically, how we manage the web of trust by certifying signers. So far, appart of a fully integrated API, I have written, I hope, an in depth design document ( http://design.xwiki.org/xwiki/bin/view/Design/SignedScripts), which try to reflect all my thoughts about the subject. I understand that it could be frightening to those that are not knowledgable in cryptography, but I have done my best to make it as accessible as possible. What is annoying, is that I haven't received much feedback about the subject. Until now, brainstorming on the subject as not be insightful enough to overcome my paranoia, which is to not introduce solutions that will reveal to be either too complex, flawed to the point that fixing them introduce breakage, or even worse new and potentially definitive security flaw. I am convinced that designing signed scripts could not be a single person decision, and that we need a team to properly define the behavior. This is why I have written the generic technical tools, and that I would be pleased to help and pursue this goal, but I do not want to do it alone. Edy has recently show some interests on the subject, and I am sure that together, we could progress to some solution, but it gets us back to the priorities. So the question for me is: do we now consider that users with edit right is a potential threat, and if so, do we want to push again to get signed script done ? Sorry for the long mail, Thanks, On Mon, Aug 31, 2015 at 5:27 PM, Guillaume "Louis-Marie" Delhumeau < gdelhumeau(a)xwiki.com&gt; wrote: -- Denis Gervalle SOFTEC sa - CEO