On 26 June 2015 at 00:51, Peter Saint-Andre - &yet <[email protected]> wrote:
> Lance Stout and I had a conversation the other day about what we call > "guest access" to an XMPP application. As example, consider a chat service > (text, video, what have you) that has registered users and the ability for > registered users to invite ad-hoc users to a session or meeting. This kind > of functionality is quite common with applications like video conferencing > (Talky, Jitsi Meet, WebEx, etc.). > > If this kind of application is based on XMPP, the invited user needs to > gain access to the network (i.e., authenticate somehow) in order to join > the conference. However, for security and scaling reasons it makes sense to > have these ad-hoc users authenticate at a different place than the > registered users. (Often, but not always, the ad-hoc users might > "authenticate" using the SASL ANONYMOUS mechanism, but other methods are > possible such as token auth.) > > Thus we need a way for a client to discover where it can authenticate as > an ad-hoc or guest user. We don't want to use a DNS SRV Service name of > "xmpp-client" because that will point clients to the service endpoint for > registered users. What we came up with was to use a new DNS SRV Service > name of "xmpp-guest", which would point to the service endpoint for guest > access. > Can't the invitation include the connection detail? Dave.
