[Standards] New revised version of proposal: Signing Forms

Peter Waher Peter.Waher at clayster.com
Wed May 21 14:55:33 UTC 2014

Hello Lance

Thanks for your input.

Regarding your concerns:

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

I first made an attempt to reuse 0235, but since it was deferred, and I did not get any response from Peter Saint-André (author) regarding the subject (see attached), I left that track. Furthermore, I wanted a solution that did not interfere with underlying architecture or communication principles, for instance like requiring to request tokens separately (like in §2 in XEP-0235), especially avoiding the use of other protocols, like HTTP (items 4 & 9 in §2).

> 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 seemed to be far too different from what I wanted to do. For instance:

* It seems to require you're already authenticated.
* Requires tokens to be separately fetched using another protocol.
* Only signs the stanza attributes, not the content.
* Was designed for interaction with pubsub, even though this can obviously be extended.

The main obstacle here are the first three points. Signing forms does not require any other interaction that what would normally have been done, and allows a solution to adapt itself easily. If the form requires signing, the client can sign the form, if not, signing is not required. The server (i.e. the one sending the form) determines if signature is necessary. The client needs no pre-knowledge if signing is required or not.

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

Well, such error information could be added easily in error responses to form submissions, if desired.

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

But 0235 is not an established way, since it is deferred.

The problem I want to avoid is anything that might interfere with how underlying implementation is done, both on clients and servers. Say you have a library that supports IBR. It raises an even when a IBR form is returned, or returns an IBR form as a response to a request. Without any changes to the library itself, you can implement the signature, since it's part of the form. If you place the OAUTH authentication outside, you might need to update the library, something you might not be able to.

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

I personally believe this is not the best solution, for the reasons described above:

* The solution might require changes made to libraries you use. The proposed solution does not.
* The changes made to 0235 would be very large, the main two problems being the token requests and use of other protocols. In essence the result would be something completely new anyway.

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

This is not a correct assessment. XEP-0235 does not sign the form, only the carrying stanza. This means you can inject anything into the stanza, and it will be assumed to be signed. The signing form proposal signs the actual form parameters, not the stanza carrying the form. This is a difference. So, the deferred 0235 can be used to sign the stanza element, but not the form, while the signing forms proposal signs the contents of a form, but not the stanza carrying the form, even though the form type and to address are included in the signature. So part of the stanza carrying the form is also signed.

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

I hope you reconsider, taking the above comments into account.

Best regards,
Peter Waher

-------------- next part --------------
An embedded message was scrubbed...
From: Peter Waher <Peter.Waher at clayster.com>
Subject: Securing IBR
Date: Mon, 14 Apr 2014 21:42:02 +0000
Size: 11833
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140521/7b5024cd/attachment.mht>

More information about the Standards mailing list