From 035720240dc859419c2d2962becada3325161a33 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 18 Apr 2008 16:32:08 +0000 Subject: [PATCH] 0.3 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1773 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0235.xml | 275 ++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 229 insertions(+), 46 deletions(-) diff --git a/xep-0235.xml b/xep-0235.xml index 0e35cd51..b490d2f2 100644 --- a/xep-0235.xml +++ b/xep-0235.xml @@ -6,8 +6,8 @@
- Direct Invitations - This specification defines an XMPP extension for generating, requesting, and providing invitations, which can be used in the context of Multi-User Chat rooms and other services. + 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 @@ -21,6 +21,18 @@ 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 @@ -35,69 +47,214 @@
-

&xep0045; 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. Therefore, this specification defines an XMPP extension that enables a user to directly send an invitation to a contact, thus routing around the blocking of mediated invitations. While the main use case for this protocol is multi-user chat, nothing in the protocol prevents it from being used to invite contacts to other types of services, such as &xep0060; services or future collaboration services.

+

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 invitation that can be directly sent to a contact, a user requests an invitation token from the relevant service. For example, let us imagine that the user <crone1@shakespeare.lit> wishes to invite the contact <hecate@shakespeare.lit> to the chatroom <darkcave@macbeth.shakespeare.lit>. The user would send the following request to the room &NSNOTE;.

+ +

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 the direct invitation protocol and the user is allowed to invite contacts to the room, the room returns an invitation token to the user.

+

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 invitation is as follows.

+

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

    -
  • The 'expires' attribute defines a date and time when the invitation expires. Inclusion of this attribute is OPTIONAL. If included, it MUST be a DateTime as specified in &xep0082;.
    • -
  • The 'for' attribute defines the JabberID of the invitee. Inclusion of this attribute is REQUIRED.
    • -
  • The 'jid' attribute defines the JabberID of the service to which the invitee is being invited. Inclusion of this attribute is REQUIRED.
    • -
  • The XML character data of the <invitation/> element is the invitation token itself. The token MAY be generated according to any method deemed appropriate by the service implementation. It is RECOMMENED that the token be the hexadecimal representation of a Keyed-Hash Message Authentication Code (see &nistfips198a;) generated using the SHA256 hashing algorithm (see &nistfips180-2;), as described elsewhere in this document.
    • +
  • The OPTIONAL 'expires' attribute defines a date and time when the token expires. If included, it MUST be a DateTime as specified in &xep0082;.
    • +
  • The REQUIRED 'consumer' attribute defines the URI of the entity to be authorized (e.g., an XMPP URI, mailto URI, or HTTP URL).
    • +
  • The REQUIRED 'service' attribute defines the JabberID of the service for which the consumer is being authorized.
    • +
  • The OPTIONAL 'node' attribute defines a publish-subscribe node at the service; if the 'node' attribute is included, the authorization MUST be accepted only for interactions with that particular node.
    • +
  • The XML character data of the <token/> element is the authorization token itself.
 - -

The user can then send the invitation to the contact in an XMPP message stanza:

- +

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 - + ]]> - -

The contact then MUST then determine the identity of the service (via &xep0030;) so that it can determine how to use the invitation.

-

In this example, the service is a multi-user chat service. Therefore if the contact wishes to join the designated chatroom, it will include the invitation in its join request.

- + +

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.

+ + + + - ]]> -

If the invitation is acceptable, the service will then allow the contact to enter the room.

-

Note: Detailed error flows will be added to a future version of this specification.

+ ]]> + + + + + + + + + + ]]> +

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.

@@ -107,7 +264,21 @@ -

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

+

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 + + + ]]> + @@ -116,27 +287,39 @@ - + + + + - - + + + + + + + + + ]]> -

Thanks to Dave Cridland for his suggestions. Aspects of this specification were inspired by &rfc4467;.

+

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.