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