[Authentication] Spec review (part 1)

[Michael Leupold]

Hi there,

Michael Leupold wrote:
> 2010/9/21 Stef Walter <stefw at gnome.org>:
>>>> 2) On the other hand, encryption introduces a lot of ugliness. Secrets
>>>> are put on the bus as byte arrays, at the moment it isn't even
>>>> specified how (decrypted) byte arrays translate to strings afterwards.
>>>> Getting rid of encryption allows to use the D-Bus type system. Two
>>>> possibilities: a) secrets are D-Bus variants ("v")
>>>> b) overloading for several common types (like "s", "ay" and "a{ss}")
>>>
>>> I agree that this is a bit of a mess and an oversight on my part. I
>>> think we should specify how those secrets are encoded. I see two ways:
>>>
>>> 1. Add an extra property to detail how the secret of an item is
>>> encoded. Possible values and encodings have to be specified.
>>>
>>> 2. Specify that the decrypted secret IS a D-Bus variant.
>>
>> So this would be like a 'content-type' sort of property on the secret?
> 
> Yes, that was my thought. I guess 2. would be a bit messy. I don't
> think we need all types the D-Bus system provides and reimplementing
> D-Bus variants might be messy.
> 
> So this leaves us with either:
> 
> a) A "Type" property
> b) An optional "Type" attribute
> c) A "type" member in the Secret-struct
> 
> I like a) for its simplicity, b) seems kinda awkward with the only
> benefit being that you could search/filter items by type, c) seems to
> be the cleanest solution. It provides consistency as you'd always
> get/set the actual value and its type in one go. I'd be in favour of
> c).
> 
> The types KDE's KWallet currently uses are:
>  - Unknown/raw data/array of bytes (could be set on all existing
> items for backwards compatibility)
>  - UTF-8 string
>  - Dict<String, String> (serialization would still have to be decided
>  upon)
> 
> We basically need this for backwards compatibility and I also believe
> that being able to figure out how a secret has to be interpreted is
> really necessary.

Any news on that? I'd really like to resolve this before we release so we 
don't have to sort out imcompatibilities between or daemons later which 
might get really messy.

Regards
Michael