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.
Thanks,
Peter
--
Peter Saint-Andre
https://andyet.com/
