From 1596ba1158a44a0bbbe07ef8de7839843da932dc Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Mon, 12 May 2014 09:22:49 -0600 Subject: [PATCH] ProtoXEP: Signing Forms v0.0.2: see revision --- inbox/signing-forms.xml | 47 +++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 25 deletions(-) diff --git a/inbox/signing-forms.xml b/inbox/signing-forms.xml index f07d593e..28906cec 100644 --- a/inbox/signing-forms.xml +++ b/inbox/signing-forms.xml @@ -31,6 +31,16 @@ peter.waher@jabber.org http://www.linkedin.com/in/peterwaher + + 0.0.2 + 2014-05-09 + pw + +

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.

+ + 0.0.1 2014-04-16 @@ -55,30 +65,13 @@ and to what extent.

- The algorithm used to sign a form, is the - OAuth 1.0 Protocol - + A fixed algorithm (OAuth 1.0 Protocol RFC-5849: The OAuth 1.0 Protocol <http://tools.ietf.org/html/rfc5849>. - . It is a popular algorithm used to sign API calls. Even though - OAuth version 2 - - - RFC-6749: The OAuth 2.0 Authorization Framework <http://tools.ietf.org/html/rfc6749>. - exists, it has not been chosen due to - - controversy - - - OAuth 2.0 and the Road to Hell <http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/>. - . and that it is not sure it provides a better solution. -

-

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

@@ -183,8 +176,12 @@

The string s 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 + 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 + Unicode Standard Annex #15, Unicode Normalization Forms + + Unicode Standard Annex #15, Unicode Normalization Forms <http://unicode.org/reports/tr15/#Norm_Forms>. + and then encoded as UTF-8 octets before percent-encoding them per RFC 3629 RFC 3629: UTF-8, a transformation format of ISO 10646 <http://www.ietf.org/rfc/rfc3629.txt>. @@ -537,4 +534,4 @@ - \ No newline at end of file +