On May 16, 2014, at 10:01 AM, Peter Waher <peter.wa...@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='jul...@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>jul...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
