[Standards] XEP-0369 (MIX) - approach to Channel invitation

Sam Whited sam at samwhited.com
Tue Sep 27 16:18:13 UTC 2016


On Tue, Sep 27, 2016 at 3:30 AM, Steve Kille <steve.kille at isode.com> wrote:
> A simple approach to address this more complex scenario is a two-step
> approach where the inviter starts by sending a message to the channel to
> grant the invitee rights to join the channel and then sends a simple invite
> to the invitee.
>
> This seems much simpler than the current descriptions of passing tokens
> around, and is to my mind a preferable approach.  Is there a requirement
> that I am missing, which needs the token passing approach?

I personally prefer a simple token based approach for two reasons:

  * We may not know the invitee's JID to request that the server allow
it (eg. if we're sending the invite out of band via an email)
  * We may not want to maintain a list of people who have been invited
(eg. if we wanted to have some form of stateless authentication
gateway that users connect too to determine if they're allowed into
the MIX)

The first example is obviously solved by use of a token, and the
second example can be solved by sending an HMAC as the token, then
instead of storing it, we just validate any tokens
sent back to the server with the same secret, similar to the way web
forms often use HMAC's for CSRF tokens.

If we want to have a stateles invite service, but also want to verify
all JIDs explicitly, we can always encode the JID in the token (eg.
make it a part of the HMAC secret or make the token a signed JSON web
token or whatever it's XML counterpart is if such a thing exists).


I also think, however, that tokens don't need to be specified in the
MIX spec and can be a matter of server policy without clients needing
special support by allowing invites to have a
server-generated arbitrary payload which MUST be sent back when
accepting the invite. This way servers could use tokens (simple
tokens, HMACs, signed JWTs, etc.) or simply send an empty payload and
validate the JID (or any other scheme they can come up with) and the
spec wouldn't have to mention any of them except in passing.

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3


More information about the Standards mailing list