It may may be helpful for us to specify in some more detail the dynamic separation of duties use case we are trying to address.
For example:
1. Do we think we are trying to prevent the same individual from taking both of two actions related to some transaction (request and approve, for example)? Or do we have to account for more complex situations (prevent one actor from all of, say, four actions related to some transaction)? Or make sure each of three (or more) actions related to a transaction is take by one of three (or more) different actors?
2. Do we assume that all the actions in a transaction subject to DSD requirements are taken using the same resource (i.e., IT system) protected by one PDP and PEP? Or do we have to account for the possibility of separate systems (ordering, funds approval, receiving, etc.) being involved in a DSD transaction? (This would make keeping a "history" more complex.)
3. Can we identify some specific real-world examples of a DSD requirement (perhaps from banking, perhaps, or procurement, or 2-person review of a classified cross-domain data transfer.)
4. Do we have to account for "long-running transactions", so that we have to keep track of changes to access provisioning over long periods of time (to make sure access to one action is not provisioned, that action taken, then the first access de-provisioned, and access to the other action provisioned in time to allow the same actor/subject to execute both parts of the transaction.)
5. Is the concept of a "transaction" appropriate for all/most of the DSD use cases we want to address?
Also, could DSD be implemented by something as simple as this:
Given a two-action transaction T, with Action A and Action B required for completion, it is required that access to the control to cause action T-A cannot be given to any actor (subject, user . . ) who has access to the control to take action T-B.
So, pseudo-code for the implementing DSD rule:
If request is for access to resource T-A_control and Subject.Attribute_T-A = "Y" and Subject.Attribute_T-B not= "Y" then PERMIT; else DENY.
Obviously this assumes that the actor has been properly provisioned (doesn't have both Subject.Attribute_T-A and Subject.Attribute_T-B set to "Y".) This kicks responsibility for making sure no one has both attributes set to "Y" to the provisioning process and tools, which is probably where that responsibility best lies.