[Standards] guest access

Peter Saint-Andre - &yet peter at andyet.net
Fri Jun 26 12:40:26 UTC 2015

On 6/26/15 5:57 AM, Dave Cridland wrote:
> On 26 June 2015 at 00:51, Peter Saint-Andre - &yet <peter at andyet.net
> <mailto:peter at andyet.net>> 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?

At least for Talky as it's current structured, the invitation is just a 
URL. Using standard URL-based and DNS-based methods seems best:

1. Strip off the room name (path) and the URL scheme to get the domain
2. Query the domain (via SRV) about where to gain guest network access


Peter Saint-Andre

More information about the Standards mailing list