%ents; ]>
Authorization Tokens This specification defines an XMPP extension for generating, requesting, and using authorization tokens, which can be used to join Multi-User Chat rooms, subscribe to Publish-Subscribe nodes, and even register XMPP accounts. &LEGALNOTICE; 0235 Experimental Standards Track Standards Council XMPP Core NOT YET ASSIGNED &stpeter; 0.3 2008-03-31 psa

Changed data forms usage to semantic XML format (except for in-band registration).

 0.2 2008-03-27 psa

Generalized to cover authorization tokens; added use cases for pubsub node subscriptions and XMPP account registration.

 0.1 2008-03-05 psa

Initial published version.

 0.0.1 2008-02-20 psa

First draft.

Although authentication is required in order to access an XMPP network, in some situations it is desirable to require authorization in order to access certain entities on the network. For example, authorization may be required in order to join a &xep0045; room or to subscribe to a &xep0060; node. This document defines a general method for obtaining, sharing, and using authorization tokens over XMPP.

In order to obtain an authorization token that can be sent to a consumer, a user requests an authorization token from the relevant service. For example, let us imagine that the user <crone1@shakespeare.lit> wishes to invite the consumer <hecate@shakespeare.lit> to the chatroom <darkcave@macbeth.shakespeare.lit>. Assuming that the user has already determined that the chatroom supports authorization tokens, the user would send the following request to the room &NSNOTE;.

]]>

If the room supports authorization tokens and the user is allowed to invite contacts to the room, the room returns an authorization token to the user.

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

The syntax of the <token/> element is as follows.

A service MAY use any algorithm in generating an authorization token. Depending on implementation and deployment policies, the algorithm MAY take into account the URI of the consumer and be limited to use by an entity that communicates via that URI. Acceptable algorithms MAY include those defined by other standards development organizations, such as &oauth;.

The user can then send the authorization token to the consumer in an XMPP message stanza:

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

If the consumer wishes to use the token, it MUST first determine the identity of the service (via &xep0030;) so that it can decide how to proceed.

Note: If the service supports this protocol, it MUST return a service discovery feature of "urn:xmpp:tmp:auth-token" in response to each disco#info request (see the Determining Support section of this document).

In this example, the service is a multi-user chat service. If authorization is required in order to join a particular room but the joining entity does not include an authorization token in its join request, the service MUST return an error as follows.

]]> ]]>

The consumer would then include the authorization token in its join request.

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

If the token is acceptable, the service will then allow the consumer to enter the room.

Note: Although XEP-0045 includes a protocol for inviting a contact to a chatroom, that protocol results in the sending of an invitation from the chatroom to the contact (a "mediated invitation"), not from the inviting user to the contact (a "direct invitation"). Because use of &xep0016; may result in blocking of XML stanzas from entities that are not in the contact's roster, mediated invitations may never be delivered to the contact. Use of authorization tokens as described herein enables a user to directly send an invitation to a contact, thus routing around the blocking of mediated invitations.

In this example, the service is a publish-subscribe service. If authorization is required in order to subscribe to a particular node but the subscribing entity does not include an authorization token in its subscribe request, the service MUST return an error as follows.

]]> ]]>

The contact would then include the authorization token in its subscription request.

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

If the token is acceptable, the service will then allow the consumer to subscribe to the node.

In this example, the service allows new account registration using &xep0077;. The registering entity SHOULD request the registration form before attempting to register.

]]> Use the enclosed form to register. If your Jabber client does not support Data Forms, visit http://www.shakespeare.lit/contests.php Contest Registration Please provide the following information to sign up for our special contests! jabber:iq:register ]]>

The user then SHOULD return the form:

jabber:iq:register Juliet Capulet juliet@capulet.com F 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

If the token is acceptable, the service will then allow the consumer to register.

If a service provides and accepts authorization tokens, it MUST advertise support for the 'urn:xmpp:tmp:auth-token' namespace in its disco#info replies (if provided) its &xep0115; notations &NSNOTE;.

To follow.

This document requires no interaction with &IANA;.

Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:auth-token"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.

This specification adds one field to the existing FORM_TYPE for In-Band Registration.

jabber:iq:register ]]> ]]>

Thanks to Dave Cridland and Pedro Melo for their suggestions. Aspects of this specification were inspired by &rfc4467;. Some of the terminology in this specification was borrowed from OAuth.