[Standards-JIG] bot-challenge proto-JEP

Peter Saint-Andre stpeter at jabber.org
Wed Aug 31 17:58:34 UTC 2005


I just chatted IRL about this with Council member Matthew Miller. He 
pointed out that JEP-0004 forbids data forms in presence except for 
forms of type result, so we can't do what I suggested below. He also 
mentioned that he would like to see us develop a solution that does not 
rely on a large number of custom protocols, since very few clients will 
implement them right away (if ever?). So something like the following 
might work....

1. Romeo sends subscription request to Juliet.

2. Juliet's server sends a message to Romeo's client, including a 
plaintext body, a URL (JEP-0066), and a data form.

3. Romeo replies to the plaintext challenge, visits the URL, or returns 
the form.

4. If he passes one of the tests, he gets another message from Juliet's 
server telling him that he's cleared to communicate with Juliet.

Peter

Peter Saint-Andre wrote:

> Here's the flow I'm envisioning right now...
> 
> 1. Romeo sends a stanza to Juliet:
> 
> <presence
>     from='romeo at montague.net/home'
>     to='juliet at capulet.com'
>     type='subscribe'/>
> 
> 2. Juliet is blocking all communications from people who are not in her 
> roster, so (in violation of RFC 3921, section 10.4, we need to change 
> the MUST NOT to MAY in rfc3921bis) her server returns a 
> <not-authorized/> error to Romeo along with a form to fill out:
> 
> <presence
>     from='juliet at capulet.com'
>     to='romeo at montague.net/home'
>     type='error'>
>   <error code='404' type='auth'>
>     <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
>     <challenge xmlns='http://jabber.org/protocol/challenge'>
>       <audio type='audio/mpeg'>
>         <data> ** Base64 encoded audio ** </data>
>         <uri>http://www.capulet.com/challenges/audio.mp3?F3A6292C</uri>
>       </audio>
>       <image type='image/jpeg' width='290' height='80'>
>         <data> ** Base64 encoded image ** </data>
>         <uri>http://www.capulet.com/challenges/image.jpg?F3A6292C</uri>
>       </image>
>       <x xmlns='jabber:x:data' type='form'>
>         <field var='FORM_TYPE' type='hidden'>
>           <value>http://jabber.org/protocol/challenge</value>
>         </field>
>         <field var='sid' type='hidden'><value>client1</value></field>
>         <field label='Enter the code shown above.'
>                type='text-single'
>                var='image'/>
>         <field label='Enter the word you hear.'
>                type='text-single'
>                var='audio'/>
>         <field label='Spell my name backwards'
>                type='text-single'
>                var='question'/>
>         <field label='93C7A' type='text-single' var='sha1'/>
>       </x>
>     </challenge>
>   </error>
> </presence>
> 
> Whoa, yes, a form in the error!
> 
> 3. Now Romeo sends an IQ-set to Juliet's bare JID, which is handled by 
> Juliet's server on her behalf:
> 
> <iq type='set'
>     from='romeo at montague.net/home'
>     to='juliet at capulet.com'
>     id='challenge1'>
>   <challenge xmlns='http://jabber.org/protocol/challenge'>
>     <x xmlns='jabber:x:data' type='submit'>
>       <field var='FORM_TYPE' type='hidden'>
>         <value>http://jabber.org/protocol/challenge</value>
>       </field>
>       <field var='image'><value>7nHL3</value></field>
>     </x>
>   </challenge>
> </iq>
> 
> 4. Juliet's server determines (on her behalf) whether the response is 
> acceptable; if so, it returns an IQ-result, if not it returns an IQ-error:
> 
> <iq type='result'
>     from='juliet at capulet.com'
>     to='romeo at montague.net/home'
>     id='challenge1'/>
> 
> or...
> 
> <iq type='error'
>     from='juliet at capulet.com'
>     to='romeo at montague.net/home'
>     id='challenge1'>
>   <challenge xmlns='http://jabber.org/protocol/challenge'>
>     <x xmlns='jabber:x:data' type='result'>
>       <field var='FORM_TYPE' type='hidden'>
>         <value>http://jabber.org/protocol/challenge</value>
>       </field>
>       <field var='image'><value>7nHL3</value></field>
>     </x>
>   </challenge>
>   <error code='406' type='modify'>
>     <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
>   </error>
> </iq>
> 
> Instead of sending a <not-acceptable/> error, the server could return 
> another challenge to Romeo.
> 
> 5. If the server deems that Romeo's response is acceptable, it changes 
> the privacy list in force and frees up the stanza and delivers it to 
> Juliet (OR we specify that Romeo needs to re-send it, since that 
> simplifies the implementation quite a bit):
> 
> <presence
>     from='romeo at montague.net/home'
>     to='juliet at capulet.com'
>     type='subscribe'/>
> 
> 6. Juliet receives the stanza and swoons.
> 
> I suppose we'll need to also define a protocol (part of the challenge 
> stuff) that enables Juliet's client to define the challenge form.
> 
> Peter
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3511 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20050831/a2ea2cf2/attachment.bin>


More information about the Standards mailing list