[Authentication] Items, attributes and properties

[Stef Walter]

Make sure to read 'On Compatibility and Features' mail posted to this
list to see my comments below in context.

Michael Leupold wrote:
> Just for clarification: Do I get it right that items are supposed to be 
> identified by their object path/unique identifier? (I'd consider that good)

Yes, as noted in 'Small API Issues' I agree with this. We should put
this in the API.

> 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.

> 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.

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.

> 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.

Obviously none of the above is 'last word'...

Cheers,

Stef Walter