Subject: [OAUTH-WG] HTTP/1.0 and JSON

From: Tim Brody <[email-masked]>
Date: Wed, 15 Jun 2011 13:41:43 +0100

Hi All,

I'm the author of this Perl library for signing OAuth 1.0 requests:
http://search.cpan.org/~timbrody/LWP-Authen-OAuth-1.01/

I've been asked about OAuth 2.0 so have scanned through the spec and
joined this list :-)

The MAC-signing draft section 1.2 refers to "Host:" but I have an HTTP
library that can talk 1.0 or 1.1. I make an HTTP request with URI + form
parameters + extra headers - I don't know if the "Host:" header will
exist. So, can you just refer to the "hostname" and "port"? (Whether
they are in the URI or a Host: header seems orthogonal to OAuth anyway?)

Why do you POST application/x-www-form-urlencoded but get
application/json?

I couldn't find a conclusion to the May 2010 discussions about using
x-www-form-urlencoded vs. json nor a rationale in the spec for using
JSON. Why do I need to add a JSON lexer/parser to my library just to get
key-value pairs that can be represented by form-urlencoded?

All the best,
Tim.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 08:31:39 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tim Brody
> Sent: Wednesday, June 15, 2011 5:42 AM
> To: [email-masked]
> Subject: [OAUTH-WG] HTTP/1.0 and JSON
> 
> Hi All,
> 
> The MAC-signing draft section 1.2 refers to "Host:" but I have an HTTP library
> that can talk 1.0 or 1.1. I make an HTTP request with URI + form parameters +
> extra headers - I don't know if the "Host:" header will exist. So, can you just
> refer to the "hostname" and "port"? (Whether they are in the URI or a Host:
> header seems orthogonal to OAuth anyway?)

The MAC draft works on HTTP/1.1 requests. Using it with 1.0 is undefined.

> Why do you POST application/x-www-form-urlencoded but get

There is a long thread somewhere... But it's the compromise we reached.

> I couldn't find a conclusion to the May 2010 discussions about using x-www-
> form-urlencoded vs. json nor a rationale in the spec for using JSON. Why do I
> need to add a JSON lexer/parser to my library just to get key-value pairs that
> can be represented by form-urlencoded?

Every modern platform has a JSON parser.

EHL
 
> 
> All the best,
> Tim.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Wed, 15 Jun 2011 11:45:28 -0400

> Every modern platform has a JSON parser.

While JSON is widespread, it is an additional requirement. I've done
some work to define and XML encoding for OAuth tokens here:

  http://tools.ietf.org/html/draft-richer-oauth-xml-00

The draft still needs to be updated to point to the right sections of
the OAuth2 spec, but the mechanics are still valid. 

The point of this is similar to your contention: if I'm already speaking
one wire format (XML), why would I want to deal with JSON just to do my
auth step? 

If you'd like to try defining a key-value encoding, we can publish an
extension draft for that as well.

 -- Justin

---

From: Tim Brody <[email-masked]>
Date: Thu, 16 Jun 2011 09:43:10 +0100

On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer <[email-masked]>
wrote:
>> > x-www-

Two queries on your spec:
 - Have you considered using HTTP Accept: (content negotiation) rather than
a 'format' parameter? Regardless I suggest using MIME types rather than
'json'/'xml'.

 - Use Schema rather than typing by bespoke attributes?

It's a useful short-cut (as a consumer) to be able to apply a schema to
validate the content including all of the values via basic schema
types/regexp.
Similarly with extensions, if you use namespacing then clients will
transparently ignore anything that isn't in their recognised namespace(s).

For simplicity I would require the default namespace (xmlns=) to be oauth.
Then values can easily be extracted using string-matching in lightweight
clients:
$xml =~ /<access_token>([^<]+)<\/access_token>/;

(Schema would also address your 3.7 Information Loss because the Schema
would explicitly define values as numeric or text and singular or multiple)

Lastly a general RFC point - should you reference RFC 3023, especially the
content-type and security sections?

> extension draft for that as well.

I think the simple case is simple:
Content-type: application/x-www-form-urlencoded

access_token=SlAV32hkKG&expires_in=3600&refresh_token=8xLOxBtZp8

I would re-use the OpenID scheme for providing extension data:

openid.ns.ax=http://openid.net/srv/ax/1.0&
openid.ax.type.email=http://schema.openid.net/contact/email&
openid.ax.value.email=[email-masked]&
oauth.ns.ext=http://example.com/api#limits&
oauth.ext.soft=10000&
oauth.ext.hard=15000&
oauth.ns.rr=http://example.com/api#roles&
oauth.rr.role=owner&
oauth.rr.role=editor&
oauth.rr.role=creator&
...

I suggest a constraint that the form/urlencoded is always utf-8 (c.f.
OpenURL KEV format NISO Z39.88-2004):
Ë => %C3%8B
And never:
Ë => %CB

I'm happy to write this up but all I'd do is drop replacement text into
your RFC.
Do you have a source doc I can work on? What do I do with it when finished?

-- 
All the best,
Tim.

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jun 2011 08:50:37 -0400

> a 'format' parameter? Regardless I suggest using MIME types rather than

Yes, and I'm planning on putting that into the updated revision. I
already had someone yell at me about its omission. :) This will be in
addition to the format parameter, though, not in lieu of it. I also
greatly prefer short names in the parameter, especially because it's a
limited set. The Accept header will use mimetypes though, obviously. 

> transparently ignore anything that isn't in their recognised namespace(s).

I'm personally a fan of schema-by-fiat, which is what JSON does. I've
also always hated writing XML schemas. If, however, someone wants to
write a schema for the core components, I'd be fine with that. However,
I do want it to remain general enough to be able to encode more complex
extensions, and apart from saying all extensions are in some namespace,
I'm not sure how to handle that with a Schema. Speaking of namespaces...

> $xml =~ /<access_token>([^<]+)<\/access_token>/;

I avoided using a namespace specifically to cut down on verbosity, since
even a default namespace requires attributes in the root tag. While I
think string-matching like that in XML is a Very Bad Thing, I do want to
keep the serialization simple. That said, if there's enough of a call I
can put in a default namespace. What would the URI of that be?
http://oauth.net/2/xml? urn:oauth2:xml?

> would explicitly define values as numeric or text and singular or multiple)

For core attributes, but not for encoding extensions. I wanted this to
be a ruleset that one could apply to a blob of JSON to translate it to
parseable XML.

> content-type and security sections?

Good catch, thanks.

> OpenURL KEV format NISO Z39.88-2004):

Not all OAuth extensions that return more stuff have a namespace,
though, so it's not an exact map. However, the general method of
encoding objects and lists could work.

> Do you have a source doc I can work on? What do I do with it when finished?

I'd be happy to incorporate your encoding if you want to write them up.

 -- Justin