Support Column/Field Level Access Restrictions
Currently WCF supports access restrictions at the entity level using entity set access rights (and something similar for service operations). It also supports, through query interceptors, the ability to filter rows on a per-request basis. It does not, however, support access restrictions on a per-field basis. It is also quite difficult to add support for this. The only workarounds are non-trivial, especially if you're using entity framework as your provider because WCF custom generates query Expressions specifically for entity framework's IQueryable implementation, differently from custom providers or the reflection provider.
So far, the only workarounds that appear to be feasible are to create custom metadata on a per-user basis. This has performance implications. The other option is to re-parse the query for each request, and throw an exception if the query references properties in the model that the current user is not allowed to access.
I would like the second option - the ability to return an error response when a query would have otherwise referenced a property (either explicitly, via a $select, $orderby, $filter, or $expand query option, or implicitly by accessing a collection or single item without explicitly $selecting fields the user has access to. These restrictions would be evaluated when the request is parsed (including requests contained in a batch request) but before the request is submitted to the server.
Also, I would like to add a second layer of field-level access restrictions - row-specific column restrictions. Example: User A has access to the SSN column for THEIR User record, but not someone ELSE's User record. These restrictions would be applied in a query interceptor after the original query was submitted to the provider and the result was returned. In order to implement this, you could either have a black box of "check that the query that returned this result didn't reference these fields", or else pass the original query to the query interceptor so that it can process it itself (preferably the query should be in the form of an ODataContrib odata query node tree, and not a .net Expression, as the former is far easier to visit than the latter.