xep-0158.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>CAPTCHA Forms</title>
  <abstract>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.</abstract>
  &LEGALNOTICE;
  <number>0158</number>
  <status>Draft</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XMPP IM</spec>
    <spec>XEP-0004</spec>
    <spec>XEP-0066</spec>
    <spec>XEP-0221</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>captcha</shortname>
  <schemaloc>
    <url>http://xmpp.org/schemas/captcha.xsd</url>
  </schemaloc>
  &ianpaterson;
  &stpeter;
  <revision>
    <version>1.0.1</version>
    <date>2019-11-07</date>
    <initials>egp, mb</initials>
    <remark><p>Use the correct FORM_TYPE for extended IBR, and use a proper MUC join as an example. Also fix typos.</p></remark>
  </revision>
  <revision>
    <version>1.0</version>
    <date>2008-09-03</date>
    <initials>psa</initials>
    <remark><p>Per a vote of the XMPP Council, advanced status to Draft; concurrently, the XMPP Registrar issued the urn:xmpp:captcha namespace; also changed element name from challenge to captcha in order to match the namespace name.</p></remark>
  </revision>
  <revision>
    <version>0.11</version>
    <date>2008-08-06</date>
    <initials>psa</initials>
    <remark><p>Further modified examples to track changes to XEP-0231.</p></remark>
  </revision>
  <revision>
    <version>0.10</version>
    <date>2008-08-06</date>
    <initials>psa</initials>
    <remark><p>Modified examples to track changes to XEP-0231; to avoid confusion with cid URIs, changed name of challenge ID form field from cid to challenge.</p></remark>
  </revision>
  <revision>
    <version>0.9</version>
    <date>2008-05-12</date>
    <initials>psa</initials>
    <remark><p>Specified that cid field is required; more clearly defined structure of challenge stanza; added several security considerations; corrected several errors in the text and examples.</p></remark>
  </revision>
  <revision>
    <version>0.8</version>
    <date>2008-05-12</date>
    <initials>psa</initials>
    <remark><p>Moved text regarding labels to new internationalization considerations section; removed necessity that ID of IQ-set shall match ID of challenge, since this is not consistent with existing usage that IDs are generated by the sender of an IQ.</p></remark>
  </revision>
  <revision>
    <version>0.7</version>
    <date>2008-04-28</date>
    <initials>psa</initials>
    <remark><p>Generalized text to cover abuse rather than just spim; modified temporary namespace to adhere to XMPP Registrar procedures; added use case for joining multi-user chat rooms.</p></remark>
  </revision>
  <revision>
    <version>0.6</version>
    <date>2007-07-11</date>
    <initials>psa/ip</initials>
    <remark><p>Moved media element definition to XEP-0221; consistently used the terms sender and challenger rather than client and entity; modified provisional namespaces to adhere to XMPP Registrar policies; completed editorial review.</p></remark>
  </revision>
  <revision>
    <version>0.5</version>
    <date>2006-10-30</date>
    <initials>ip</initials>
    <remark><p>Added reference to SPIM Reporting.</p></remark>
  </revision>
  <revision>
    <version>0.4</version>
    <date>2005-09-30</date>
    <initials>ip</initials>
    <remark><p>Required WAV instead of MP3 for audio CAPTCHAs; minor corrections.</p></remark>
  </revision>
  <revision>
    <version>0.3</version>
    <date>2005-09-28</date>
    <initials>ip</initials>
    <remark><p>Added more CAPTCHA types and the legacy question and answer section.</p></remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2005-09-14</date>
    <initials>ip</initials>
    <remark><p>Minor fixes.</p></remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2005-09-14</date>
    <initials>ip</initials>
    <remark><p>Initial version.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2005-09-07</date>
    <initials>ip</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>

