a message header flag for interactive authentication?

[Thiago Macieira]

On Tuesday 26 August 2014 18:22:41 Lennart Poettering wrote:
> We then started to think that it might make sense to add the boolean
> right to the message header itself for this, inside the flag field. Given
> how interlinked dbus and the need for inetractive authentication is,
> this actually sounds like a good idea to me. Currently, the flags byte
> only knows 2 flags (disable activation, and don't expect a reply), we'd
> like to add a third one. This would relieve us from having to add the
> boolean argument explicitly to all method calls.
> 
> We'd define the flag very generically, as
> "allow-interactive-authentication" or so. It would default to off, and
> would be a way for clients to tell services that they are OK if the
> method call takes a long time due to the need for interactive
> authentication, and that in the UI flow of the app such inetractivity is
> OK. It would then be up to services to actually make use of the flag and
> pass it on to polkit (or some other framework, we wouldn't hardcode that
> in...)
> 
> We'd define the flag only for method call messages, nothing else.
> 
> Opinions?

I like this, but I suggest we extend to a more generic mechanism. The message 
header contains a "a(yv)" structure. So we should simply add a header field 
like "USER_METADATA" (value 10) and in the variant store the user's data.

The most generic mechanism is that the variant contain a "(sv)" struct, so the 
user can add any value to a string key type. If we want to make this simpler, 
we could restrict it to string-string or int-int pairs.

Metadata CAN be ignored by the callee and the callee MUST NOT rely on it being 
there. If the callee requires it, it should be part of the parameters, not 
metadata.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358