As with similar browser plug-ins, Silverlight applications are not allowed to communicate with 3rd-party domains by default.  That is, an app loaded from http://fabrikam.com cannot make web requests to http://contoso.com.  Contoso can declaratively enable this scenario by publishing a cross-domain policy file—generally either a CrossDomain.xml or ClientAccessPolicy.xml file served at the root of the domain.

Why is this necessary?  Couldn’t the Fabrikam application just run a proxy on fabrikam.com that sends requests to contoso.com on behalf of the client?

There are a few specific reasons allowing cross-domain connections from the client is bad:

1. Cookies.  If an HTTP request is made from the browser to contoso.com, this would carry along with it all the user’s cookies for contoso.com.  If the user has an active session cookie with contoso, the server will trust this request as being part of a legitimate session.
2. HTTP Authentication.  A user may be authenticated to contoso via HTTP auth.  Again, this traffic will be sent in the context of the authenticated user – something the Fabrikam server would not be able to do on its own.
3. Physical topology.  The client may simply have access to network nodes the attacker does not.  For example, many consumer routers have web interfaces that are only accessible from within the LAN.  Or, an attacker may be able to talk to other machines on the user’s company’s network – machines the attacker would normally be prevented from communicating with (because of firewalls, NATs, etc)
4. Repudiation.  If Fabrikam attacks Contoso directly, Contoso can tell where those requests are coming from (by looking at the TCP/IP headers).  By using the user as an intermediary, Fabrikam can make it much harder to tell where the attack is coming from.  Ideally a server could check the referer header to see who’s really behind the request, but the referer header isn’t always sent reliably.

There may be more reasons, but these are very good ones themselves.