[Standards] resource identifiers: a summary
stpeter at jabber.org
Thu May 31 18:31:29 UTC 2007
Here is a summary of the recent thread about resource identifiers...
1. The current practice of specifying non-random resource identifiers
from the client side results in potential presence leaks. No one has
contested this. So if I always log in as "stpeter at jabber.org/roundabout"
then people can send IQs to that full JID and perhaps discover if I am
online, even if they are not in my roster. This seems like a bad thing.
2. Resource identifiers are supposed to be used purely for routing
purposes and are not supposed to have semantic meaning for any entity on
the network. If this is not sufficiently clear in RFC 3920 then we can
make it clearer in rfc3920bis.
3. Most users are blithely unaware of resource identifiers (e.g.,
because they log in with only one client or because their clients hide
other users' multiple resources from them as too complicated for end
users to handle), but some power users like resource identifiers and
also like them to have semantic meaning (foo at bar.com/office is always my
desktop machine at the office, etc.).
4. We have ways to discover the identity of particular resources, via
things like the presence <status/> element, Entity Capabilities
(XEP-0115), Software Version (XEP-0092), Service Discovery (XEP-0030)
potentially with extensions (XEP-0128), Geolocation (XEP-0080), and so
on. So power users do have the means to know that some other resource is
in fact their desktop computer at the office, even without semantically
meaningful resource identifiers.
5. From my recent reading of the specs, I think that the text about
resource binding in RFC 3920 and rfc3920bis could be cleaned up,
especially with regard to handling of user-provided resource identifiers
as opposed to server-generated resource identifiers. Also I think that
we should recommend server-generated resource identifiers and specify
that the resource identifier should be a UUID in string format, such as
"ca486eba-0f9a-11dc-8835-000bcd821bfb". I will post separately about
this once I come up with proposed text for this section.
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.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards