Ah, ok, I misunderstood the context of your reference to XMPP. So the
question at hand here is: How do you construct the thing you're going
to sign?
Assuming that's the question, then the critical thing is that the
format be canonical (or at least canonicalizable). That always seems
easier for simpler formats, so my inclination would be toward either
form-encoding or a custom format (3 or 4), since these define precise
rules for how things fit together. After that, a tight profile of
JSON might be workable (e.g., no white space); XML is probably too
much of a hassle.
--Richard
On Jan 28, 2010, at 1:06 PM, Eran Hammer-Lahav wrote:
This defeats the point of having a unified message format across
different transports. And since the message itself is not sent on the
wire, the benefit to XMPP isn't that significant.
Also, we are only talking about construction, not parsing. So
technically, no lib is really needed in either case (but can be useful
for data type encoding).
EHL
On Jan 28, 2010, at 7:30, "Richard L. Barnes" <[email protected]> wrote:
It's not clear that XML is always crazy. If you're integrating this
into an XMPP client, it's already used to using XML (i.e., it's
already got a parser/generator), and might not have JSON machinery.
I would suggest pinning down a data model that gets serialized to
different formats depending on the protocol. You're going to have to
define how OAuth fits into a different protocol anyway, so if there's
a set of defined serializations, you can just add a line to that
definition that says "use X serialization".
--Richard
On Jan 27, 2010, at 9:42 PM, Eran Hammer-Lahav wrote:
I don't think we had enough discussion for a consensus call but I
would like to continue with some combination of A and C. That means,
defining a message format to normalize the request into (which can
be used with XMPP and other transports), but to still process the
HTTP request and not the API request into the message. In other
words, not process parameters but still turn the request into a
message.
I will try this in my next draft.
My question: what format should we use for this message? The main
four options are:
1. XML
2. JSON
3. Form-encoded (key=value&key=value)
4. Text (key-value pair new line separated, or HTTP-header like
key="value" comma, etc.)
My thinking is: XML is crazy here (complication without benefits),
JSON is interesting but doesn't add much value beyond other options
(unless we foresee the need for lists or richer value types), Form-
encoded is ok but has to be specified due to variations in libraries
(well-known OAuth issue), and Text is easy but requires a custom
parser and we need to choose a style.
I am inclined to use Text (key=value LF) but can be talked into
Form-
encoded or even JSON.
Anyone else?
EHL
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of Eran Hammer-Lahav
Sent: Wednesday, January 13, 2010 9:41 PM
To: OAuth WG
Subject: [OAUTH-WG] Request Signing vs. API Signing vs. Message
Signing
Authentication Open Question #1: What to sign?
OAuth Core 1.0 was designed to sign API requests made using common
form-encoded formats. The main component of the 1.0 signature base
string
are the parameters. The host and HTTP methods are important but
were
never the focus on the signed content.
draft-hammer-oauth does not change the process but does describe
the
process very differently, changing the focus form signing API
requests and
parameters to signing HTTP requests (partially).
draft-hammer-http-token-auth takes this approach a step further and
focuses on signing the raw HTTP request components, completely
ignoring
their meaning as used by API calls. The end result is very similar
but the
differences are important.
Brian Eaton proposed [1] an alternative approach to sign messages
instead of
API calls or HTTP request. In his proposal, the HTTP request (or
API call based
on your perspective) in transformed into a message (in his case
using a JSON-
based format) which is then signed. This additional layer of
abstraction allows
the use of the method with other transports or use cases in which
parameters are not sent in the request URI or body.
QUESTION: Do you prefer:
A. Directly processing the HTTP request into a base string for
signing (draft-
hammer-oauth style).
B. Treating the request as an API call with form-encoded parameters
(OAuth
1.0 style).
C. Converting the request into a normalized message and signing
that (Eaton
style).
EHL
[1] http://www.ietf.org/mail-archive/web/oauth/current/
msg00890.html
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
