[Standards] guest access

Matthew Wild mwild1 at gmail.com
Fri Jun 26 15:08:32 UTC 2015


On 26 June 2015 at 15:45, Peter Saint-Andre - &yet <peter at andyet.net> wrote:
> On 6/26/15 6:46 AM, Matthew Wild wrote:
>>
>> On 26 June 2015 at 13:38, Peter Saint-Andre - &yet <peter at andyet.net>
>> wrote:
>>> On 6/26/15 5:26 AM, Matthew Wild wrote:
>> I'm not sure I understand completely, then. Are you proposing that the
>> target of the SRV record is the XMPP host (and thus ignore the port?)?
>
>
> I'm not sure I understand completely either. :-)
>
> We'll probably do something like this:
>
>    _xmpp-client._tcp.talky.io. 400 IN SRV 20 0 5222 auth.talky.io
>    _xmpp-guest._tcp.talky.io. 400 IN SRV 20 0 5222 anon.talky.io
>
> Naturally the ports might not be 5222 and such, but the general idea is that
> we want to point guest users at a different auth service. By "SRV two-step"
> I mean that the client would still need to resolve auth.talky.io or
> anon.talky.io in the normal ways (we're not necessarily going to point
> directly to what in draft-ietf-dane-srv we called the "connection
> endpoint").

Right, as I suspected. So the flow would be something like:

 1) Client knows it wants to connect to "talky.io" on XMPP, but it
doesn't have credentials for that domain so it...
 2) Attempts to resolve _xmpp-guest._tcp.talky.io, which returns:

   _xmpp-guest._tcp.talky.io. 400 IN SRV 20 0 5222 anon.talky.io

 3) This isn't a network-level connection endpoint, so it discards the
port number and uses "anon.talky.io" as the XMPP service name in a
usual connection attempt, so it
 4) resolves _xmpp-client._tcp.anon.talky.io, etc. and once connected,
authenticates using whatever mechanism it supports (ANONYMOUS, or
whatever)

As I mentioned, I completely agree with the principle, but I don't
think the technique is ideal. I need to think about it more... :)

Regards,
Matthew



More information about the Standards mailing list