[Authentication] Items, attributes and properties

[Michael Leupold]

Now on to items...

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)

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

Marshalling (client-side):
- TypeString - UTF-8 string
- TypeDictionary - pretty much equivalent to D-Bus a{ss} but without the 
padding.
- TypeBinary - no transformation needed

This does not mandate how secrets are stored so implementations may choose to 
store the type inside the secret and extract it as Type property and for 
transmitting the secret.


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.

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.


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/83f827f5/attachment-0001.pgp