Georg, MIX defines a token mechanism for mediated invitations. Details are left open to the MIX implementer, including: - Token syntax - Token (detailed) semantics - Implementation approach
Two possible implementation approaches for MIX tokens: a. Hash across the <invitation> and a channel private token. The channel can then validate in stateless manner b. A key index into a database of invitations that are held by the channel and expired after a period It could also be extended to your requirement of using an invitation for a different JID to the original invitee. I'm not sure this is a good idea, but a MIX channel could support this without change to protocol. It could make sense to write a bit about this in the spec, although my initial thinking is that the current words suffice Regards Steve > -----Original Message----- > From: Standards [mailto:[email protected]] On Behalf Of Georg > Lukas > Sent: 24 January 2017 11:08 > To: [email protected] > Subject: [Standards] MIX Invitations and PARS (XEP-0379) > > Hi, > > while pondering about Easy Group Chats[0], I realized that there is some > similarity between the MIX invitation token (ยง5.1.17 [1]) and PARS > (XEP-0379 [2]), but also some differences that I would like to streamline and > better understand. > > Both expose an authentication token, which is forwarded to another user, > allowing that user to gain access. > > MIX invitation: > > <invitation> > <inviter>[email protected]</inviter> > <invitee>[email protected]</invitee> > <channel>[email protected]</channel> > <token>ABCDEF</token> > </invitation> > > PARS (as part of a presence subscription): > > <presence to='[email protected]' type='subscribe'> > <preauth xmlns='urn:xmpp:pars:0' > token='1tMFqYDdKhfe2pwp' /> > </presence> > > In the MIX spec, the token seems to be bound to the inviter's and invitee's > JIDs (you need to pass both when requesting it), so I could imagine an > implementation that encodes both JIDs into the token and later verifies that > the user attempting to join is actually the token's invitee. This is not > explicitly > stated in the XEP, so I wonder if this is a conscious design decision or not. > > Depending on whether you want to bind an invitation token to a given inviter > and/or a given invitee, I propose to remove the 'inviter' and 'invitee' > elements from the <invitation> XML, and possibly even to replace the 'token' > with a PARS element. > > Personally, I'd like to be able to issue tokens to people who's JID I don't > know > in advance, e.g. on a web page. For this, I'd like to at least recycle the > preauth > query parameter for the xmpp: URI, i.e.: > > xmpp:[email protected]?mix&preauth=ABCDEF > > Which would then be encoded into the <preauth/> or <token/> XML when > joining the channel. > > Comments? > > > Georg > > [0] https://wiki.xmpp.org/web/Easy_Group_Chats > [1] http://xmpp.org/extensions/xep-0369.html#usecase-user-invite > [2] http://xmpp.org/extensions/xep-0379.html > -- > || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ > || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || > || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || > ++ IRCnet OFTC OPN > ||_________________________________________________|| _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
