[Standards] guest access

Dave Cridland dave at cridland.net
Fri Jun 26 15:01:32 UTC 2015


On 26 June 2015 at 13:40, Peter Saint-Andre - &yet <peter at andyet.net> wrote:

> 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
>
>
What does this URL look like?

I'm assuming that the inviter knows that the invitee needs guest access, in
which case the invitation URL can presumably encode what's needed, even if
it's just a "guest domain" to be looked up in the normal manner. Or even if
it's an HTTP URL which derefs for more extensive information.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150626/0fee682b/attachment.html>


More information about the Standards mailing list