moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 02:32:18 -05:00
Code Issues Releases Wiki Activity

ProtoXEP: Signing Forms v0.0.2: see revision

Browse Source
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

45
inbox/signing-forms.xml
View File

@ -31,6 +31,16 @@
<jid>peter.waher@jabber.org</jid> <jid>peter.waher@jabber.org</jid>
<uri>http://www.linkedin.com/in/peterwaher</uri> <uri>http://www.linkedin.com/in/peterwaher</uri>
</author> </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> <revision>
<version>0.0.1</version> <version>0.0.1</version>
<date>2014-04-16</date> <date>2014-04-16</date>
@ -55,30 +65,13 @@
and to what extent. and to what extent.
</p> </p>
<p> <p>
The algorithm used to sign a form, is the <span class='ref'> A fixed algorithm (<span class='ref'><link url='http://tools.ietf.org/html/rfc5849'>OAuth 1.0 Protocol</link></span>
<link url='http://tools.ietf.org/html/rfc5849'>OAuth 1.0 Protocol</link>
</span>
<note> <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;. 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'> </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
<link url='http://tools.ietf.org/html/rfc6749'>OAuth version 2</link> 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
</span> 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
<note> being signed.
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.
</p> </p>
</section1> </section1>
<section1 topic='Signing a form' anchor='signingform'> <section1 topic='Signing a form' anchor='signingform'>
@ -183,8 +176,12 @@
<dd> <dd>
<p> <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. 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 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
octets before percent-encoding them per <span class='ref'> 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> <link url='http://www.ietf.org/rfc/rfc3629.txt'>RFC 3629</link>
</span> <note> </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;. 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;.