moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

ProtoXEP: Signing Forms v0.0.2: see revision

This commit is contained in:
Matthew A. Miller 2014-05-12 09:22:49 -06:00
parent 9051a00b3e
commit 1596ba1158
1 changed files with 22 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
inbox/signing-forms.xml
View File

@ -31,6 +31,16 @@
<jid>peter.waher@jabber.org</jid>
<uri>http://www.linkedin.com/in/peterwaher</uri>
</author>
<revision>
<version>0.0.2</version>
<date>2014-05-09</date>
<initials>pw</initials>
<remark>
<p>Removed links to articles expression opinions.</p>
<p>Reformulated the reference to SASL in the introduction.</p>
<p>A reference to Unicode Standard Annex #15, Unicode Normalization Forms, and NFC normalization has been added.</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2014-04-16</date>
@ -55,30 +65,13 @@
and to what extent.
</p>
<p>
The algorithm used to sign a form, is the <span class='ref'>
<link url='http://tools.ietf.org/html/rfc5849'>OAuth 1.0 Protocol</link>
</span>
A fixed algorithm (<span class='ref'><link url='http://tools.ietf.org/html/rfc5849'>OAuth 1.0 Protocol</link></span>
<note>
RFC-5849: The OAuth 1.0 Protocol &lt;<link url='http://tools.ietf.org/html/rfc5849'>http://tools.ietf.org/html/rfc5849</link>&gt;.
</note>. It is a popular algorithm used to sign API calls. Even though <span class='ref'>
<link url='http://tools.ietf.org/html/rfc6749'>OAuth version 2</link>
</span>
<note>
RFC-6749: The OAuth 2.0 Authorization Framework &lt;<link url='http://tools.ietf.org/html/rfc6749'>http://tools.ietf.org/html/rfc6749</link>&gt;.
</note> exists, it has not been chosen due to
<span class='ref'>
<link url='http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/'>controversy</link>
</span>
<note>
OAuth 2.0 and the Road to Hell &lt;<link url='http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/'>http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/</link>&gt;.
</note>. and that it is not sure it provides a better solution.
</p>
<p>
A fixed algorithm has been chosen in favor of SASL, to avoid multiple callbacks during form signature.
The idea is to make form signature possible without having to do any intermediate server callbacks, or having to change the original request returning the form. Using SASL and
recommended SASL authentication methods, such as SCRAM-SHA-1, at least one extra server callback would be necessary. If including a callback when selecting SASL method after
having retrieved the form, at least two extra callbacks would be required in some cases. Even by fixing SASL algorithm, the common algorithms not requiring server callback, such
as DIGEST-MD5, are not considered secure enough.
</note>) has been chosen in favor of a method where the user can select an authentication method from a list of available methods, modelled in the likeness of SASL. The main reason is
to avoid multiple callbacks during form signature. The idea is to make form signature possible without having to do any intermediate server callbacks, or having to change the original
request returning the form. The method is still extensible, allowing possible future extensions. The form signing algorithm to use is defined by the FORM_TYPE parameter in the form
being signed.
</p>
</section1>
<section1 topic='Signing a form' anchor='signingform'>
@ -183,8 +176,12 @@
<dd>
<p>
The string <strong>s</strong> are escaped using the &rfc3986; percent-encoding (%xx) mechanism. Characters not in the unreserved character set (§ 2.3) MUST be encoded.
Characters in the unreserved character set MUST NOT be encoded. Hexadecimal characters in encodings MUST be upper case. Text names and values MUST be encoded as UTF-8
octets before percent-encoding them per <span class='ref'>
Characters in the unreserved character set MUST NOT be encoded. Hexadecimal characters in encodings MUST be upper case. Text names and values MUST first be normalized
using Normalization Form C (NFC) as defined in <span class='ref'>
<link url='http://unicode.org/reports/tr15/#Norm_Forms'>Unicode Standard Annex #15, Unicode Normalization Forms</link>
</span> <note>
Unicode Standard Annex #15, Unicode Normalization Forms &lt;<link url='http://unicode.org/reports/tr15/#Norm_Forms'>http://unicode.org/reports/tr15/#Norm_Forms</link>&gt;.
</note> and then encoded as UTF-8 octets before percent-encoding them per <span class='ref'>
<link url='http://www.ietf.org/rfc/rfc3629.txt'>RFC 3629</link>
</span> <note>
RFC 3629: UTF-8, a transformation format of ISO 10646 &lt;<link url='http://www.ietf.org/rfc/rfc3629.txt'>http://www.ietf.org/rfc/rfc3629.txt</link>&gt;.
@ -537,4 +534,4 @@
</example>
</section2>
</section1>
</xep>
</xep>