Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

On 08/09/2012 06:47 PM, Dick Hardt wrote:
>
> On Aug 9, 2012, at 1:08 PM, Justin Richer wrote:
>
>> With MAC, you should be able to re-use about 80-90% of your existing 
>> codepath that's in place for Bearer, simplifying the setup below.
>
> That makes no sense, I would be adding MAC to the sites that support 
> MAC in addition to OAuth 1.0A or OAuth 2.0

You get to re-use all of the code for OAuth2 for issuing tokens (from 
server side) and requesting tokens (from client side). Apart from 
parsing the JSON value that's returned from the token endpoint (and you 
are using a generic parser there, right?), nothing changes here. The 
part where you *use* the token to access a protected resource (client), 
or *validate* a request to a protected resource (server) changes 
significantly, yes. But that's only a small part of the process.

>
>>
>> I would figure that the "variant of OAuth2" issue is a red herring 
>> because not everyone out there is fully spec compliant. If they were, 
>> you wouldn't have so many beautiful snowflakes.
>
>
> Being consistent in the spec would help, but likely would just give me 
> snowflakes that look more like each other.
>
> There are many aspects of the OAuth dance that are implementation 
> dependent and it is simpler to just have a separate method for each 
> one that deals with those unique characteristics. Note this is not 
> theory, this is practice. Different modules was not an issue. Not 
> having to use a library to sign requests and being able to use CURL or 
> a browser to see what a request returned had a HUGE productivity gain 
> for OAuth 2.0 implementations over OAuth 1.0A implemetations.
>
>>
>>  -- Justin
>>
>> On 08/09/2012 03:48 PM, Dick Hardt wrote:
>>> As an implementer, I have an app that accesses 10 different 
>>> resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All 
>>> have a slightly different code path since each resource is its own 
>>> beautiful snowflake. I did not use any libraries for OAuth 2. 
>>> Supporting MAC would give me yet another library to integrate with.
>>>
>>> I'd be interested in what signing problems OAuth 1.0A has. I have my 
>>> own list of how writing to OAuth 1.0A is hard.
>>>
>>> On Aug 9, 2012, at 10:53 AM, William Mills wrote:
>>>
>>>> MAC fixes the signing problems encountered in OAuth 1.0a, yes there 
>>>> are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 
>>>> auth model and will provide for a single codepath for sites that 
>>>> want to use both Bearer and MAC.
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Dick Hardt <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>>
>>>> *To:* William Mills <wmills_92105@yahoo.com 
>>>> <mailto:wmills_92105@yahoo.com>>
>>>> *Cc:* "oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org 
>>>> <mailto:oauth@ietf.org>>
>>>> *Sent:* Thursday, August 9, 2012 10:27 Aa
>>>> *Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>>>
>>>>
>>>> On Aug 9, 2012, at 9:52 AM, William Mills wrote:
>>>>
>>>>> I find the idea of starting from scratch frustrating.  MAC solves 
>>>>> a set of specific problems and has a well defined use case.  It's 
>>>>> symmetric key based which doesn't work for some folks, and the 
>>>>> question is do we try to develop something that supports both PK 
>>>>> and SK, or finish the SK use case and then work on a PK based draft.
>>>>>
>>>>> I think it's better to leave them separate and finish out MAC 
>>>>> which is *VERY CLOSE* to being done.
>>>>
>>>> Who is interested in MAC? People can use OAuth 1.0 if they prefer 
>>>> that model.
>>>>
>>>> For my projects, I prefer the flexibility of a signed or encrypted 
>>>> JWT if I need holder of key.
>>>>
>>>> Just my $.02
>>>>
>>>> -- Dick
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>