[Authentication] Collection/Item unlocking

[Michael Leupold]

On Wednesday 15 July 2009 19:24:08 Stef Walter wrote:
> Michael Leupold wrote:
> > 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.
>
> Locking, ACLs, prompts are all the most challenging parts of this API.
> I've seen a lot of it done wrong, or inflexibly, and want to make sure
> we get it as close to 'right' as possible this time around.
>
> [... zipp ...]

Sorry for stripping that much text (I advise other non-believers to read the 
original reply :)). After reading it I agree that individual-item locking is 
indeed beneficial and worth some extra work on getting a good client library.

> > 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.
>
> I feel that this must be implemented as an additional interface, which
> password managers can use to control a collection.
>
> Remember that service implementors may choose to implement locking
> non-master-password methods such as:
>
>  * Keys
>  * Fingerprints
>  * Prompts on a removable device.
>  * Attaching a USB unlock stick.
>  * Many other ideas....
>
> While the above "ChangeAuthentication" suggestion does not exactly limit
> a service implementor to use of master passwords, I still feel it's
> better served as an additional interface, an implementation detail.

Yeah, I mostly agree. It's especially hard to foresee what an implementation 
might use to authenticate a user so a simple "ChangeAuthentication" call might 
indeed be too simple whereas tieing the specification too close to the 
implementation seems unfortunate as well. I guess we could have this 
implementation defined for now and agree on a common way later - if it might 
turn out to be feasible.

> > 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
>
> All items, it finds unlocked ones. This is essential for a good user
> experience. Otherwise the user will at times need to unlock a collection
> in which there was nothing of interest.
>
> Again, 'individual item unlocking' does not mean that items need to be
> encrypted individually. Most service implementers will prompt for and
> unlock an entire collection when an item in that collection is 'unlocked'.

Thanks for the clarification. +1 from me. This should probably be documented.

> > - 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.
>
> Hmmm, that's true. But I wonder if there's a better way to do this. Null
> values are not well represented in DBus. Should we instead return a dict
> of object-path -> secret?

Yes, it seems more appropriate. Like this we could just leave out items which 
are impossible to retrieve.

> Again, none of the above is intended to be 'last word' even when I do
> come across strongly :)

Don't worry, if the idea is superior I'll agree right away, if it isn't I'll 
still try to improve it :-)

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/1e0840c5/attachment.pgp