[Standards] New revised version of proposal: Signing Forms

Peter Waher Peter.Waher at clayster.com
Fri May 16 17:01:57 UTC 2014

Hello Dave,

Thanks for the valuable input. Sorry for the delay in responding. I’ll address your comments and suggestions one at a time:

>Last one on my list. :-)
>First off, it's unclear why, in §2.4, PStr does not include the 'from' attribute if available? I also suspect it should include the 'to' only if given in the stanza, and finally I think your use of "type" should be replaced with "form_type" to avoid confusion with the stanza's type attribute.

The reason was to stick to the OAUTH algorithm as defiend for the web, where BStr is defined as:


(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:


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.“


Note however, that you can include any parameter in the signature, by posting hidden parameters on the form.

Next, typo - Example 6 should presumably have a title of "PLAINTEXT".

Thanks. Corrected.

Overall, I really think that using the FORM_TYPE here is wrong - it means the only forms that can be signed are form signing forms, which seems somewhat introspective. Instead I recommend defining a new signing indicator, perhaps a field SIGNED. It's not *wonderfully* clear in XEP-0068 whether additional generic field names such as this, or the oauth ones, can be registered in such a way, but we can change that to accommodate this.

The reason I feel strongly here is because I'd like to be able to potentially sign forms such as MUC configurations, and the current proposal essentially prevents this.

Yes, I was thinking about this also. I was thinking, that instead of defining a completely new FORM_TYPE, just to define a suffix, for instance “:signature:oauth1”. This would make it easier for clients to understand. Examples:

For signed in-band registration with form signature:

For in-band registration with CAPTCHA:

Generic form signature:

Similarly, form types for MUC configuration, etc. could have their FORM_TYPE suffixed by “:signature:oauth1”.

Would that work?

I have not reviewed this document in terms of security.

On 13 May 2014 13:58, Peter Waher <Peter.Waher at clayster.com<mailto:Peter.Waher at clayster.com>> wrote:

I had forgotten to add an Acknowledgements section to the previous version. Here, an updated version with acknowledgements. If I’ve forgotten anybody, please let me know.

Best regards,
Peter Waher

From: Peter Waher
Sent: den 9 maj 2014 18:12
To: standards at xmpp.org<mailto:standards at xmpp.org>
Cc: XEP Editor (editor at xmpp.org<mailto:editor at xmpp.org>)
Subject: New revised version of proposal: Signing Forms


Attached is a revised version of the proposed XEP: Signing Forms.

All input from the community and the council has been addressed, mostly minor:

•         Removed links to articles expression opinions.

•         Reformulated the reference to SASL in the introduction.

•         A reference to Unicode Standard Annex #15, Unicode Normalization Forms, and NFC normalization has been added.

Please add this to the inbox.

Best regards,
Peter Waher

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140516/672d968b/attachment.html>

More information about the Standards mailing list