Hello,
an association would be possible too, but only to store the information for later evaluation / reporting when you have the node at hand. If you need to do some querying (find the policies user X has not yet accepted), then you have to go either property (with a "NOT user=X" fragment) or user preference ("NOT ID IN (ID1, ID2, …)"). You could build the last type of query with associations too, but handling all the existing associations and nodes via NodeService is way more expensive than just parsing the preference JSON string.
A problem you face with associations (and preferences too): If the user / person object is deleted somehow (may just be a temporary error in LDAP synchronization), all the information about the policies that the user accepted is lost, while using a property it is kept (and still valid when the user / person is re-created with the same user name). This was a major issue in a system I once maintained, where the customer was quite unhappy about the additional effort they had to invest to re-create all the associations from-to user / person objects when about a hundred of them were deleted due to a faulty LDAP / AD (rollback was not an option, since a thousand other users were happily working along).
Regards
Axel