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:
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.
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:
jabber:iq:register:signature:oauth1
For in-band registration with CAPTCHA:
urn:xmpp:captcha:signature:oauth1
Generic form signature:
urn:xmpp:xdata:signature:oauth1
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.wa...@clayster.com<mailto:peter.wa...@clayster.com>> wrote:
Hello
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@xmpp.org<mailto:standards@xmpp.org>
Cc: XEP Editor (edi...@xmpp.org<mailto:edi...@xmpp.org>)
Subject: New revised version of proposal: Signing Forms
Hello
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