<section1 topic='Introduction' anchor='intro'>
  <p>The appearance of large public IM services based on &xmppcore; and &xmppim; makes it desirable to implement protocols that <em>discourage</em> 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 stanzas could take many forms; a full taxonomy is outside the scope of this document.</p>
  <p>One technique developed to combat abusive messages and behavior via non-XMPP technologies requires humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see &lt;<link url='http://www.captcha.net/'>http://www.captcha.net/</link>&gt;). 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.</p>
  <p>An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a <span class='ref'>Hashcash</span> <note>Hashcash &lt;<link url='http://hashcash.org/'>http://hashcash.org/</link>&gt;.</note> 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 abusive traffic.</p>
  <p>Both CAPTCHAs and hashcash have been criticized regarding their effectiveness (or lack thereof). Therefore, the challenge protocol specified herein provides a great deal of flexibility, so that challenges can include CAPTCHAs, hashcash, word puzzles, so-called kitten authentication, and any other mechanism that may be developed in the future.</p>
  <p>The generic challenge protocol described in this document is designed for incorporation into protocols such as &xep0077;, &xep0045;, &xep0016;, and &xep0159;.</p>
</section1>

<section1 topic='Requirements' anchor='require'>
  <section2 topic='Extensibility' anchor='require-extend'>
    <p>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.</p>
  </section2>
  <section2 topic='Variety' anchor='require-variety'>
    <p>Several common CAPTCHA techniques present major problems to users with disabilities (see &w3turingtest;). 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.</p>
  </section2>
</section1>

