[Standards] resource identifiers: a summary

Peter Saint-Andre stpeter at jabber.org
Fri Jun 1 15:23:49 CDT 2007


Andrew Plotkin wrote:
> On Thu, 31 May 2007, Peter Saint-Andre wrote:
> 
>> Here is a summary of the recent thread about resource identifiers...
>>
>> 6. Allowing a client to specify the resource identifier is not evil 
>> and should not be disallowed. So I am not arguing that a server MUST 
>> generate the resource identifer or override a resource identifier 
>> provided by the client during resource binding. As long as client 
>> developers understand the risks involved, let them do what they've 
>> always done. But we need to add something about this to the security 
>> considerations in rfc3920bis and perhaps rfc3921bis.
> 
> Our game system uses *well-known* resource IDs for IQ-based (bot) 
> services. We're treating it as a feature, not merely a byproduct of poor 
> security.
> 
> We have a service running at bookkeeper at volity.net/volity. We want to 
> always have that full address (including resource string), because its 
> purpose is to accept IQs (disco and XML-RPC) from clients. If we got a 
> random resource every time the bot restarted, our lives would be harder 
> -- we'd have to do additional negotiation. (Either require every client 
> to add the bookkeeper to roster, or do a round of <message> to establish 
> the resource ID.)
> 
> Is the well-known ID (for a particular JID) a legitimate use case? Or 
> should we be handling this some other way?

As I said, there's nothing evil about it. I don't think every user would 
want to have that, but for your bot it probably makes sense.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070601/00db4e78/smime.bin


More information about the Standards mailing list