[Authentication] Open Issue: Passwords for new Collections

[Michael Leupold]

Stef Walter wrote:
> This discussion assumes that the service locks collections individually,
> which gnome-keyring does.
> 
> In some cases when a new collection is created, it's good enough to lock
> it with the users login password. In effect this does not prompt the
> user for a new password.
> 
> However in many cases, the whole point of creating a new collection is
> to put a different lock password on it.
> 
> We currently have no facility in the API by which a client application
> can request a new password be prompted for.
> 
> In addition, what's been nice about the API is that no calls are
> blocking, and BeginAuthenticate/CompleteAuthenticate are the only ones
> that actually have asynchronous state.
> 
> I've been thinking about this problem for a while.
>  * Either we introduce another pair of calls for prompting for
>    new authentication.
>  * Or we overload BeginAuthenticate/CompleteAuthenticate to do this.
> 
> I'm leaning toward the latter. In particular:
> 
>  * Specify a certain 'reason' argument to BeginAuthenticate,
>    which specifies why the authenticate is being done.
>  * One reason might be: 'unlock'
>    - This signifies a normal unlock of the collection/item.
>  * Another reason might be: 'change'
>    - Prompts the user to change locking (usually a new password).
>    - Also used to set a new password. Service would know whether
>      a previous password was set.
> 
> What do you all think? In addition this covers the use case of changing
> a collection lock (usually a password). We had previously said this
> would be service specific, but it seems like we'll to bake something
> like this (at least for new collections) in the API. It's nice to have
> it cover both new, and collections previously created.

I'd actually prefer the former as I think this method is a little harder on 
the application. In my opinion setting the password on creating a new 
collection should be done implicitly on the CreateCollection call which is 
already async (CollectionCreated signal).

When changing the user authentication the application (which will most 
likely be some secret management application) would probably want the 
collection's state after changing the authentication to be the same as 
before, ie. if the collection was locked before it will be locked 
afterwards, if it was unlocked before it will be unlocked afterwards.

As I understand it BeginAuthenticate/CompleteAuthenticate would require the 
application requesting the change (or the client API) to handle this.

Thus I'd prefer:
Method: Boolean ChangeAuthentication(object, window-id);
- objects is the object to change authentication for (collections and/or 
items)
- return value is false, if changing the authentication for that object is 
not supported (ie. it's an item and the service handles authentication per 
collection)
Signal: AuthenticationChanged(object, Boolean);
- async return for ChangeAuthentication
- second argument is false if changing the authentication failed

I think this scheme would be clearer to developers as well.

(BTW: I'm finally back from the shadows and ready to get started on 
development - albeit slowly :-)).

Regards,
Michael