Call for Advices: The design issues in the Python keyring lib

About this project's idea, here's the proposal's abstract:

As the Python desktop applications grew very fast, the need for a general, platform independent keyring API ,becomes important for development. Many services require authentication before they can be used. Application always needs to store these authentications safely.

This lib is aimed to address this problem. By making a single call to this library, an application can store login information on a keyring where the application can retrieve the information—also with a single call—when needed.

For more information, you may refer to Tarek's post on the original idea and the introduction of this project.

The design of this lib has been started. Here's the main issues in the design phase:

Issue #1, the architecture of the keyring lib.
There are several ways to implement an OS related lib. I've surveyed many related work on the python binding for the keyring service. These libs are designed for GTK (Gnome-python and Micheal's work ) or OSX(Keychain.py and PcMacAdmin) . Generally speaking, there are three way to implement such a lib.

• Method 1, use the c/c++'s python extension. This method is used by Gnome-python for their gnomekeyring binding.
  
• Method 2, load the system's library through the ctypes. PyMacAdmin use this way to wrap the Keychain service of OSX.
  
• Method 3, execute a external tool using commonds. Keychain.py uses this method.
  

We prefer method 1, since it is faster and integrated with Python better.

Issue #2, about the lib's Windows implementation.
Windows dose not provided any keyring services like the Gnome keyring and KeyChain. One good option for Windows will be to provide our own lightweight keyring system, as we have everything needed in Python itself to do so. Another possible solution is using the CryptoAPI as Subversion did.

Issue #3, the API interface of this keyring lib.
We want to hear more voice from the potential developers who'll use this lib. An initial draft can be seen in the Tarek's post. I've also made some rough thoughts after looked into Subversion's code.
Since we've decided to construct the whole lib from bottom to up, and to make the API better. This issue is not in a hurry. It will always be waiting for your suggestions.

Any advice given will be credited. Don't hesitate to leave your thoughts here.:-)