<section1 topic='Protocol' anchor='protocol'>
  <section2 topic='Simple Challenge' anchor='protocol-simple'>
    <section3 topic='Triggering Stanza' anchor='protocol-trigger'>
      <p>A "triggering stanza" is an XMPP &MESSAGE;, &PRESENCE;, or &IQ; stanza that is deemed abusive by the receiving entity (e.g., a client) or an intermediate router (e.g., a server). The entity that generates a triggering stanza is called a "sender".</p>
      <example caption='Sender Generates Triggering Stanza'><![CDATA[
<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>
]]></example>
    </section3>
    <section3 topic='Challenge Stanza' anchor='protocol-challenge'>
     <p>Upon receiving a triggering stanza, an entity MAY send a "challenge stanza". An entity MUST NOT send a challenge stanza under any other circumstances. The entity that generates the challenge stanza is called the "challenger".</p>
    <p>The challenge stanza consists of an XMPP &MESSAGE; stanza containing a data form for the sender to fill out, formatted according to &xep0004;, optionally along with a &BODY; and other elements. The following rules apply to the challenge stanza.</p>
    <ol>
      <li>The challenge stanza MUST include an 'id' attribute set to the challenge ID (i.e., a unique identifier for this challenge within the challenger's application).</li>
      <li>The challenge stanza SHOULD include a &BODY; element that provides an explanation of the challenge for clients that do not yet support CAPTCHA forms.</li>
      <li>The challenge stanza MAY include a URL (typically a Web page with instructions) using &xep0066; as an alternative for clients that do not yet support CAPTCHA forms.</li>
      <li>The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the sender, if any.</li>
      <li>The challenge stanza MUST include a CAPTCHA form, i.e., a data form of type "form" containing one or more challenges. <note>Inclusion of a CAPTCHA form not only makes it possible to flexibly support or require a large number of challenge types, but also enables constrained clients to respond to challenges (e.g., mobile phone clients that cannot present web pages, or clients on XMPP-only networks).</note></li>
      <li>The CAPTCHA form MUST include a hidden field named "FORM_TYPE" (in accordance with &xep0068;) whose value MUST be "urn:xmpp:captcha".</li>
      <li>The CAPTCHA form MUST include a hidden field named "challenge" set to the challenge ID.</li>
      <li>The CAPTCHA form MUST include a hidden field named "from" set to the value of the 'to' attribute from the triggering stanza.</li>
      <li>If the triggering stanza included an 'id' attribute, then the CAPTCHA form MUST include a hidden field named "sid" set to that value.</li>
      <li>Each of the CAPTCHA form's non-hidden &lt;field/&gt; elements MAY contain a different challenge.</li>
      <li>Each CAPTCHA field MAY contain a media element (see &xep0221;) that in turn contains a pointer to media that the sender shall use in solving puzzles, performing optical character recognition, identifying audio or video samples, etc. When the sender replies to a media element via a data form of type "submit", the field type SHOULD be "text-single" (which is the default for data form fields) but MAY in turn include a media element if acceptable to the challenger application.</li>
    </ol>
    <example caption='Challenger Offers a Choice of Challenges to Sender'><![CDATA[
<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>
  <captcha xmlns='urn:xmpp:captcha'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:captcha</value>
      </field>
      <field type='hidden' var='from'><value>innocent@victim.com</value></field>
      <field type='hidden' var='challenge'><value>F3A6292C</value></field>
      <field type='hidden' var='sid'><value>spam1</value></field>
      <field var='ocr' label='Enter the text you see'>
        <media xmlns='urn:xmpp:media-element'
               height='80'
               width='290'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/ocr.jpeg?F3A6292C
          </uri>
          <uri type='image/jpeg'>
            cid:sha1+f24030b8d91d233bac14777be5ab531ca3b9f102@bob.xmpp.org
          </uri>
        </media>
      </field>
      <field var='picture_recog' label='Identify the picture'>
        <media xmlns='urn:xmpp:media-element'
               height='150'
               width='150'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/picture.jpeg?F3A6292C
          </uri>
          <uri type='image/jpeg'>
            cid:sha1+f2377f3a3287eac81028243079e1aa9905c466bc@bob.xmpp.org
          </uri>
        </media>
      </field>
      <field var='speech_recog' label='Enter the words you hear'>
        <media xmlns='urn:xmpp: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' label='Identity the video'>
        <media xmlns='urn:xmpp: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>
  </captcha>
</message>
]]></example>
      <p>The sender then would retrieve the media data via HTTP or (for the cid: URIs) via XMPP as described in &xep0231;.</p>
    </section3>

    <section3 topic='Response Stanza' anchor='protocol-response'>
    <p>The sender's client SHOULD ignore the challenge stanza in either of the following cases:</p>
    <ul>
      <li>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). <note>Otherwise the user's presence would be disclosed, or a robot might dupe the user into providing answers to other people's challenges!</note></li>
      <li>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.)</li>
    </ul>
    <p>Otherwise, if the challenger provided a URL using <cite>Out-of-Band Data</cite>, then the sender's client MAY present the URL to the sender, instead of responding to the CAPTCHA form, in any of the following cases:</p>
    <ul>
      <li>if it does not understand the CAPTCHA form</li>
      <li>if it does not support all of the <em>required</em> challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
      <li>if it does not support enough of the challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
    </ul>
    <p>Otherwise, the sender's client MUST respond to the challenge.</p>
    <p>The sender's client MUST respond with a &notacceptable; error in any of the following cases:</p>
    <ul>
      <li>if it does not support all of the required challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
      <li>if it does not support enough of the challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
      <li>if the sender declines the challenge</li>
    </ul>
    <example caption='Sender Reports Challenge Not Acceptable'><![CDATA[
<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>
]]></example>
    <p>Otherwise, it MUST select one challenge according to the sender's preferences and submit the sender's response form to the challenger.</p>
    <example caption='Sender Sends One Response to Challenger'><![CDATA[
<iq type='set'
    from='robot@abuser.com/zombie'
    to='victim.com'
    xml:lang='en'
    id='z140r0s'>
  <captcha xmlns='urn:xmpp:captcha'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>urn:xmpp:captcha</value>
      </field>
      <field var='from'><value>innocent@victim.com</value></field>
      <field var='challenge'><value>F3A6292C</value></field>
      <field var='sid'><value>spam1</value></field>
      <field var='ocr'><value>7nHL3</value></field>
    </x>
  </captcha>
</iq>
]]></example>
    </section3>

    <section3 topic='Result Stanza' anchor='protocol-result'>
    <p>The challenger SHOULD send a &unavailable; error to the sender if:</p>
    <ul>
      <li>The challenger did not send the specified challenge. <note>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.</note></li>
      <li>The sender already submitted its response to this challenge.</li>
      <li>The sender took too long to submit its response.</li>
    </ul>
    <p>Note: This error MAY be sent even in cases where the challenge became unnecessary while the challenger was waiting for the response.</p>
    <example caption='Challenger Indicates Challenge Not Found'><![CDATA[
<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>
]]></example>
    <p>After receiving a correct response to its challenge, the challenger SHOULD inform the sender that it was successful.</p>
    <example caption='Challenger Tells Sender it Passed'><![CDATA[
<iq type='result'
    from='victim.com'
    to='robot@abuser.com/zombie'
    id='z140r0s'/>
]]></example>
    <p>However, if the sender submits an incorrect response the challenger SHOULD send it a &notacceptable; error with type "cancel": <note>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 &xep0161; or &xep0236;. It SHOULD also automatically block all stanzas from the abusive user, users, server or IP.</note></p>
    <example caption='Challenger Tells Sender it Failed'><![CDATA[
<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>
]]></example>
    </section3>
  </section2>
  <section2 topic='Multiple Challenges' anchor='protocol-multiple'>
    <p>The challenger MAY demand responses to more than one of the challenges it is offering; this is done by including an 'answers' &lt;field/&gt; element in the form, which specifies how many answers the sender needs to include. The challenger also MAY require responses to particular challenges; this is done by including a &lt;required/&gt; element in the compulsory fields.</p>
    <example caption='Challenger Sets Multiple Challenges'><![CDATA[
<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>
  <captcha xmlns='urn:xmpp:captcha'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:captcha</value>
      </field>
      <field type='hidden' var='from'><value>innocent@victim.com</value></field>
      <field type='hidden' var='challenge'><value>73DE28A2</value></field>
      <field type='hidden' var='sid'><value>spam2</value></field>
      <field type='hidden' var='answers'><value>2</value></field>
      <field var='ocr' label='Enter the text you see'>
        <media xmlns='urn:xmpp:media-element'
               height='80'
               width='290'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/ocr.jpeg?F3A6292C
          </uri>
          <uri type='image/jpeg'>
            cid:sha1+f24030b8d91d233bac14777be5ab531ca3b9f102@bob.xmpp.org
          </uri>
        </media>
      </field>
      <field var='audio_recog' label='Describe the sound you hear'>
        <media xmlns='urn:xmpp: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>
  </captcha>
</message>
]]></example>

    <p>If the sender finds the request acceptable, it MUST answer all challenges that include a &lt;required/&gt; element. If the total number of answers was specified and it is greater than the number of &lt;required/&gt; elements then the sender MUST also answer one or more of the challenges without a &lt;required/&gt; element. In the example above, the sender should respond to the 'qa' challenge <em>and</em> one of the other challenges ('ocr', 'audio_recog' or 'SHA-256').</p>
    <example caption='Sender Sends Multiple Responses to the Challenger'><![CDATA[
<iq type='set'
    from='robot@abuser.com/zombie'
    to='victim.com'
    xml:lang='en'
    id='73DE28A2'>
  <captcha xmlns='urn:xmpp:captcha'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>urn:xmpp:captcha</value>
      </field>
      <field var='from'><value>innocent@victim.com</value></field>
      <field var='challenge'><value>73DE28A2</value></field>
      <field var='sid'><value>spam2</value></field>
      <field var='answers'><value>2</value></field>
      <field var='qa'><value>red</value></field>
      <field var='SHA-256'><value>innocent@victim.com2450F06C173B05E3</value></field>
    </x>
  </captcha>
</iq>
]]></example>
    <p>The challenger MAY decide the sender has passed a challenge even if the responses are not all perfectly correct.</p>
  </section2>
