Pretty much your only option are NXP chips such as the PN531 (old), PN532, and PN544. The PN544 is the one in Samsung's Nexus S phone.
Most NFC cards these days are MiFare-base and since NXP owns the MiFare IP (and doesn't license it to anyone else) their chips are pretty much the only ones around.
I'm working with the PN532 myself and it's not bad. You can talk to it via UART, I2C, or SPI. They're not that cheap (considering the monopoly) but aren't crazily priced either.
Whenever she gets it back in stock, I'd recommend starting with Adafruit's PN532 breakout board http://www.adafruit.com/products/364 and have a look at the PN532's user manual and datasheet in the meantime.
As for communication with smartphones, that'll involve the Peer-to-peer communication mode of NFC. But if all you want is to pass static content, just get a bunch of MiFare tags from Alibaba or something; they won't be more than $0.70 depending on size and form factor. They are blank and can be programmed (and locked) via a cheap USB NFC transceiver. For that I'd recommend the SCM SCL3711.
Good luck!
If you read the datasheet, it gives information on the typical and maximum current consumption for the IC. It also gives power down consumption and other details. I'd also check the other documentation (app notes, etc) to see if there is more information/advice on power characteristics.
On page 3 note 7, it says typical current consumption is below 100mA. 60mA is given as the typical consumption for the transmitter supply, digital and analog ~7mA each, and the pin supply up to 40mA. With this info you can get a pretty good idea of what capacity battery you need for 10 hours operation.
Assuming maximum consumption, and less than 100% efficiency (e.g. regulator used) we can do some calculations. We'll assume 80% efficiency and 100mA continuous draw:
100mA * 10h * (1/0.8) = 1250mAh
This is probably very, very conservative, but gives you a figure which will certainly be plenty. However the only way to get very accurate figures is to run some tests yourself, since consumption will depend on how many IO pins you are using, other circuit activity, regulator efficiency, temperature, etc, etc.
I would probably look at using a 3.7V Li-Ion cell, since it's a good voltage, they are conveniently sized and there are plenty of options around 1000mAh (eBay, Sparkfun, Digikey, etc) There are also cheap charging ICs available (Microchip do some good ones) Of course it's up to you, anything that provides the required capacity would work, but you have to consider what is most suitable for your project (size, weight, cost, etc)
Best Answer
The short answer is "no". The NFC ring will not contain the application-specific cryptographic keys required by Oyster.
NFC "rings", like other NFC-capable contactless payment tokens, contain a tamper-resistant microprocessor with cryptographic acceleration and a small amount of secure memory storage. These chips and associated induction antenna coil are together referred to as "tags", "smart cards", or "secure elements", regardless of the physical form factor of the surrounding plastic package (e.g. card, key chain dongle, ring, watchband).
Among the secrets stored inside the chip are symmetric cryptographic keys used to encrypt the observable traffic between the chip in the card and the turnstile reader. Without this secret key, any data you might place in your key ring, even if in exactly the right application format, would nevertheless have the wrong authentication key. The turnstile will not succeed in authenticating your key ring and will not be able to read the memory contents.
During manufacturing of the chips (during wafer-sort and test phase), the devices are automatically tested before the wafer is sawn into dice. During this testing step, the initial contents of the secure memory can be programmed according to the needs of high-volume customers. The chips are then sawn and delivered (securely) to a separate factory that produces the "inlays" (the combination of antenna coil, chip, encased in suitable packaging of plastic, plasticized paper, mylar, fluffy toy, rubber wristband, etc...)
The Oyster card uses MIFARE Classic or MIFARE Plus chips from NXP Semiconductor (MIFARE Classic family). MIFARE Plus works the same as MIFARE Classic but uses AES encryption rather than NXP proprietary encryption used in Classic. Newer applications use ISO/IEC 14443-4 standardized application cards (like payment cards from V/M/Amex, and NXP offers a proprietary extension of these called DESFire for transit agency issued cards).
The Oyster MIFARE cards are programmed at the factory (or by the system operator from blank devices) and are activated upon enrollment to the system. The readers at the turnstiles and behind the glass window or in the fare adjustment machines all have matching chipsets called "SAM" (Secure Access modules) with matching secret keys stored in their own secure memory. The reader uses the SAM to generate and validate challenge-response codes and to deduct or top-up fare balances or redeem one-time tickets.
The keys required by each application are generated in the factory and programmed as described above. Alternatively, blank cards can be programmed with "transport keys" that are not secret and enable anyone to use the chip. Your NFC key ring comes that way. Once you key the chip, you can change the two keys to whatever you want them to be and program your application settings into the chip. However, you will have no way of replicating the unique keys required by Oyster: Even if you were to discover the keys in the Oyster card, they would be the wrong keys for your NFC keyring which has a separate and unchangeable UID. The keys in each card are unique to that card, derived from the card serial number and encrypted according to an application diversification rule and master key set (AN10922—Symmetric Key Diversification). So even brute force cracking one card to discover its keys will not enable you to crack any others.
In the case of MIFARE the application platform two keys are needed. The Key A and the Key B. Key B can be thought of as the "admin" key--used to top-up change keys, replace otherwise read-only data. The Key A is the key used by the turnstiles to challenge the card. The MIFARE application in the card supports only a limited set of primitive operations and so the SAM must interrogate and update the card according to Oyster-defined logic after authenticating to the card using one of the two secret keys.
There is nothing different about an Oyster card electrically from any other MIFARE device. If TfL chose to, they could provision their application to any randomly presented MIFARE device of appropriate memory size, after first erasing it. The problem becomes one of veracity of the token. If Oyster issues the card or ticket, they can rely on a secure supply chain to ensure only legitimate cards are used to hold and redeem value. However, they can't prove where your device came from — it might be a microprocessor emulating a MIFARE device, encased in an ID-1 form plastic card like Oyster cards, but with backdoor logic that might be used to undermine Oyster system controls. There is no positive return for TfL investing against this risk, however small.
So the "no" above is really a policy choice by TfL, not a technical limitation.
Once mobile NFC becomes more accepted by TfL, they will have a way of provisioning a different kind of secure application to the phone, rather than relying on MIFARE emulation. Contactless payment cards issued by Visa, MasterCard, American Express and the other payment brands, use an ISO/IEC standard physical and logical protocol that has been adapted for use in mobile phones as "NFC". The compatibility of the radio and logical protocols, together with suitable security hardware or cloud-based tokenization, will enable the mobile phone to hold an Oyster-compatible digital token that will function at turnstiles and at the glass windows.
TfL must upgrade their reader systems and SAMs (nearly in entirety) to enable the use of open-loop payment cards, issued by banks, in addition to closed-loop Oyster tokens issued by TfL. This switch to ISO 14443-4 payment readers has taken awhile. But it works already on busses and they have promised conversion of Tube should be done by 16 September 2014.
This conversion is the first step in enabling consumer-owned security tokens to substitute for agency-issued tokens. And is a HUGE cost savings for TfL. Just accepting V/M contactless cards will save enormous amounts on issuing and replacing cards and on system management. And it is a practical improvement for riders who will no longer have to top-up an Oyster card or adjust a fare—these tasks are now performed automatically.
So it may not be too long from now before you can use an "NFC ring" or "watch" to open a turnstile at your favorite station. You can already use your branded payment card and may as well use your NFC payment enabled phone.