[Standards] guest access

Kevin Smith kevin.smith at isode.com
Fri Jun 26 08:12:06 UTC 2015


On 26 Jun 2015, at 00:51, Peter Saint-Andre - &yet <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.
> 
> Has anyone else deployed this kind of pattern? If so, how did you solve the problem of service endpoint discovery? Would you find it helpful to have a DNS SRV Service name for this kind of access?
> 
> If there is wide enough interest, I'd be happy to write a spec and pursue registration of the service name with our friends at IANA.

I guess the two options are either another SRV entry, or using the standard client endpoint and then advertising after connection.

I know a surprising number of people have issues with SRV, so that’s an argument in favour of doing a redirection in stream:features or the like, but SRV is the neater solution, I think.

/K


More information about the Standards mailing list