</section1>

<section1 topic='Extended In-Band Registration' anchor='register'>
  <p>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 <cite>XEP-0077</cite>.</p>
  <p>Note: The &lt;challenge/&gt; wrapper element is not included, because <cite>XEP-0077</cite> specifies that data forms shall be contained as the direct children of the &QUERY; element.</p>
  <example caption='Entity Requests Registration Fields from Host'><![CDATA[
<iq type='get' xml:lang='en' id='reg1'>
  <query xmlns='jabber:iq:register'/>
</iq>
]]></example>
  <p>Note that the CAPTCHA form MUST be inside the &QUERY; element, and the server's challenge ID is specified within the form:</p>
  <example caption='Host Returns Registration and Challenge Fields to Entity'><![CDATA[
<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>jabber:iq:register</value>
      </field>
      <field type='hidden' var='challenge'><value>F3A6292C</value></field>
      <field type='hidden' var='sid'><value>reg1</value></field>
      <field type='hidden' var='answers'><value>3</value></field>
      <field var='ocr' label='Enter the text you see'>
        <media xmlns='urn:xmpp: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-private' 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>
]]></example>
  <p>The server MAY include an &lt;instructions/&gt; element and a URL using <cite>Out-of-Band Data</cite> (e.g., a web page) in the &QUERY; element (see example above). <cite>In-Band Registration</cite> 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.</p>
  <example caption='Entity Provides Required Information In-Band'><![CDATA[
<iq type='set' xml:lang='en' id='reg2'>
  <query xmlns='jabber:iq:register'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>jabber:iq:register</value>
      </field>
      <field var='challenge'><value>F3A6292C</value></field>
      <field var='sid'><value>reg1</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>
]]></example>
</section1>

