On Thu, 2010-03-11 at 23:10 +0000, Will Thompson wrote: > This looks nice! The example flows made it pretty easy to get my head > around; maybe they could be included in the preamble in some form or > another later on? >
Sure, we could drop that in the wiki perhaps, or where you thinking in
the spec itself? Maybe when the developer's guide covers authentication
it could use those.
> Something similar to the chatroom password example could be used to make
> clients that just want to provide a password when you log in, rather
> than storing it on disk, easier, with a TP_PASSWORD mechanism where you
> just Respond("secretpassword"). Which would save simple clients having
> to know how to do SASL PLAIN. Maybe those clients don't actually exist,
> but it's nice to know it's possible.
Not sure what you mean by this. When SASLing with the server it will
always be a SASL_ mechanism. But for chatroom joins and the like, where
the security level is relatively low, the chat UI could handle the
TP_PASSWORD mechanism or whatever.
>
> Maybe the authentication rejection reasons should be namespaced strings,
> D-Bus error style? This would prevent the need for the Other member, and
> would allow people with particularly weird auth requirements to use this
> more easily. But perhaps this is YAGNI territory.
>
Hm, not a bad idea. I don't mind either way. Although revising the enums
or the namespaced strings seem to be the same kind of headache.
> It's a little weird that the Challenge signal is also used for "here is
> a response from the other party", and the Respond() method is used to
> issue challenges to the other party. But this is just a naming thing; it
> makes sense from a technical perspective.
>
Yeah, challenge/response is used liberally in the SASL RFC. It doesn't
matter who is authenticating against who, the challenge is the remote
response, and the response is the remote challenge. I took the same
liberty in this spec.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
