In .NET 3.5, WCF allows only a limited set of scenarios to execute in partial trust. It allows only the BasicHttpBinding, the WSHttpBinding, and the WebHttpBinding (with the notable exclusion of the WSDualHttpBinding) to be called under partial trust, and only with either no transfer security at all or Transport security. Furthermore, in the case of the WSHttpBinding, aspects such as Message security, reliable messaging, and transactions are disallowed. All partial-trust-enabled bindings must use text encoding. A WCF service (or client) running under partial trust cannot use additional WCF facilities, such as diagnostics and performance counters. To enable usage in a partially trusted environment, the System.ServiceModel assembly allows for partial trust callers by including the AllowPartiallyTrustedCallers attribute as part of the assembly definition:

[assembly: AllowPartiallyTrustedCallers]

In the first release of WCF, omitting this attribute precluded all partial trust use. In .NET 3.5, enforcing the limited set of supported features is now the responsibility of the bindings. Each non-HTTP binding actively demands full trust of its caller, be it the client proxy or the service host. The allowed HTTP bindings themselves do not demand full trust, but instead demand permissions according to the context of use. On the client side, the allowed HTTP bindings demand permission to execute (security permission with execution flag) and permission to connect to the service (web permission with connect flag to the target URI). On the host side, the allowed HTTP bindings demand the permissions listed in Table D-1.

The allowed HTTP bindings all demand permission to execute and permission to modify the infrastructure (security permission with infrastructure flag), and permission to accept calls on the URI configured for their endpoint (web permission with accept flag to the URI). When the calls are authenticated, the allowed HTTP bindings also demand permission to control the thread principal (security permission with principal control flag) because after authentication, for the duration of the call and regardless of the binding, WCF will install a new principal with an identity matching the provided client's credentials. If the service type provided to the host constructor is defined as an internal type of another assembly, the host also demands unrestricted reflection permission to be able to load that type using reflection.

Beyond these demands on the client or the host, there are additional limitations on configuration. For example, the config file cannot contain any reference to any certificate store (for service-side or client-side certificate credentials), since touching the certificate store will cause WCF to demand full trust. Administrators have to configure these certificates separately, using tools such as HttpConfig.exe.

A problem with basing the host-side permissions demand solely on the binding is that the hosted service instance is implicitly given these permissions, even if it does not require them to function. For example, the service instance could control the principal or reflect the internal types of other assemblies on the host machine. It would have been better to design the bindings to demand their permissions and yet somehow provide the host with a way of granting different permissions to the service, while ensuring that the service permissions were a subset of the hosting code's permissions.

Clearly, .NET 3.5's support falls short of comprehensive code-access security support for WCF. Ideally, you would like to be able to tap into the full power of WCF, from distributed transactions, to reliable calls, to various security credential types, to intranet (or even same-machine) applications with the TCP and IPC bindings, not to mention duplex callbacks, asynchronous calls, diagnostics and tracing, instrumentation, and of course queued calls over MSMQ, and do all that without compromising on code-access security (that is, resorting to full trust). There are three distinct areas where such support is required: partially trusted clients, partially trusted services, and partially trusted hosts.