XEP-0158: Robot Challenges

This document specifies an XMPP protocol extension that entities may use to discover whether the sender of an XML stanza is a human user or a robot.

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

Document Information

Author Information

Ian Paterson

Email: ian.paterson@clientside.co.uk
JabberID: ian@zoofy.com

Peter Saint-Andre

JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Legal Notices

Copyright

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Discussion Venue

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

1. Introduction
2. Requirements
    2.1. Extensibility
    2.2. Variety
3. Protocol Usage
    3.1. Simple Challenge
       3.1.1. Challenge Stanza
       3.1.2. Response Stanza
       3.1.3. Result Stanza
    3.2. Multiple Challenges
4. Extended In-Band Registration
5. Multi-User Chat
6. Challenge Types
    6.1. Introduction
    6.2. SHA-256 Hashcash
    6.3. CAPTCHAs
7. Question and Answer for Legacy Clients
8. Discontinuation Policy
9. Internationalization Considerations
10. Security Considerations
11. IANA Considerations
12. XMPP Registrar Considerations
    12.1. Protocol Namespaces
    12.2. Field Standardization
       12.2.1. challenge FORM_TYPE
       12.2.2. jabber:iq:register FORM_TYPE
13. XML Schema
14. Open Issues
Notes
Revision History

1. Introduction

The appearance of large public IM services based on RFC 3920 [1] and RFC 3921 [2] makes it desirable to implement protocols that discourage the sending of large quantities of instant messaging spam (a.k.a. "spim") or, in general, abusive traffic. Abusive stanzas could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Such abusive stanas could take many forms; a full taxonomy is outside the scope of this document.

Several of the most effective techniques developed to combat abusive messages and behavior via non-XMPP technologies require humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see <http://www.captcha.net/>). These challenge techniques are easily adapted to discourage XMPP abuse. The very occasional inconvenience of responding to a CAPTCHA (e.g., when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.

An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a Hashcash [3] challenge. These are completely transparent to PC users. They require clients to perform specified CPU-intensive work, making it difficult to send large amounts of spim.

2. Requirements

2.1 Extensibility

The CAPTCHAs in most common use today are Optical Character Recognition (OCR) challenges where an image containing deformed text is presented and the human enters the characters they can read. However, if OCR software advances more rapidly than the techniques used to disguise text from Artificial Intelligence (AI) then very different CAPTCHAs will need to be deployed. This protocol must be extensible enough to allow the incorporation of CAPTCHA techniques that may not have been envisaged.

2.2 Variety

Several common CAPTCHA techniques present major problems to users with disabilities (see Inaccessibility of Visually-Oriented Anti-Robot Tests [7]). Clients running in constrained environments may not be able to perform some challenges (e.g., due to the absence of audio output or a lack of CPU performance). This protocol must allow clients to be offered a choice from a variety of challenges.

3. Protocol Usage

3.1 Simple Challenge

An entity (client or server) MAY send a challenge immediately after receiving a stanza from another entitiy. An entity MUST NOT send challenges under any other circumstances. Hereafter, the entity that generates the stanza that triggers the challenge is called the "sender" and the entity that sends the challenge is called the "challenger".

Example 1. Sender Generates Stanza

<message from='robot@abuser.com/zombie'
    to='innocent@victim.com'
    xml:lang='en'
    id='spam1'>
  <body>Love pills - 75% OFF</body>
  <x xmlns='jabber:x:oob'>
    <url>http://www.abuser.com/lovepills.html</url>
  </x>
</message>

3.1.1 Challenge Stanza

The challange consists of a message containing a form for the sender to fill out, formatted according to Data Forms [8]. Each of the challenge form's <field/> elements that are not hidden MAY contain a different challenge and any media required for the challenge (see Data Forms Media Element [9]). The hidden 'from' field MUST contain the value of the 'to' attribute of the sender's triggering stanza. If the stanza from the sender included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the sender. In accordance with Field Standardization for Data Forms [10], the hidden 'FORM_TYPE' field MUST have a value of "urn:xmpp:tmp:challenge" (see Protocol Namespaces regarding issuance of one or more permanent namespaces).