<section1 topic='Multi-User Chat' anchor='muc'>
  <p>A service that hosts multi-user chat rooms in accordance with <cite>XEP-0045</cite> MAY challenge unknown entities that seek to join such rooms or that send messages in such rooms.</p>
  <example caption='Sender Attempts to Join Chat Room'><![CDATA[
<presence from='robot@abuser.com/zombie'
          to='friendly-chat@muc.victim.com/robot101'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>
]]></example>
  <example caption='Challenger Offers a Choice of Challenges to Sender'><![CDATA[
<message from='friendly-chat@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>
  <captcha xmlns='urn:xmpp:captcha'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:captcha</value>
      </field>
      <field type='hidden' var='from'><value>friendly-chat@muc.victim.com</value></field>
      <field type='hidden' var='challenge'><value>A4C7303D</value></field>
      <field var='ocr' label='Enter the text you see'>
        <media xmlns='urn:xmpp:media-element'
               height='80'
               width='290'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/ocr.jpeg?A4C7303D
          </uri>
        </media>
      </field>
      <field var='picture_recog' label='Identify the picture'>
        <media xmlns='urn:xmpp:media-element'
               height='150'
               width='150'>
          <uri type='image/jpeg'>
            http://www.victim.com/challenges/picture.jpeg?A4C7303D
          </uri>
          <uri type='image/jpeg'>
            cid:sha1+f2377f3a3287eac81028243079e1aa9905c466bc@bob.xmpp.org
          </uri>
        </media>
      </field>
      <field var='speech_recog' label='Enter the words you hear'>
        <media xmlns='urn:xmpp: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' label='Identity the video'>
        <media xmlns='urn:xmpp: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>
  </captcha>
</message>
]]></example>
</section1>

<section1 topic='Challenge Types' anchor='challenge'>
  <section2 topic='Introduction' anchor='challenge-intro'>
    <p>Entities MUST address the needs of disabled people and CPU-constrained clients by offering senders a reasonable choice of different types of challenges.</p>
    <p>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. <note>A CPU-constrained client could ask a faster computer (e.g., its server) to perform a Hashcash challenge for it.</note></p>
    <p>Visually disabled people using a CPU-constrained client could configure their client to always present them with an audio CAPTCHA challenge.</p>
    <p>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.</p>
    <p>Challenge types are distinguished by the 'var' attribute of each &lt;field/&gt; element. Several types of challenges are described below. More challenges MAY be documented elsewhere and registered with the XMPP Registrar (see <link url='#registrar-formtypes'>Field Standardization</link>).</p>
  </section2>
  <section2 topic='SHA-256 Hashcash' anchor='challenge-hashcash'>
    <p>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 abusive traffic. This significantly reduces abusive traffic, but alone it will not completely stop abusive stanzas from being sent through large collections of 'zombie' computers. <note>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.</note></p>
    <p>The challenger MUST set the 'label' attribute of the &lt;field/&gt; element to a hexadecimal random number containing a configured number of bits (e.g., 2<span class='super'>20</span> &#8804; label &lt; 2<span class='super'>21</span>).</p>
    <p>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 &nistfips180-2;) of the string MUST equal the hexadecimal value specified by the challenger (in the 'label' attribute of the &lt;field/&gt; element). For example, if the 'label' attribute is the 20-bit value 'e03d7' then the following string would be correct:</p>
    <code>innocent@victim.com2450F06C173B05E3</code>
    <p>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.</p>
  </section2>
  <section2 topic='CAPTCHAs' anchor='challenge-captcha'>
    <p>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.</p>
    <p>If a media type is specified (see table below) then the &lt;field/&gt; element MUST contain a &lt;media/&gt; element that includes a &lt;uri/&gt; 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. <note>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.</note></p>
    <p>The 'type' attribute of the &lt;field/&gt; element SHOULD be 'text-single', 'text-private', or 'text-multi' (if no 'type' is specified, the default is 'text-single'). <note>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.</note> The response MUST be provided in the language specified by the 'xml:lang' attribute of the challenge stanza.</p>
    <table caption='CAPTCHAs'>
      <tr>
        <th>'var'</th>
        <th>Name</th>
        <th>Media type</th>
        <th>MIME-type</th>
        <th>Suggested generic instructions *</th>
      </tr>
      <tr>
        <td>audio_recog</td>
        <td>Audio Recognition</td>
        <td>audio</td>
        <td>audio/x-wav</td>
        <td>Describe the sound you hear</td>
      </tr>
      <tr>
        <td>ocr **</td>
        <td>Optical Character Recognition</td>
        <td>image</td>
        <td>image/jpeg</td>
        <td>Enter the text you see</td>
      </tr>
      <tr>
        <td>picture_q</td>
        <td>Picture Question</td>
        <td>image</td>
        <td>image/jpeg</td>
        <td>Answer the question you see</td>
      </tr>
      <tr>
        <td>picture_recog</td>
        <td>Picture Recognition</td>
        <td>image</td>
        <td>image/jpeg</td>
        <td>Identify the picture</td>
      </tr>
      <tr>
        <td>qa</td>
        <td>Text Question and Answer</td>
        <td>-</td>
        <td>-</td>
        <td>-</td>
      </tr>
      <tr>
        <td>speech_q</td>
        <td>Speech Question</td>
        <td>audio</td>
        <td>audio/x-wav</td>
        <td>Answer the question you hear</td>
      </tr>
      <tr>
        <td>speech_recog</td>
        <td>Speech Recognition</td>
        <td>audio</td>
        <td>audio/x-wav</td>
        <td>Enter the words you hear</td>
      </tr>
      <tr>
        <td>video_q</td>
        <td>Video Question</td>
        <td>video</td>
        <td>video/mpeg</td>
        <td>Answer the question in the video</td>
      </tr>
      <tr>
        <td>video_recog</td>
        <td>Video Recognition</td>
        <td>video</td>
        <td>video/mpeg</td>
        <td>Identify the video</td>
      </tr>
    </table>
    <p>* See the <link url='#i18n'>Internationalization Considerations</link> section of this document.</p>
    <p>** The image portrays random characters that humans can read but OCR software cannot. <note>See PWNtcha &lt;<link url='http://sam.zoy.org/pwntcha/'>http://sam.zoy.org/pwntcha/</link>&gt; for some example OCR CAPTCHA images.</note> 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.</p>
  </section2>
</section1>

