First, let's be clear that OAuth and OpenID are two separate things. OpenID is intended for authentication only. OAuth is intended for authentication and authorization. In this case, authorization refers to the idea that a client application is authorized to access and update data associated with an authenticated user.
What I need to do is let the third party websites login to a user's account on the website, but only read and write data that belongs to them and not be able to touch data that belong to other third party websites?
If the data that is stored on each of the third party websites is mutually exclusive of the data stored on your authentication server, then you may want to stick with OpenID.
If, however, you want your third party websites to update information about the user that should be shared with all the other third party websites (i.e. First name, Last name, Street address, Credit Card Information, etc.), then you may want to go with OAuth. I am aware that there is an extension to the OpenID spec that allows for this sort of thing (and indeed, you can adapt this to your own implementation), but in the general sense, this sort of stuff belongs in OAuth.
I'm a bit fuzzy of the details of
oAuth. Do I need to create some sort
of an API or is oAuth the only thing I
need to implement?
Beyond the initial details of requesting tokens and authorizing the client application with the OAuth server, you would have to implement additional methods to retrieve and update information about the authenticated user. For example, Twitter requires your application to be authenticated with a particular user and authorized to update the user's status. That update status method is a part of their API in addition to the base OAuth implementation.
If I implement oAuth, will other third
party websites be able to access data
from the website? Does anyone think
this is a bad idea? yes/no and why?
Those websites will only be allowed to access the data of the user who has authenticated with your OAuth server and authorized that website to access their data. However, only those websites with a valid Consumer Key can request the proper tokens to begin an OAuth session. So only those websites that you have authorized will be allowed to interact with your server.
There is always the chance that those tokens can be hijacked through Session Fixation. But that concern should not prevent you from implementing your OAuth service. That doesn't mean don't worry about it. Just don't let that be a roadblock.
Can I let other third party websites register the user to the main website without the user having to visit the main website?
Not with the current spec as defined by OAuth. The idea behind OAuth is that your users register at the OAuth server. Your third party clients use this server as an authentication point. This doesn't mean you can't, however, implement some sort of API to register a user if the application has some sort of "master" account to log in with (though this is it's own security risk). It's just not recommended.
and how does oAuth help me make sure that a third party websites does not read/write/change user data related to another third party website?
Just because you use OAuth doesn't mean that your third party websites can't store data in their own data stores. Both Flickr and Twitter offer OAuth services, but neither store each other's information on their servers (no flickr photos get stored in Twitter's databases).
As long as you aren't storing the information specific to each application on your OAuth server, you shouldn't have a problem. Remember, the OAuth server is there to authenticate users and store the basic information that should be shared by ALL applications. I'll reiterate here, if all you want to do is authenticate the user, then stick with OpenID.
Edit
Can I segment the permissions such that when the user authorizes site A, he doesn't authorize it to his full account, but just authorizes it to access its own data on his account? Can oAuth do this?
In your implementation, you can. It would be a matter of checking consumer key associated with the access token being used to access that OAuth Endpoint. Remember that each call to the authorized portion of your API must include an access token. So it makes sense that if you want to lock down that endpoint to a particular application you would check it by access token and consumer key.