[Standards] MIX Invitations and PARS (XEP-0379)
steve.kille at isode.com
Tue Jan 24 14:57:08 UTC 2017
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
> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Georg
> Sent: 24 January 2017 11:08
> To: standards at xmpp.org
> Subject: [Standards] MIX Invitations and PARS (XEP-0379)
> while pondering about Easy Group Chats, I realized that there is some
> similarity between the MIX invitation token (§5.1.17 ) and PARS
> (XEP-0379 ), 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:
> <inviter>hag66 at shakespeare.lit</inviter>
> <invitee>cat at shakespeare.lit</invitee>
> <channel>coven at mix.shakespeare.lit</channel>
> PARS (as part of a presence subscription):
> <presence to='romeo at montague.net' type='subscribe'>
> <preauth xmlns='urn:xmpp:pars:0'
> token='1tMFqYDdKhfe2pwp' />
> 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.
>  https://wiki.xmpp.org/web/Easy_Group_Chats
>  http://xmpp.org/extensions/xep-0369.html#usecase-user-invite
>  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