[Standards] New revised version of proposal: Signing Forms

Lance Stout lancestout at gmail.com
Tue May 20 19:04:06 UTC 2014


On May 16, 2014, at 10:01 AM, Peter Waher <Peter.Waher at clayster.com> wrote:

> The reason was to stick to the OAUTH algorithm as defiend for the web, where BStr is defined as:
>  
> BStr:=Escape(method)+'&'+Escape(url)+'&'+Escape(PStr)
>  
> (method=GET/POST; etc..)
>  
> The closest match in XMPP the method parameter has is the type attribute used when submitting the form, and the closest match to the url parameter is the to-attribute. It is the actual ‘type’ attribute that is referred to. (I’ve made a small change to highlight this.) The form_type parameter is already included in PStr:
>  
> BStr:=Escape(type)+'&'+Escape(to)+'&'+Escape(PStr)
>  
> Clarification now reads:
>  
> “The Signature Base String (BStr) is then formed concatenating Escape(type) (the 'type' attribute of the form used when submitting the form), Escape(to) (the full destination address, including resource, if any) and Escape(PStr), using ampersands ('&') as delimiter.“
>  
> OK?
>  
> Note however, that you can include any parameter in the signature, by posting hidden parameters on the form.


-- without council hat --

Since signing forms uses OAuth 1, how much from XEP-0235 (OAuth over XMPP) can be reused here? XEP-0235 already specifies some of these parameters for generating signatures, which differ from ones in this proposal.


Having spent some time reviewing signing forms against some use cases I might have for it, I'm really left wondering why not just use XEP-0235 directly? It clearly separates the OAuth data from the user's form data, and provides error elements for explicit feedback on incorrect or missing parameters which signing forms currently lacks. I understand that embedding OAuth information inside a form is quick & easy, but 235 is very simple too and can be used in places where forms aren't used. I'd rather we have a single established way to do OAuth generally rather than two almost-the-same-but-not-quite methods.


    <iq type='set'
        from='juliet at capulet.com/balcony'
        to='contests.shakespeare.lit'
        id='reg4'>
      <query xmlns='jabber:iq:register'>
        <x xmlns='jabber:x:data' type='submit'>
          <field type='hidden' var='FORM_TYPE'>
            <value>jabber:iq:register</value>
          </field>
          <field type='text-single' label='Given Name' var='first'>
            <value>Juliet</value>
          </field>
          <field type='text-single' label='Family Name' var='last'>
            <value>Capulet</value>
          </field>
          <field type='text-single' label='Email Address' var='email'>
            <value>juliet at capulet.com</value>
          </field>
          <field type='list-single' label='Gender' var='x-gender'>
            <value>F</value>
          </field>
        </x>
        <oauth xmlns="urn:xmpp:oauth:0">
          <oauth_version>1.0</oauth_version>
          <oauth_signature_method>HMAC-SHA1</oauth_signature_method>
          <oauth_token>...</oauth_token>
          <oauth_token_secret>...</oauth_token_secret>
          <oauth_consumer_key>.. .</oauth_consumer_key>
          <oauth_nonce>.. .</oauth_nonce>
          <oauth_timestamp>.. .</oauth_timestamp>
          <oauth_signature>.. .</oauth_signature>
        </oauth>
      </query>
    </iq>


I will admit that right now XEP-0235 does need some editing & review, and that it lacks two key features: indication that OAuth is required, and the optional inclusion of form fields in the signature. As for requirement indication, I think we can do that rather easily:

<oauth xmlns="urn:xmpp:oauth:0">
  <required />
  <oauth_version>1.0</oauth_version>
  <oauth_signature_method>HMAC-SHA1</oauth_signature_method>
</oauth>

And for form values in the signature, we can state that if the OAuth request is used in conjunction with a data form, then the signature process may include those form values, in the manner described here.





-- with council hat --

XEP-0235 & Signing Forms have overlapping use cases, and while similar have at least one subtle difference & gotcha (notably the method values are currently inconsistent). Editing and updating of XEP-0235 could be done to cover the cases addressed by Signing Forms. However, Signing Forms can *not* be updated to cover all of the cases addressed by XEP-0235, namely cases which don't involve data forms (e.g., PubSub subscription requests).

As such, I'm inclined to vote -1 for Signing Forms as-is in preference that we expand and fix XEP-0235 so that it addresses the use cases for Signing Forms.


-- Lance



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140520/e60cbef0/attachment.sig>


More information about the Standards mailing list