Hi Skylar, 

> -----Original Message-----
> From: Skylar Woodward [mailto:sky...@kiva.org]
> Sent: Monday, February 07, 2011 9:25 AM

> On including parameters for signing...
> 
> I'd retract my suggestion that we'd include parameter-hash in the header.
> Instead, I would suggest making parameters optional in calculating the
> signature using a flag as with bodyhash. Providers could require including
> parameters if so desired. Parameters could be included as currently defined,
> or with a hash method similar to entity-body (which I find both simpler and
> more congruent).
> 
> Again, the goal in making query parameters optional is to allow providers to
> make signature calculation as simple as possible for clients (so much as it 
> is in
> line with the security requirements of the provider) and avoid complexities in
> implementation such as those that tripped up OAuth 1.

I have been opposed this line of thinking for over two years now.

As actual code shows, producing the normalized request string per this 
specification is straight-forward. Developers finding it hard should use a 
library and not try to write their own. They can also cut-and-paste the 10 or 
so lines it takes to produce the string.

This authentication method comes with well understood security properties. By 
making query parameters optional because of developer ease, providers will be 
giving up an important part of the protection this protocol offers. This is 
especially true for the majority of APIs where query parameters are critical to 
the request integrity.

The right solution here is to provide either a library for your developers, or 
an API without any parameters.

EHL

> 
> 
> 
> On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote:
> 
> > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02
> >
> > New version includes the following changes:
> >
> >    o  Added body-hash support.
> >    o  Updated OAuth 2.0 reference to -12 and added token type registration
> template.
> >    o  Removed error and error URI attributes (codes were just a duplication
> of the HTTP status codes).
> >
> > Feedback would be greatly appreciated.
> >
> > EHL
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to