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

+1

We've supported #3 for quite some time in our public APIs that pre-date 
OAuth.

Thanks,
George

On 8/9/12 3:37 PM, Justin Richer wrote:
> Use case #2: signature protection over plain HTTP parameters
>
> MAC gives us message-level signing in a way that doesn't require all 
> the parameters to be packed into an extra structure, like JWT/SAML do. 
> TLS gives no application-layer verification of integrity of 
> parameters, nor does it give you the ability to know who presented 
> those parameters (unless you're doing mutual TLS, which nobody does). 
> MAC gives you a fairly simple way to protect all parameters on a call 
> to the resource server while still keeping all of those parameters in 
> their native HTTP forms.
>
>
> Use case #3: generic signed HTTP fetch (not directly addressed by MAC 
> spec as of today)
>
> Sometimes you want to create a URL with one service, fix all of the 
> parameters in that URL, and protect those parameters with a signature. 
> Then that URL can be passed to an untrusted service who cannot modify 
> any portion of it. Nor can they re-use the signature portion to 
> protect different parameters. We do this today with a 2-legged OAuth 
> signature across a service URL. The "Client" generates the signed URLs 
> and passes them to a user agent which actually does the fetch to the 
> service.
>
>
>  -- Justin
>
> On 08/09/2012 02:43 PM, William Mills wrote:
>> OK, I'll play and start documenting the use cases.
>>
>> Use case #1: Secure authentication in plain text connections:
>>
>> Some applications need a secure form authorization, but do not want 
>> or need the overhead of encrypted connections.  HTTP cookies and 
>> their ilk are replayable credentials and do not satisfy this need.   
>> the MAC scheme using signed HTTP authorization credentials offer the 
>> capability to securely authorize a transaction, can offer integrity 
>> protection on all or part of an HTTP request, and can provide replay 
>> protection.
>>
>> -bill
>>
>> ------------------------------------------------------------------------
>> *From:* John Bradley <ve7jtb@ve7jtb.com>
>> *To:* William Mills <wmills_92105@yahoo.com>
>> *Cc:* Dick Hardt <dick.hardt@gmail.com>; "oauth@ietf.org" 
>> <oauth@ietf.org>
>> *Sent:* Thursday, August 9, 2012 11:26 AM
>> *Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>
>> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth