On Tue Sep 9 19:51:43 2008, Dirk Meyer wrote:
BTW, if a bad client removes all certificates except its own, you
still have control because you always have the password login.
Clients might also be able to change the password... That's possible
now with the right XEPs.
Comments on that? And where to put it? XEP-0189? XEP-0178? A new
XEP?
And a question for server developer: how complicated is it to add a
feature like this?
I'm thoroughly against "special" pubsub nodes, because they
complicate the processing of pubsub/PEP requests.
So I'd be inclined to have a provisioning <iq/>, which might
(possibly optionally) publish internally to XEP-0189. It also then
has the ability to refuse to provision the certificate.
As to how difficult this is - not very.
I've done "proper" CA-based X.509 authentication in our
implementation, and that's moderately complex, but do-able.
Doing simple certificate comparison, on the other hand, is pretty
easy, since you just load in an X.509 object and check for equality.
I think I could implement this reasonably quickly.
But I don't think you want this. I think you want to have a user
control a "mini-me" account for automata - so maybe they get a fixed
resource, and low rights - no ability to change certificates,
passwords, or even roster items - and that'scomparitively much harder
to do.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
