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

Kevin Smith kevin.smith at isode.com
Thu Sep 29 08:41:31 UTC 2016


On 27 Sep 2016, at 17:18, Sam Whited <sam at samwhited.com> wrote:
> 
> 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.

I agree with Sam. It’s easier for servers not to have to keep a state table if they don’t want to, and tokens let them encode it. ISTR Dave also had a use case here where he wanted the MUCs to know that a user was joining because of an invite and so could reject them if the token was wrong, even if the user was allowed to join (because it was possible but inappropriate for them to join in normal circumstances, I think, but I forget the details, I was concentrating on eating curry at the time).

/K


More information about the Standards mailing list