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

+1

finishing a draft for historical reasons without the full context of HoK 
use-cases and identified threats concerns me

> In Vancouver the question was asked about the future of the MAC spec 
> due to it no linger having a editor.
>
> The Chair and AD indicated a desire to have a document on the 
> use-cases we are trying to address before deciding on progressing MAC 
> or starting a new document.
>
> Phil Hunt is going to put together a summery of the Vancouver 
> discussion and we are going to work on the use-case/problem 
> description document ASAP.
>
> People are welcome to contribute to the use-case document.
>
> Part of the problem with MAC has been that people could never agree on 
> what it was protecting against.
>
> I think there is general agreement that one or more proof mechanisms 
> are required for access tokens.
> Security for the token endpoint also cannot be ignored.
>
>
> John B.
>
> On 2012-08-09, at 1:53 PM, 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 AM
>> *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 <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth