[Authentication] Collection/Item unlocking

Michael Leupold lemma at confuego.org
Wed Jul 15 03:46:52 PDT 2009


Hi,

I was wondering if we really need individual-item unlocking? While on the 
service side it's up to the implementor if he wants it, clients would have to 
implement all of it to be able to communicate with every daemon.

So far I don't really see the benefit of it (an application could still create 
while I clearly see how complicated things will get in my client code and 
would prefer whole-collection unlocking only. Or is that meant to be able to 
check acls on individual items?

Having collection-only locking we could introduce a "ChangeAuthentication" 
call on collections which will initiate some GUI to change a collection's 
authentication information (eg. a password to unlock) in the service.


Other questions related to unlocking as well:
- org.freedesktop.Secrets.Collection.SearchItems - with individual-item 
unlocking it should be specified if this searches ALL items or just unlocked 
ones

- org.freedesktop.Secrets.Service.SearchCollections - same as above. search 
all or just unlocked? Furthermore, if results and locked are distinct I'd 
rename "results" to "unlocked" to make it more clear.

- org.freedesktop.Secrets.Service.RetrieveSecrets - The description should 
specifiy that "secrets" returns items in the order queried for (so items[n] => 
secrets[n]). There's currently no way this method can return an error if one 
of the items is not found/locked. As it's nonetheless useful, it could return 
secret structs with empty value so it would be up to the client to check if an 
item exists.

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/630c8e7f/attachment.pgp 


More information about the Authentication mailing list