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>
></oauth>
>
>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
--- Begin Message ---
Hello
Regarding IBR and a new proposal, it would be really great to have your input
before I start, to avoid losing time needlessly.
And on a related topic, what happened to the OAUTH & XMPP effort?
http://xmpp.org/extensions/xep-0235.html
http://mail.jabber.org/pipermail/standards/2009-December/022923.html
Do you share the conclusion of Eran Hammer, that OAuth 2 is not a good idea?
Best regards,
Peter Waher
PS: Thoughts about making IBR secure in open networks:
Hello Peter & community
As I mentioned before, I have an idea on how to make IBR secure. It would work
as follows:
* A manufacturer, or responsible party, would create an account on the xmpp
server, or have an account created for him by an operator. There he/she could
be allowed to create a certain number of accounts automatically.
* The manufacturer would get a shared secret (say an "API Key") identifying the
account.
* Each device or application wanting to perform IBR would have this key
configured.
* When the device or app connects to the server, using IBR, it returns a
registration form, as specified in IBR. But one (or two) of the fields would
contain a challenge.
* The device or application fills in the response field according to the shared
secret and the challenge. Perhaps using OAUTH.
* When registering, the new account would be discounted from the pool of
accounts permitted by the key.
* If a shared secret gets to be known, the manufacturer or responsible party
can just choose to generate a new shared secret (or key).
In this way operatos of the xmpp server can have control of who are trusted to
create accounts automatically. And they in turn have control of how many
accounts can be created, and monitor how many have been created. And it allows
them to create devices without preprogrammed JID:s.
What do you think about such an approach?
Best regards,
Peter Waher
From: Peter Waher
Sent: den 3 april 2014 10:56
To: Peter Saint-Andre
Subject: IBR
Hello Peter
It would be great to have your input on the IBR question and my proposal,
before continuing.
Best regards,
Peter Waher
--- End Message ---
