This extension has been deprecated.
Recently I implemented a first version of public-key driven presence subscription on both server and XMPP client1. The idea is simple: if Alice wants to see Bob's presence and write to him, Bob must sign Alice's public key first — and vice-versa. Server can verify each other's public key signatures and either allow or deny presence subscription and message delivery. This can bring some benefits:
- server won't need to store roster list — since Kontalk is a roster-less system, this is a very good way to achieve it and store it in a user-controlled way.
- Many will start to use Web of Trust — PGP web of trust is still confusing to some users; using a system like this can broaden adoption of a decentralized web of trust using open and standard tools.
Here is how the protocol looks like. It's an extension to the normal presence subscription flow.
Alice wants to subscribe to Bob.
<presence id='xk3h1v69' email@example.com' type='subscribe'/>
Server checks if Alice's public key has been signed by Bob. If that's the case, subscription is accepted immediately: server will reply with presence subscribed.
If Alice's key is not signed by Bob, server forwards the presence subscription request to Bob, injecting Alice's public key:
<presence id='xk3h1v69' firstname.lastname@example.org/balcony' email@example.com' type='subscribe'> [Alice's public key] </presence>
Public key might be included using XEP-0189 with the pubkey element inside the presence stanza.
At this point, Bob can decide to either sign Alice's public key or reject the subscription.
<presence id='xk3h1v69' firstname.lastname@example.org' email@example.com/balcony' type='subscribed'> [include Alice's signed public key] </presence>
Refusal is achieved in the usual way — presence unsubscribed stanza.
Obviously to make this work, both users have to sign each other's key. Eventually servers will use those signatures to check if message delivery and presence subscription are allowed.
I recently proposed this idea to the XMPP standards list but I guess they didn't feel so happy about it — actually they didn't even reply. If anyone has opinions or comments please post them to the mailing list.
androidclient genkeypair branch ↩