[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