Basically, you want to run the business logic on a client. This may be dangerous, but sometimes it's inevitable — people want to have nice dynamic reactive UI. Be aware of the following issues:
Some business logic may slip into front-end and stay there. Consequences may range from inconsistent UI to dangerous security holes.
Code duplication may cause discrepancy between back-end and front-end. If you are lucky to use same language on both sides, this problem can be partially mitigated — still, there will be cases when front-end does not have all required information.
This may leak security-related implementation details and other users' data. Helping potential attacker is not a good idea.
Sending plain roles/permissions will cause maximum coupling. It makes more sense to send sets of flags that describe availability of operations: "CanEditOrder", "CanDeleteOrder". Just remember that if you're doing any validation on client-side, you have to to repeat it in the back-end.
(As a side note, there is one trick I found when developing CRM/ERP with lots of complex rules. Put a button somewhere, that may be activated by IT or advanced users. It calls back-end to run all possible validations in current component and return resulting errors to display in a dialog. Solves lots of "why can't I do that?".)