Ralph, I thought about the "Role" as well. When we configure the behavior (assuming a condition provider), we do it based on roles. Shouldn't this take care of it already?

Hi Donald, no. As I already mentioned in my answer you can basically choose which role can update an attribute. So you can, as an example, specify which role can update the due date attribute.

The Due Date attribute can be configured for many work item types. There is no way to specify which role can modify the attribute for a work item type. A role that can change it for one type can change it for any type.

What you could do, is to specify different attributes for each type, where you need that. E.g. you could define an attribute due_date_task and one due_date_defect and one due_date_story. You can then set dedicated permissions for the attributes and the roles and distinguish the work item types impacted by choosing where to use which attribute. 

I was thinking about the operation behavior, not permission - precisely, the Read-Only Attributes For Condition precondition.

You don't have access to the role information with JavaScript. See https://rsjazz.wordpress.com/2016/07/15/rtc-process-customization-what-you-can-and-cannot-do/ .

You can use Java with the caveats e.g. need to deploy. Here an example:
https://rsjazz.wordpress.com/2015/08/07/a-custom-condition-to-make-attributes-required-or-read-only-by-role-version-2/