[Standards] XEP-0369 (MIX) - approach to Channel invitation
dave at cridland.net
Thu Sep 29 10:21:01 UTC 2016
On 29 September 2016 at 09:41, Kevin Smith <kevin.smith at isode.com> wrote:
> 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).
My concern was spam invitations, actually, but I suspect there's lots
of useful things one can do if one has an opaque token from the
Really, I think we're after:
1) Inviter sends a token request to MIX channel.
2) MIX channel responds with either a token, or an error (if the
invitee cannot be invited).
3) Inviter sends token onto Invitee. We want this pathway to avoid
privacy list and spamming issues.
4) OPTIONAL: Invitee can check validity of the token with the MIX
channel without causing side-effects. This allows a UI to discard
spammy invites. This might also be an abuse pathway of its own; so
we'll want to keep an eye on this.
5) Invitee can "spend" token within a MIX join. This may or may not
mean that subsequent use of the token fails.
I think this allows Sam's stateless case easily enough, and provides a
set of mitigations against spam invitations as well.
FWIW, I suspect a simple HMAC over the invitee bare jid and the MIX
channel id against a short-term private key held by the MIX channel is
adequate for these tokens for the use-cases discussed so far, but
making it any kind of opaque string should be future-proof. If we
really want, add in a "token-type" attribute and default it to
"opaque". Can't hurt, might provide useful in the future.
As an aside, I think this provides general cover for the passworded
channel use-cases, too - if one considers the password to be simply
another invitation token. But I've not thought this through very far.
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards