<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>
<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>
<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>
<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>
<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>
<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>
<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>
<p>The appearance of large public IM services based on &rfc3920; and &rfc3921; 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 stanas 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 <<linkurl='http://www.captcha.net/'>http://www.captcha.net/</link>>). 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 <spanclass='ref'>Hashcash</span><note>Hashcash <<linkurl='http://hashcash.org/'>http://hashcash.org/</link>>.</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>
<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>
<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>
<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>
<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 challange 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 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 "cid" 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 <field/> 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>
<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>
<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>
<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>
<p>However, if the sender submits an incorrect response the challenger SHOULD send it a ¬acceptable; 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>
<p>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, 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 <required/> element in the compulsory fields.</p>
<p>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 <em>and</em> one of the other challenges ('ocr', 'audio_recog' or 'SHA-256').</p>
<examplecaption='Sender Sends Multiple Responses to the Challenger'><