<section1 topic='Question and Answer for Legacy Clients' anchor='legacy'>
  <p>A challenger MAY provide a text question in the &BODY; element of a challenge stanza for clients that do not support CAPTCHA forms. Entities that cannot serve <cite>Out-of-Band Data</cite> URLs MAY use this option to challenge legacy clients.</p>
  <!-- It also allows entities to provide a challenge for minimal legacy clients that do not support <cite>Out-of-Band Data</cite> URLs (these don't exist). -->
  <p>Note: Robots always attempt the easiest challenge they are offered. So the question MUST be at least as difficult for a robot as the CAPTCHA form.</p>
  <p>Note: Even if it provides a text question in the &BODY; element, a challenger MUST always provide a CAPTCHA form.</p>
  <example caption='Challenger Includes a Legacy Challenge'><![CDATA[
<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>
  <captcha xmlns='urn:xmpp:captcha'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:captcha</value>
      </field>
      <field type='hidden' var='from'><value>innocent@victim.com</value></field>
      <field type='hidden' var='challenge'><value>F3A6292C</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>
  </captcha>
</message>
]]></example>
  <p>Legacy clients respond to the challenger using a &MESSAGE; stanza (not an &IQ;).</p>
  <example caption='Legacy Sender Responds'><![CDATA[
<message from='robot@abuser.com/zombie' to='innocent@victim.com/pda'>
  <body>red F3A6292C</body>
</message>
]]></example>
  <p>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.</p>
  <p>Otherwise the challenger MUST report the result of the challenge to the legacy client using a &MESSAGE; stanza (not an &IQ;).</p>
  <example caption='Challenger Tells Legacy Sender it Passed'><![CDATA[
<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>
]]></example>
  <example caption='Challenger Tells Legacy Sender it Failed'><![CDATA[
<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>
]]></example>
</section1>

<section1 topic='Discontinuation Policy' anchor='stop'>
  <p>It is RECOMMENDED that entities employ other techniques to combat abusive stanzas in addition to those described in this document (e.g., see <cite>XEP-0161</cite> and &xep0205;).</p>
  <p>It is expected that this protocol will be an important and successful tool for discouraging abusive traffic. However, much of its success is dependent on the quality of the CAPTCHAs and other puzzles employed by a particular implementation.</p>
  <p>The administrator of an application that functions as a challenger SHOULD discontinue the use of CAPTCHA forms under the following circumstances:</p>
  <ul>
    <li>If he realises that the challenger's challenges are largely ineffective in combating abusive traffic, and that the reduction in abuse does not compensate for the inconvenience to humans of responding to the challenger's challenges.</li>
    <li>If other, <em>more transparent</em>, techniques being employed by the challenger are so successful that challenges are offering only negligible additional protection against abusive traffic.</li>
    <li>If the challenger needs no protection at all because it receives only a negligible amount of abusive traffic.</li>
  </ul>
</section1>

<section1 topic='Internationalization Considerations' anchor='i18n'>
  <p>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. Suggested generic text (to be suitably localized) is provided by <link url='#table-1'>Table 1</link> in the <link url='#challenge-captcha'>CAPTCHAs</link> section of this document.</p>
</section1>

<section1 topic='Security Considerations' anchor='sec'>
  <p>The use of CAPTCHAs is not a panacea, and should be combined with other anti-abuse mechanisms, such as those described in <cite>XEP-0161</cite> and <cite>XEP-0205</cite>. For example, the task of finding solutions to CAPTCHAs and other computational puzzles is becoming easier for computer programs, and in any case can be farmed out to third parties. Therefore challengers should limit the number of triggering stanzas (e.g., registration attempts, subscription requests, or chatroom joins) allowed per JabberID or IP address during any given time period, and may simply refuse repeated stanzas by terminating an XML stream with a &policy; stream error or returning a &notacceptable; stanza error as appropriate. In addition, a challenger should feel free to deploy additional anti-abuse mechanisms as needed.</p>
</section1>

<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document requires no interaction with &IANA;. </p>
</section1>

<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <section2 topic='Protocol Namespaces' anchor='ns'>
    <p>The &REGISTRAR; includes "urn:xmpp:captcha" in its registry of protocol namespaces (see &NAMESPACES;).</p>
  </section2>
  <section2 topic='Field Standardization' anchor='registrar-formtypes'>
    <section3 topic='CAPTCHA FORM_TYPE' anchor='registrar-formtypes-captcha'>
      <p>The <cite>XMPP Registrar</cite> registers following FORM_TYPE. Additional fields might be defined in future submissions.</p>
      <code><![CDATA[
<form_type>
  <name>urn:xmpp:captcha</name>
  <doc>XEP-0158</doc>
  <desc>Forms enabling the use of CAPTCHAs.</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='challenge'
      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>
]]></code>
    </section3>
    <section3 topic='jabber:iq:register FORM_TYPE' anchor='registrar-formtypes-register'>
      <p>The <cite>XMPP Registrar</cite> registers the following fields for the existing jabber:iq:register FORM_TYPE. Additional fields might be defined in future submissions.</p>
      <code><![CDATA[
<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='challenge'
      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='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>
]]></code>
    </section3>
  </section2>
</section1>

<section1 topic='XML Schema' anchor='schema'>
  <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>

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

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0158: http://xmpp.org/extensions/xep-0158.html
    </xs:documentation>
  </xs:annotation>

  <xs:import namespace='jabber:x:data'
             schemaLocation='http://xmpp.org/schemas/x-data.xsd'/>

  <xs:element name='captcha'>
    <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>
]]></code>

</section1>

<section1 topic='Open Issues' anchor='open'>
  <p>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 abusive traffic.</p>
</section1>

</xep>