[Authentication] Items, attributes and properties

[Michael Leupold]

On Wednesday 15 July 2009 19:11:56 Stef Walter wrote:
> > As mentioned before KDE Wallet knows different types of secrets (String,
> > String-String Map/Dictionary and Binary). While it's possible to store
> > any of those secrets using the current API a client application for
> > secret management (eg. kwalletmanager on KDE) will have no means of
> > figuring out how to display a secret unless it stores the type inside the
> > secret (which means a loss in interoperability with other client
> > applications).
> > Thus I mandate an additional org.freedesktop.Secrets.Item.Type property
> > of type integer. It would currently use the following values:
> > enum Types
> > {
> >   TypeString = 0,
> >   TypeDictionary = 1,
> >   TypeBinary = 2
> > };
> > More values could be added later if there's a need for it. The service
> > implementation wouldn't have to be concerned with types at all (just
> > storing the type and the binary value).
>
> I personally think KDE wallet should have implement this on the client
> side. gnome-keyring currently has a concept of an item 'type' but it's
> completely different. It's used as a schema. We have types like:
>
>    GNOME_KEYRING_ITEM_NETWORK_PASSWORD
>    GNOME_KEYRING_ITEM_GENERIC_SECRET
>    GNOME_KEYRING_ITEM_NOTE
>
> Could KDE wallet could do one of the following?
>
>  * Automatically determine the type when the secret comes back out.
>  * Use a specific prefix in the secret to prefix dictionary and binary
>    types (for example).
>  * Store an attribute which determines the type.
>
> gnome-keyring will store it's type property (which again, is like a
> schema) in an attribute.

While automatically determining the type wouldn't work, prefixing or storing a 
type attribute would certainly work. My main concern with it is that it would 
be specific to KDE clients only. So if the secret collection management client 
of platform X would list a collection's items it doesn't know how or even if 
to display any of them. If other client libraries decided they'd want a 
similar feature they'd also have to re-invent a method.

How about the following compromise:
Type is specified as one of the fixed-set attributes mentioned below using a 
set of given values ("map"/"binary", no need for string) and a way how to 
marshal secrets of those types (using the methods mentioned above).

Like this we can keep both KWallet compatibility and (as I understand it) the 
keyring file format.

> > Regarding attributes:
> > There are attributes which not only have a meaning to the application
> > storing/retrieving the password but also to client/management
> > applications. Therefore I'd like to have a list of attributes which have
> > specified semantics. One of them KDE will have to keep supporting for
> > compatibility is the "Folder" attribute. User-visible attributes like
> > this one should either be prefixed with the application/desktop
> > environment's name (eg. "X-KDE- SomeAttribute") or amended to the spec.
> > Client support for known attributes amended in the spec should be
> > OPTIONAL but no client may use a known attribute in a way other than
> > specified.
>
> Let's choose a prefix that applications shouldn't use for their own
> purposes, and document that in the API.

This sounds like it could lead to name clashes (X choosing attribute a and Y 
choosing attribute a - both unprefixed).

> A password manager might choose to filter out prefixed attributes or use
> known attributes in a certain way, but I don't think that should be
> specified in the API.

I'd not put it into the API but make an addendum that contains extra stuff 
(implementation hints, attributes used elsewhere...).

> > As a first "known attribute" I'd like to propose "Folder":
> > "Folder" is a string (ie. "My Special Passwords") allowing a user to
> > order passwords. Folders can be nested by using "/" as a separator.
> > Therefore single folder names must not use "/" as a separator. The folder
> > attribute is meant for display only and should not convey any semantic
> > meaning other than specified.
>
> Doesn't the concept of a folder map to a collection? Or am I missing
> something? If the concepts don't map, then this would (I imagine) be a
> desktop specific attribute.

The main difference is that multiple user-visible folders could reside inside 
the same collection thus providing a single collection a user can use to 
manage manually entered passwords. The folders would be used to manage stuff 
inside those collections (eg. I use folders for various of my web work to 
manage passwords by-customer). I'd put that into an addendum as well (not the 
main API) as it would be a strictly client-only feature.

Regards,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/authentication/attachments/20090715/47cdd8bc/attachment.pgp