<sarcasm>We could always just use ASN.1</sarcasm>
On Jan 28, 2010, at 4:00 PM, Eran Hammer-Lahav wrote:
That's exactly it.
This is why JSON is not my top priority because people will see 'use
JSON' and ignore the profile (no whitespace) and will fail.
Those of you who picked JSON, does this change your mind? If we use
JSON, I expect many existing libraries that produce JSON objects to
fail because of the differences in how they add whitespace.
EHL
-----Original Message-----
From: Richard L. Barnes [mailto:[email protected]]
Sent: Thursday, January 28, 2010 11:32 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Request Signing vs. API Signing vs. Message
Signing
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
