Subject: [OAUTH-WG] Request Signing vs. API Signing vs. Message Signing

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 13 Jan 2010 22:40:55 -0700

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

---

From: Blaine Cook <[email-masked]>
Date: Thu, 14 Jan 2010 12:44:58 +0000

> C. Converting the request into a normalized message and signing that (Eaton

For protocol independence of presenting a token + signed message, (C).
I wonder if John Panzer's recent proposal for Salmon [1] could be
adapted to use (C) elegantly? I think Salmon/PSHB is an interesting
use-case for delegated authorization and subsequent authentication,
and as such might be a good place to think about approaches like
Brian's.

b.

[1] http://www.abstractioneer.org/2010/01/magic-signatures-for-salmon.html

---

From: Blaine Cook <[email-masked]>
Date: Thu, 14 Jan 2010 12:56:46 +0000

> and as such might be a good place to think about approaches like

On second thought (and after reading Eran's Question #2) I'd like to
clarify this a bit; I like that Brian's proposal makes it flexible to
determine what is to be signed. Including the data twice in the
request is silly; perhaps an approach like Brian's, but with the
"message" part replaced with pointers-to-the-message-parts.

e.g.,

instead of envelope:

{ "name": "source.example.com",
  "algorithm": "RSA-SHA256",
  "timestamp": 1260253850,
  "nonce": "0437f743b5809" }

and message:

{ "url": "http://source.example.com/x/y/z" }

just include the message-parts in the envelope:

{ "name": "source.example.com",
  "algorithm": "RSA-SHA256",
  "timestamp": 1260253850,
  "nonce": "0437f743b5809",
  "message": [ "url" ] }

See my reply to Eran's Question #2 for reasoning.

b.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 14 Jan 2010 14:30:49 -0800

> C. Converting the request into a normalized message and signing that (Eaton

I lean toward having an extensible, normalized structure that can be
signed. As pointed-out by Blane, I think Eaton style (C) gives the most
amount of flexibility in this regard.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

Paul

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Jan 2010 19:42:59 -0700

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-masked] [mailto:[email-masked]] 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
> 
> 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
> 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
> 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).

---

From: Justin Hart <[email-masked]>
Date: Thu, 28 Jan 2010 08:15:26 -0700

I'm inclined to say #1 to JSON because its rules are well defined
(especially escaping and delimiters) and the parsers are widely available
and relatively standard.  It really has little more complication than other
key-value forms. I say #2 to form-encoded because though there have been
issues, again, the form is defined.  Picking an already defined format
should avoid most parser trouble.

On Wed, Jan 27, 2010 at 7:42 PM, Eran Hammer-Lahav <[email-masked]>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.
>
> 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.
>
> based

---

From: Luke Shepard <[email-masked]>
Date: Thu, 28 Jan 2010 07:21:10 -0800

+1 to JSON. Custom parser is difficult and JSON adds very little overhead to the data.

On 1/28/10 7:15 AM, "Justin Hart" <[email-masked]> wrote:

I'm inclined to say #1 to JSON because its rules are well defined (especially escaping and delimiters) and the parsers are widely available and relatively standard.  It really has little more complication than other key-value forms. I say #2 to form-encoded because though there have been issues, again, the form is defined.  Picking an already defined format should avoid most parser trouble.

On Wed, Jan 27, 2010 at 7:42 PM, Eran Hammer-Lahav <[email-masked]> 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.

1. XML
2. JSON

Anyone else?

EHL

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Jan 2010 10:30:33 -0500

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

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 28 Jan 2010 10:35:34 -0700

Speaking not as a core OAuth contributor but as someone who has implemented and used a few flavors of OAuth, I am +1 on either JSON or form encoded.

John

On Jan 28, 2010, at 7:21 AM, "Luke Shepard" <[email-masked]<mailto:[email-masked]>> wrote:

On 1/28/10 7:15 AM, "Justin Hart" <<[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jan 27, 2010 at 7:42 PM, Eran Hammer-Lahav <<[email-masked]>[email-masked]<mailto:[email-masked]>> 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.

1. XML
2. JSON

Anyone else?

EHL

> From: <[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> [1] <http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html> http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html
>
> <[email-masked]> [email-masked]<mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/oauth> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
<[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 28 Jan 2010 11:06:23 -0700

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Jan 2010 14:32:11 -0500

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:

>>> I am inclined to use Text (key=value LF) but can be talked into  
>>> Form-
>>> encoded or even JSON.
>>>
>>> Anyone else?
>>>
>>> EHL
>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 28 Jan 2010 14:00:42 -0700

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

> From: Richard L. Barnes [mailto:[email-masked]]
> 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
> 
> 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
> 
> 
> 
> >>> 3. Form-encoded (key=value&key=value) 4. Text (key-value pair new
> >>> line separated, or HTTP-header like key="value" comma, etc.)
> >>>
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Eran Hammer-Lahav
> >>>> 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).
> >>>> 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).
> >>>> C. Converting the request into a normalized message and signing
> >>>> that (Eaton style).
> >>>>
> >>>> EHL
> >>>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Jan 2010 16:09:32 -0500

<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
>
>> format be
>>>>>> B. Treating the request as an API call with form-encoded  
>>>>>> parameters
>>>>>> (OAuth
>>>>>> 1.0 style).

---

From: Justin Hart <[email-masked]>
Date: Thu, 28 Jan 2010 16:00:17 -0700

You're correct.  I was thinking too much about reading, not about creating.
 This is all about creation.  In that case, the absolute simpler the better.
 In any case there'll have to be some key-value and pair delimiter which
will need to be escaped within keys and values.  The newline idea (where
newlines become literal \n?) is nice, because it has implied key-value
delimiter by specifying that values always come after keys delimited by
newline.  Then we only have one thing to escape.

On Thu, Jan 28, 2010 at 2:00 PM, Eran Hammer-Lahav <[email-masked]>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
>

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 28 Jan 2010 15:11:35 -0800

+1 to JSON. Rationale:

1. Allows for structured data with relatively low overhead (unlike flat
name-value pairs).
2. Marshalls/unmarshalls nearly unambiguously to/from native data
structures (dictionaries, arrays, integers, strings, etc.) in multiple
programming languages (unlike XML).
3. In-browser capabilities (e.g. JavaScript) for manipulating
JSON-structured data.

That said, there would probably need to be some restrictions on JSON
encoding in order to support normalization. See
http://wiki.apache.org/couchdb/SignedDocuments for issues they've had to
deal with on this front.

Paul

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 28 Jan 2010 16:20:07 -0700

> Of Paul C. Bryan
> Sent: Thursday, January 28, 2010 3:12 PM

> 3. In-browser capabilities (e.g. JavaScript) for manipulating JSON-structured
> data.
> 

These two statements are contradictory because whatever issues there are, it is unlikely that the in-browser support will be able to work around it, leading to more errors and confusion than being helpful.

EHL

> > 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
> 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.
> >
> > > process very differently, changing the focus form signing API
> > > method with other transports or use cases in which parameters are not
> sent in the request URI or body.
> > >
> > > QUESTION: Do you prefer:
> > >
> > > C. Converting the request into a normalized message and signing that
> > > (Eaton style).
> > >
> > > EHL
> > >

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 28 Jan 2010 15:28:00 -0800

Possibly, although I haven't yet come to the conclusion that these are
incompatible.

Moves to build proper JSON JavaScript libraries rather than rely on the
built-in parser are already tackling some other JSON-related issues, and
could possibly serve to address this issue as well.

Paul