[Standards] MIX Invitations and PARS (XEP-0379)

Steve Kille steve.kille at isode.com
Tue Jan 24 14:57:08 UTC 2017


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:standards-bounces at xmpp.org] On Behalf Of Georg
> Lukas
> Sent: 24 January 2017 11:08
> To: standards at xmpp.org
> 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>hag66 at shakespeare.lit</inviter>
> 		<invitee>cat at shakespeare.lit</invitee>
> 		<channel>coven at mix.shakespeare.lit</channel>
> 		<token>ABCDEF</token>
> 	</invitation>
> 
> PARS (as part of a presence subscription):
> 
> 	<presence to='romeo at montague.net' 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:somemix at mixdomain.mixrocks.xmpp?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
> ||_________________________________________________||



More information about the Standards mailing list