Support for creation of key-pairs

[dany74q]

Heya !

For the past few days, I've been working on making webuathn flows to work with OSX's keychain;
During this process, I had to write various wrappers, helpers, and logic that I think would be best served if it were split and contributing to several OSS libraries.

Keyring is the de-facto python standard for accessing OSX keychain - I wonder if you'd be open to the idea of extending the password-oriented interface to storing, retrieving (and potentially signing with) private & public keys;
or alternatively, offering implementations that implement a password interface, and an additional keypair interface.

I have the keychain related logic for it - and not sure this expansion would make sense for every backend.

Let me know if you think this is directionally interesting for the future of keyring, or if it's too far-off the main goal of the library.

Thanks, appreciate your time !

[jaraco]

Hey Dany. Definitely open to improvements, and as we've seen with the introduction of get_credential, it's possible to introduce a feature incrementally across backends. If we can envision a design in which each backend could potentially implement an interface for key pairs, I'd be okay with the macOS backend being the only backend that implements it (initially).

To start, what is it that's special about public/private keypairs? What features would you expect from an interface supporting keypairs? What would prevent a library from building on top of keyring to store/retrieve a key pair using the get_password and set_password primitives?

[dany74q]

@jaraco - great questions, I think that the last one stresses an important point,
and that is - one can probably b64 encode the keypair and store it as a password,
with no real loss of functionality.

I've looked at other supported backends (namely, SecretService, KWallet, Win CredLocker), to get a better feel as to if any of them have a dedicated key pair primitive;
none of them seem to offer such granularity between secret types.

To that end, I think you led me to a better option - I can either create an external backend that uses
keychain's key pair primitives - if on a second glance it would seem that there's any benefit to categorize the secret
as a keypair;
or simply encode & store it as a generic password.

One of the above will fit well with my end goal - so I don't think there's a clear advantage to have such support baked in to the library itself.

Appreciate your input !