Can oracle implementations like Oraclize and Reality Keys work with two different blockchains? More precisely, if I have a custom data source and my own oracle running on top of it, can that oracle determine the source of the API call and send data accordingly? Can I design a permission layer in this oracle to allow/deny API calls from a specific address?
As for Oraclize, you can potentially use it with any blockchain.
What Oraclize provides is a native integration with public blockchains (i.e.: Ethereum mainnet, Ethereum morden testnet, Bitcoin mainnet) and an HTTP API you can use to connect the Oraclize engine to any other blockchain (for example by using the Ethereum-bridge tool you can connect the engine to your private Ethereum testnet/Eris/etc).
Being this approach so flexible, it enables different blockchain to speak to each other by using Oraclize as a connector.
A datasource is the data provider: if you want to use your own web service as a datasource, you can implement there whatever logic you want - Oraclize is just abstracting the connection to the datasource so that it can be blockchain agnostic.
That said, this is all about transparency and auditability, so there is not effective way to restrict the visibility of data to some blockchains only (unless you are willing to lose the oracle abstraction layer part).
If what you want to achieve is having your own web service being able to answer just to queries coming from "authorized contracts" (let's say for example you want to allow using it on ETH but not on ETC), you can do that via Oraclize encrypted queries thanks to one of its features: a given encrypted string is binded to one contract only - which is the first one using it.
So let's say you want a given query Q, when you encrypt it you will have ENC1(Q), ENC2(Q), ENC3(Q) and so on.. every time you encrypt it, the encrypted string will be different.
If you deploy a contract using ENC1(Q) via oraclize_query, it will just work and the decrypted query will be visible to Oraclize - which will send your contract back the answer.
If another contract (on the same chain.. or on a different one!) then tries to use ENC1(Q), Oraclize will prevent the query to the datasource to succeed as the only contract allowed to use ENC1(Q) is just the first one who used it. Q is known to you and Oraclize only, enabling your datasource logic to work under some given circumstances only.
This feature was designed to use private api credentials as queries on public blockchains, but of course it enables many other useful applications to come to life: for example your chain-specific whitelisting feature or other interesting scenarios (a bit OT here).
Thomas Bertani - Oraclize
Edmund Edgar from Reality Keys here.
The way we work is by signing data and publishing it publicly off-chain. You then send it in a transaction to your blockchain yourself. This means that we don't need to interact with your blockchain, or even know that it exists. The same data will be usable on any blockchain that knows how to check the signature.
If you want to send different data to the different blockchains, you would put whatever is different in the definition of that event, and treat them as two different events.
If these are public blockchains and you're hoping to keep the data secret from users of the other chain, you're probably out of luck: Once you send data to a public blockchain, anyone can see what it is.