[Authentication] project ideas

[Michael Leupold]

Hi Ben,

Sorry for the late reply, I've been pretty busy at work.

Am Freitag, 26. Februar 2010 00:31:05 schrieb Ben Kibbey:
> On Wed, Feb 24, 2010 at 10:03:21PM +0100, Michael Leupold wrote:
> > The concept used in the Secret Service API is a bit different but can
> > in some ways achieve similar things. Secret items in the API are
> > usually not stored and retrieved by name ("isp", "exim", ...) but by
> > attributes. This basically means that you wouldn't store an imap
> > account's password using the name "isp" as its identifier but would
> > attach attributes likes "server=imap.myisp.com:993" or "type=email"
> > which would enable the item to be found by several applications.
> 
> How would multiple accounts on the same server be handled?

You'd introduce an extra identifier. Either make the mail address or the 
username an attribute or - if you want to keep that private - introduce an 
extra identifier property (guid, integer).

> > One major difference is that the daemon itself doesn't actually parse
> > the secret data. It's just treated as a binary blob. Of course this
> > makes refering to elements inside some hierarchy pretty much
> > impossible. As I don't know how pwmd is used I don't know if that's a
> > must-have feature though (I'm trying to imagine how that would work in
> > an application's gui but can't really figure out how it would be
> > used).
> 
> pwmd doesn't really parse the data either. It only stores it at some
> location in the XML document. So to retrieve some data associated with
> something the client needs, the client sends an element path using the
> GET protocol command: GET isp<TAB>username. The XML might look like
> this:
> 
> 	<root name="isp">
> 		<username>someuser</username>
> 		<server>some.server.com</server>
> 		<port>993</port>
> 		...
> 	</root>
> 
> It's different that it's not a binary blob like the Secrets Service but
> it can be base64 en/decoded by the client before storing and after
> retrieving if binary data is needed.
> 
> Haven't really thought about the GUI of applications for pwmd much. The
> way it works for most of the patches I have for apps (all but one are
> daemons or console apps) is that an application or service element name
> is created in the XML document and the children of that element are
> settings for the service or application. So the client/app only needs to
> know what it wants although no standard/specification of the root
> element or element attribute names has been thought up.
> 
> For a GUI app only a root element path and data filename to open would
> be needed. The rest of the data that the app needs is retrieved/stored
> from the app-configured root element path. I suppose a GUI tree widget
> of the document structure for selecting the root element would be nice.
> This can be gotten with the LIST/DUMP/XPATH protocol commands.

Does that mean the client parses the XML as well to get to other applications' 
root elements? Or does pwmd do that?

> > There's already some (afaik non-public) KDE API for storing secrets
> > using the current KWallet through the means of the KConfig system. I
> > don't believe merging configuration and storage of secrets is that
> > good an idea. I'd like to keep the two separated. Especially since I
> > fear the result might get so complicated we might face a problem
> > finding someone to maintain it - after all configuration systems and
> > password management daemons don't seem to be among the top 10
> > "projects I'd like to maintain".
> 
> What would be complicated about it? It only stores the data right? It's
> up to the client what it does with it. Or maybe the attributes are
> hard-coded? Is that what you mean?

No, I mostly meant that the more features you cram into it the harder it gets 
for someone working on it to figure it out and improve it :-) Keeping things 
simple makes it easier for others to help and fix bugs.

Regards,
Michael