The challenger SHOULD include an explanation (in the <body/> element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using Out-of-Band Data [11] as an alternative for clients that do not support the challenge form. Note: Even if it provides a URL, a challenger MUST always provide a challenge form. [12]

Example 2. Challenger Offers a Choice of Challenges to Sender

<message from='victim.com'
    to='robot@abuser.com/zombie'
    xml:lang='en'
    id='F3A6292C'>
  <body>
    Your messages to innocent@victim.com are being blocked. To unblock
    them, visit http://www.victim.com/challenge.html?F3A6292C
  </body>
  <x xmlns='jabber:x:oob'>
    <url>http://www.victim.com/challenge.html?F3A6292C</url>
  </x>
  <challenge xmlns='urn:xmpp:tmp:challenge'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:tmp:challenge</value>
      </field>
      <field type='hidden' var='from'><value>innocent@victim.com</value></field>
      <field type='hidden' var='sid'><value>spam1</value></field>
      <field var='ocr'>
        <media xmlns='urn:xmpp:tmp:media-element'
               height='80'
               width='290'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/ocr.jpeg?F3A6292C
          </uri>
          <data xmlns='urn:xmpp:tmp:data-element'
                type='image/jpeg'> ** Base64 encoded image ** </data>
        </media>
      </field>
      <field var='picture_recog'>
        <media xmlns='urn:xmpp:tmp:media-element'
               height='150'
               width='150'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/picture.jpeg?F3A6292C
          </uri>
          <data xmlns='urn:xmpp:tmp:data-element'
                type='image/jpeg'> ** Base64 encoded image ** </data>
        </media>
      </field>
      <field var='speech_recog'>
        <media xmlns='urn:xmpp:tmp:media-element'>
          <uri type='audio/x-wav'>
            http://www.victim.com/challenges/speech.wav?F3A6292C
          </uri>
          <uri type='audio/ogg-speex'>
            http://www.victim.com/challenges/speech.ogg?F3A6292C
          </uri>
        </media>
      </field>
      <field var='video_recog'>
        <media xmlns='urn:xmpp:tmp:media-element'
               height='150'
               width='150'>
          <uri type='video/mpeg'>
            http://www.victim.com/challenges/video.mpeg?F3A6292C
          </uri>
        </media>
      </field>
      <field label='Type the color of a stop light' type='text-single' var='qa'/>
      <field label='93C7A' type='text-single' var='SHA-256'/>
    </x>
  </challenge>
</message>

3.1.2 Response Stanza

The sender's client SHOULD ignore the challenge stanza in either of the following cases:

If it has not recently sent (e.g., in the last two minutes) a stanza to the JID specified in the 'from' field of the form with the 'id' specified in the 'sid' field (or with no 'id' if no 'sid' field is included). [13]
If the 'from' attribute of the challenge stanza does not match the 'from' field of the form. (If the values are different, then they still match if the bare JIDs are the same, or if the 'from' attribute is the domain of the other JID.)

Otherwise, if the challenger provided a URL using Out-of-Band Data, then the sender's client MAY present the URL to the sender, instead of responding to the challenge form, in any of the following cases:

if it does not understand the challenge form
if it does not support all of the required challenges (see Multiple Challenges)
if it does not support enough of the challenges (see Multiple Challenges)

Otherwise, the sender's client MUST respond to the challenge.

The sender's client MUST respond with a <not-acceptable/> error in any of the following cases:

if it does not support all of the required challenges (see Multiple Challenges)
if it does not support enough of the challenges (see Multiple Challenges)
if the sender declines the challenge

Example 3. Sender Reports Challenge Not Acceptable

<message type='error'
    from='robot@abuser.com/zombie'
    to='victim.com'
    xml:lang='en'
    id='F3A6292C'>
  <error type='modify'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>

Otherwise, it MUST select one challenge according to the sender's preferences and submit the sender's response form to the challenger.

Example 4. Sender Sends One Response to Challenger

<iq type='set'
    from='robot@abuser.com/zombie'
    to='victim.com'
    xml:lang='en'
    id='z140r0s'>
  <challenge xmlns='urn:xmpp:tmp:challenge'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>urn:xmpp:tmp:challenge</value>
      </field>
      <field var='from'><value>innocent@victim.com</value></field>
      <field var='sid'><value>spam1</value></field>
      <field var='ocr'><value>7nHL3</value></field>
    </x>
  </challenge>
</iq>

3.1.3 Result Stanza

The challenger SHOULD send a <service-unavailable/> error to the sender if:

The challenger did not send the specified challenge. [14]
The sender already submitted its response to this challenge.
The sender took too long to submit its response.

Note: This error MAY be sent even in cases where the challenge became unnecessary while the challenger was waiting for the response.

Example 5. Challenger Indicates Challenge Not Found

<iq type='error'
    from='victim.com'
    to='robot@abuser.com/zombie'
    id='z140r0s'>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

After receiving a correct response to its challenge, the challenger SHOULD inform the sender that it was successful.

Example 6. Challenger Tells Sender it Passed

<iq type='result'
    from='victim.com'
    to='robot@abuser.com/zombie'
    id='z140r0s'/>

However, if the sender submits an incorrect response the challenger SHOULD send it a <not-acceptable/> error with type "cancel": [15]

Example 7. Challenger Tells Sender it Failed

<iq type='error'
    from='victim.com'
    to='robot@abuser.com/zombie'
    id='z140r0s'>
  <error type='cancel'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

3.2 Multiple Challenges

The challenger MAY demand responses to more than one of the challenges it is offering; this is done by including an 'answers' <field/> element in the form. The challenger also MAY require responses to particular challenges; this is done by including <required/> elements in the compulsory fields.

Example 8. Challenger Sets Multiple Challenges

<message from='victim.com'
    to='robot@abuser.com/zombie'
    xml:lang='en'
    id='73DE28A2'>
  <body>Your messages to innocent@victim.com are being blocked.
    To unblock them, ask innocent@victim.com to send you a message.</body>
  <challenge xmlns='urn:xmpp:tmp:challenge'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:tmp:challenge</value>
      </field>
      <field type='hidden' var='from'><value>innocent@victim.com</value></field>
      <field type='hidden' var='sid'><value>spam2</value></field>
      <field type='hidden' var='answers'><value>2</value></field>
      <field var='ocr'>
        <media xmlns='urn:xmpp:tmp:media-element'
               height='80'
               width='290'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/ocr.jpeg?F3A6292C
          </uri>
        </media>
      </field>
      <field var='audio_recog'>
        <media xmlns='urn:xmpp:tmp:media-element'>
          <uri type='audio/x-wav'>
            http://www.victim.com/challenges/audio.wav?F3A6292C
          </uri>
        </media>
      </field>
      <field label='Type the color of a stop light' type='text-single' var='qa'>
        <required/>
      </field>
      <field label='e03d7' type='text-single' var='SHA-256'/>
    </x>
  </challenge>
</message>

If the sender finds the request acceptable, it MUST answer all challenges that include a <required/> element. If the total number of answers was specified and it is greater than the number of <required/> elements then the sender MUST also answer one or more of the challenges without a <required/> element. In the example above, the sender should respond to the 'qa' challenge and one of the other challenges ('ocr', 'audio_recog' or 'SHA-256').

Example 9. Sender Sends Multiple Responses to the Challenger

<iq type='set'
    from='robot@abuser.com/zombie'
    to='victim.com'
    xml:lang='en'
    id='73DE28A2'>
  <challenge xmlns='urn:xmpp:tmp:challenge'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>urn:xmpp:tmp:challenge</value>
      </field>
      <field var='from'><value>innocent@victim.com</value></field>
      <field var='sid'><value>spam2</value></field>
      <field var='answers'><value>2</value></field>
      <field var='qa'><value>divad</value></field>
      <field var='SHA-256'><value>innocent@victim.com2450F06C173B05E3</value></field>
    </x>
  </challenge>
</iq>

The challenger MAY decide the sender has passed a challenge even if the responses are not all perfectly correct.

4. Extended In-Band Registration

This section shows how challenges SHOULD be combined with the existing In-Band Registration protocol according to the rules defined in the Extensibility section of XEP-0077.

Note: The <challenge/> wrapper element is not included, because XEP-0077 specifies that data forms shall be contained as the direct children of the <query/> element.

<iq type='get' xml:lang='en' id='reg1'>
  <query xmlns='jabber:iq:register'/>
</iq>

Note that the challenge form MUST be inside the <query/> element, and the server's challenge ID is specified within the form:

<iq type='result' xml:lang='en' id='reg1'>
  <query xmlns='jabber:iq:register'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:tmp:challenge</value>
      </field>
      <field type='hidden' var='cid'><value>F3A6292C</value></field>
      <field type='hidden' var='answers'><value>3</value></field>
      <field var='ocr'>
        <media xmlns='urn:xmpp:tmp:media-element'
               height='80'
               width='290'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/ocr.jpeg?F3A6292C
          </uri>
        </media>
      </field>
      <field label='93C7A' type='text-single' var='SHA-256'/>
      <field type='text-single' var='username'>
        <required/>
      </field>
      <field type='text-single' var='password'>
        <required/>
      </field>
    </x>
    <instructions>
      To register, visit http://www.victim.com/register.html
    </instructions>
    <x xmlns='jabber:x:oob'>
      <url>http://www.victim.com/register.html</url>
    </x>
  </query>
</iq>

The server MAY include an <instructions/> element and a URL using Out-of-Band Data (e.g., a web page) in the <query/> element (see example above). In-Band Registration recommends that the challenger SHOULD submit the completed x:data form, however if it does not understand the form, then it MAY present the instructions and the included URL to the user instead of providing the required information in-band.

<iq type='set' xml:lang='en' id='reg2'>
  <query xmlns='jabber:iq:register'>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE'>
        <value>urn:xmpp:tmp:challenge</value>
      </field>
      <field var='cid'><value>F3A6292C</value></field>
      <field var='answers'><value>3</value></field>
      <field var='ocr'><value>7nHL3</value></field>
      <field var='username'><value>bill</value></field>
      <field var='password'><value>Calliope</value></field>
    </x>
  </query>
</iq>

5. Multi-User Chat

A service that hosts multi-user chat rooms in accordance with XEP-0045 MAY challenge unknown entities that seek to join such rooms or that send messages in such rooms.

<presence from='robot@abuser.com/zombie'
          to='friendly-chat@muc.victim.com'/>

<message from='muc.victim.com'
         to='robot@abuser.com/zombie'
         id='A4C7303D'>
  <body>
    Your messages to friendly-chat@muc.victim.com are being blocked. To unblock
    them, visit http://www.victim.com/challenge.html?A4C7303D
  </body>
  <x xmlns='jabber:x:oob'>
    <url>http://www.victim.com/challenge.html?A4C7303D</url>
  </x>
  <challenge xmlns='urn:xmpp:tmp:challenge'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:tmp:challenge</value>
      </field>
      <field type='hidden' var='from'><value>muc.victim.com</value></field>
      <field type='hidden' var='sid'><value>spam3</value></field>
      <field var='ocr'>
        <media xmlns='urn:xmpp:tmp:media-element'
               height='80'
               width='290'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/ocr.jpeg?A4C7303D
          </uri>
          <data xmlns='urn:xmpp:tmp:data-element'
                type='image/jpeg'> ** Base64 encoded image ** </data>
        </media>
      </field>
      <field var='picture_recog'>
        <media xmlns='urn:xmpp:tmp:media-element'
               height='150'
               width='150'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/picture.jpeg?A4C7303D
          </uri>
          <data xmlns='urn:xmpp:tmp:data-element'
                type='image/jpeg'> ** Base64 encoded image ** </data>
        </media>
      </field>
      <field var='speech_recog'>
        <media xmlns='urn:xmpp:tmp:media-element'>
          <uri type='audio/x-wav'>
            http://www.victim.com/challenges/speech.wav?A4C7303D
          </uri>
          <uri type='audio/ogg-speex'>
            http://www.victim.com/challenges/speech.ogg?A4C7303D
          </uri>
        </media>
      </field>
      <field var='video_recog'>
        <media xmlns='urn:xmpp:tmp:media-element'
               height='150'
               width='150'>
          <uri type='video/mpeg'>
            http://www.victim.com/challenges/video.mpeg?A4C7303D
          </uri>
        </media>
      </field>
      <field label='Type the color of a stop light' type='text-single' var='qa'/>
      <field label='93C7A' type='text-single' var='SHA-256'/>
    </x>
  </challenge>
</message>

6. Challenge Types

6.1 Introduction

Entities MUST address the needs of disabled people and CPU-constrained clients by offering senders a reasonable choice of different types of challenges.

Desktop clients running on modern PCs will typically be configured to automatically perform a specified 'SHA-256' Hashcash challenge (see below) whenever it is below a certain level of difficulty, with the result that many people may not even notice challenges most of the time. However, people using CPU-constrained clients (e.g. Web or mobile clients) would notice the performance hit. They might prefer to take a CAPTCHA challenge instead. [18]

Visually disabled people using a CPU-constrained client could configure their client to always present them with an audio CAPTCHA challenge.

Most of the challenges below are language sensitive. However, the evaluation of the OCR and Hashcash responses does not depend on the language the sender is using.

Challenge types are distinguished by the 'var' attribute of each <field/> element. Several types of challenges are described below. More challenges MAY be documented elsewhere and registered with the XMPP Registrar (see Field Standardization).

6.2 SHA-256 Hashcash

The SHA-256 Hashcash challenge is transparent to average PC users. It is indicated when the value of the 'var' attribute is 'SHA-256'. It forces clients to perform CPU-intensive work, making it difficult to send large amounts of spim. This significantly reduces spim, but alone it will not completely stop abusive stanzas from being sent through large collections of 'zombie' computers. [19]

The challenger MUST set the 'label' attribute of the <field/> element to a hexadecimal random number containing a configured number of bits (e.g., 220 ≤ label < 221).

To pass the test, the sender MUST return a text string that starts with the JID the sender sent the first stanza to (i.e., the stanza that triggered the challenge). The least significant bits of the SHA-256 hash (see SHA [20]) of the string MUST equal the hexadecimal value specified by the challenger (in the 'label' attribute of the <field/> element). For example, if the 'label' attribute is the 20-bit value 'e03d7' then the following string would be correct:

innocent@victim.com2450F06C173B05E3

Note: When configuring the number of bits to be specified by a challenger in the 'label' attribute values, administrators MUST balance the need to make mass abuse as difficult as possible, with the inconvenience that may be caused to the users of less powerful computers. (Most clients will be challenged only very occasionally, so the consumption of 70% of a typical desktop CPU for 4 seconds might be considered appropriate.) Administrators SHOULD increment the configured number of bits from time to time to match increases in the performance of typical desktop PCs. If an administrator notices that abusive robots never attempt the Hashcash challenge, then he SHOULD consider reducing the number of bits, to avoid inconveniencing people unnecessarily.

6.3 CAPTCHAs

Note: It may be profitable to send abusive stanzas even if less than one percent of CAPTCHA responses are successful. The effectiveness of a CAPTCHA challenge needs to be close to perfect, unless it is used in combination with other anti-abuse techniques.

If a media type is specified (see table below) then the <field/> element MUST contain a <media/> element that includes a <uri/> element of that type. Clients that support the CAPTCHA type MUST be able to play or render the specified MIME-types (see table below). They MAY also support other formats. [21]

The 'type' attribute of the <field/> element SHOULD be 'text-single', 'text-private', or 'text-multi' (if no 'type' is specified, the default is 'text-single'). [22] The response MUST be provided in the language specified by the 'xml:lang' attribute of the challenge stanza.

Table 1: CAPTCHAs

'var'	Name	Media type	MIME-type	Example generic instructions *
audio_recog	Audio Recognition	audio	audio/x-wav	Describe the sound you hear
ocr **	Optical Character Recognition	image	image/jpeg	Enter the code you see
picture_q	Picture Question	image	image/jpeg	Answer the question you see
picture_recog	Picture Recognition	image	image/jpeg	Identify the picture
qa	Text Question and Answer	-	-	-
speech_q	Speech Question	audio	audio/x-wav	Answer the question you hear
speech_recog	Speech Recognition	audio	audio/x-wav	Enter the words you hear
video_q	Video Question	video	video/mpeg	Answer the question in the video
video_recog	Video Recognition	video	video/mpeg	Identify the video

* See the Internationalization Considerations section of this document.

** The image portrays random characters that humans can read but OCR software cannot. [23] To pass the challenge, the sender must simply type the characters. The correct answer SHOULD NOT depend on the language specified by the 'xml:lang' attribute of the challenge stanza.

7. Question and Answer for Legacy Clients

A challenger MAY provide a text question in the <body/> element of a challenge stanza for clients that do not support challenge forms. Entities that cannot serve Out-of-Band Data URLs MAY use this option to challenge legacy clients.

Note: Robots always attempt the easiest challenge they are offered. So the question MUST be at least as difficult for a robot as the challenge form.

Note: Even if it provides a text question in the <body/> element, a challenger MUST always provide a challenge form.

<message from='innocent@victim.com/pda'
    to='robot@abuser.com/zombie'
    xml:lang='en'
    id='F3A6292C'>
  <body>Your messages to me are being blocked. To unblock them,
    reply with the color of a stop light followed by 'F3A6292C'.</body>
  <challenge xmlns='urn:xmpp:tmp:challenge'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:tmp:challenge</value>
      </field>
      <field type='hidden' var='from'><value>innocent@victim.com</value></field>
      <field type='hidden' var='sid'><value>spam1</value></field>
      <field label='Type the color of a stop light' type='text-single' var='qa'/>
      <field label='93C7A' type='text-single' var='SHA-256'/>
    </x>
  </challenge>
</message>

Legacy clients respond to the challenger using a <message/> stanza (not an <iq/>).

<message from='robot@abuser.com/zombie' to='innocent@victim.com/pda'>
  <body>red F3A6292C</body>
</message>

The challenger SHOULD treat the stanza as a normal message (instead of as a response to its challenge) if the legacy client either takes too long to submit it or has already responded to the challenge. The challenger MAY treat the response as a normal message even in cases where the challenge became unnecessary while the challenger was waiting for the response.

Otherwise the challenger MUST report the result of the challenge to the legacy client using a <message/> stanza (not an <iq/>).

<message from='innocent@victim.com/pda' to='robot@abuser.com/zombie'>
  <body>Your message was delivered. Your messages
        to me are no longer being blocked.</body>
</message>

<message type='error'
         from='innocent@victim.com/pda'
         to='robot@abuser.com/zombie'>
  <error type='cancel'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
      Your message to me was not delivered.
    </text>
  </error>
</message>

8. Discontinuation Policy

It is expected that this protocol will be an important and successful tool for discouraging spim. However, much of its success is dependent on the quality of the CAPTCHAs employed by a particular implementation.

The administrator of a challenger MUST discontinue the use of Robot Challenges under the following circumstances:

9. Internationalization Considerations

Each form field SHOULD include a 'label' attribute. If the sender did not include an 'xml:lang' attribute, then the challenger may not know the correct language for the labels. Therefore, depending on user preferences the client that receives a challenge MAY present generic but localized text instead of label text that would not be understood by the user. Recommended generic text (to be suitably localized) is provided by Table 1 in the CAPTCHAs section of this document.

10. Security Considerations

This document introduces no security considerations above and beyond those described in RFC 3920 and RFC 3921.

11. IANA Considerations

12. XMPP Registrar Considerations

12.1 Protocol Namespaces

Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-00158.html#ns"; upon advancement of this specification, the XMPP Registrar [26] shall issue a permanent namespace in accordance with the process defined in Section 4 of XMPP Registrar Function [27].

12.2 Field Standardization

12.2.1 challenge FORM_TYPE

Upon approval of this document, the XMPP Registrar shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.

<form_type>
  <name>urn:xmpp:tmp:challenge</name>
  <doc>XEP-0158</doc>
  <desc>forms enabling robot challenges</desc>
  <field
      var='answers'
      type='hidden'
      label='number of answers required'/>
  <field
      var='audio_recog'
      type='text-single'
      label='text associated with a sound'/>
  <field
      var='cid'
      type='hidden'
      label='challenge ID'/>
  <field
      var='from'
      type='hidden'
      label='to attribute of stanza that triggered challenge'/>
  <field
      var='ocr'
      type='text-single'
      label='code appearing in an image'/>
  <field
      var='picture_q'
      type='text-single'
      label='answer associated with a picture'/>
  <field
      var='picture_recog'
      type='text-single'
      label='text associated with a picture'/>
  <field
      var='qa'
      type='text-single'
      label='answer to a question'/>
  <field
      var='SHA-256'
      type='text-single'
      label='least significant bits of SHA-256 hash of text should equal hexadecimal label'/>
  <field
      var='sid'
      type='hidden'
      label='stanza ID'/>
  <field
      var='speech_q'
      type='text-single'
      label='answer associated with speech'/>
  <field
      var='speech_recog'
      type='text-single'
      label='text associated with speech'/>
  <field
      var='video_q'
      type='text-single'
      label='answer associated with a video'/>
  <field
      var='video_recog'
      type='text-single'
      label='text associated with a video'/>
</form_type>

12.2.2 jabber:iq:register FORM_TYPE

Upon approval of this document, the XMPP Registrar shall register the following new fields for the existing jabber:iq:register FORM_TYPE. Additional fields will be defined in future submissions.

<form_type>
  <name>jabber:iq:register</name>
  <doc>XEP-0077</doc>
  <field
      var='answers'
      type='hidden'
      label='number of answers required'/>
  <field
      var='audio_recog'
      type='text-single'
      label='text associated with a sound'/>
  <field
      var='cid'
      type='hidden'
      label='challenge ID'/>
  <field
      var='ocr'
      type='text-single'
      label='code appearing in an image'/>
  <field
      var='picture_q'
      type='text-single'
      label='answer associated with a picture'/>
  <field
      var='picture_recog'
      type='text-single'
      label='text associated with a picture'/>
  <field
      var='qa'
      type='text-single'
      label='answer to a question'/>
  <field
      var='SHA-256'
      type='text-single'
      label='least significant bits of SHA-256 hash of text should equal hexadecimal label'/>
  <field
      var='speech_q'
      type='text-single'
      label='answer associated with speech'/>
  <field
      var='speech_recog'
      type='text-single'
      label='text associated with speech'/>
  <field
      var='video_q'
      type='text-single'
      label='answer associated with a video'/>
  <field
      var='video_recog'
      type='text-single'
      label='text associated with a video'/>
</form_type>

13. XML Schema

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:tmp:challenge'
    xmlns='urn:xmpp:tmp:challenge'
    elementFormDefault='qualified'>

  <xs:element name='challenge'>
    <xs:complexType>
      <xs:sequence xmlns:xdata='jabber:x:data'>
        <xs:element ref='xdata:x' minOccurs='1' maxOccurs='1'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>

14. Open Issues

Another protocol could allow users to edit the challenges their server will make on their behalf. For example, the number of SHA-256 bits, a personal or original question and answer, a picture, a video, or a sound recording. Of course Aunt Tillie would typically use this feature only if she was plagued by spim.

Notes

1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

2. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.

3. Hashcash <http://hashcash.org/>.

4. XEP-0077: In-Band Registration <http://www.xmpp.org/extensions/xep-0077.html>.

5. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.

6. XEP-0159: SPIM-Blocking Control <http://www.xmpp.org/extensions/xep-0159.html>.

7. Inaccessibility of Visually-Oriented Anti-Robot Tests <http://www.w3.org/TR/turingtest/>.

8. XEP-0004: Data Forms <http://www.xmpp.org/extensions/xep-0004.html>.

9. XEP-0221: Data Forms Media Element <http://www.xmpp.org/extensions/xep-0221.html>.

10. XEP-0068: Field Data Standardization for Data Forms <http://www.xmpp.org/extensions/xep-0068.html>.

11. XEP-0066: Out of Band Data <http://www.xmpp.org/extensions/xep-0066.html>.

12. A constrained client, like a mobile phone, cannot present a Web page to its user.

13. Otherwise the user's presence would be disclosed, or a robot might dupe the user into providing answers to other people's challenges!

14. If the challenger is a client then it SHOULD be careful not to leak information about the presence of the sender and reply to potentially bogus challenge responses with exactly the same XML that its server would send if the sender were offline.

15. If a large proportion of the responses a server is receiving from another IP are incorrect then it SHOULD inform the administrator of the other server using the protocol specified in SPIM Reporting [16] or Abuse Reporting [17]. It SHOULD also automatically block all stanzas from the abusive user, users, server or IP.

16. XEP-0161: SPIM Reporting <http://www.xmpp.org/extensions/xep-0161.html>.

17. XEP-0236: Abuse Reporting <http://www.xmpp.org/extensions/xep-0236.html>.

18. A CPU-constrained client could ask a faster computer (e.g., its server) to perform a Hashcash challenge for it.

19. The hope is that the extra CPU usage will often be noticed by the owners of the zombie machines, who will be more likely to fix them.

20. Secure Hash Standard: Federal Information Processing Standards Publication 180-2 <http://csrc.nist.gov/publications/fips/fips180-2/fips186-2withchangenotice.pdf>.

21. Audio CAPTCHAs typically require challengers to provide at least the 'audio/x-wav' MIME-type (with the PCM codec) because more efficient patent-free formats are often not supported by constrained clients. It is RECOMMENDED that challengers provide more compact formats (like Ogg Speex or MP3) too.

22. The 'boolean' and 'list-single' field types would make it trivial for a robot to provide a correct response at least some of the time.

23. See PWNtcha <http://sam.zoy.org/pwntcha/> for some example OCR CAPTCHA images.

24. XEP-0205: Best Practices to Discourage Denial of Service Attacks <http://www.xmpp.org/extensions/xep-0205.html>.

25. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

26. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.

27. XEP-0053: XMPP Registrar Function <http://www.xmpp.org/extensions/xep-0053.html>.