Those reasons make sense to me, thanks for enumerating. On Aug 10, 2012, at 9:25 AM, Justin Richer wrote:
> The reason is simple: to benefit from the rest of the improvements in the > OAuth2 framework. These are just the ones off the top of my head: > > 1) Multiple means for getting a token (all the flows are now available) > 2) No request tokens > 3) No reliance on per-client secrets (though, addendum, I think the MAC spec > should be augmented to use them if present) > 4) Ability to integrate with many different extensions to OAuth2, both now > and in the future > > -- Justin > > On 08/10/2012 12:18 PM, Dick Hardt wrote: >> As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying. >> >> Given that, there is also a clear need for signing an HTTP(S) request as >> some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to >> use bearer tokens. >> >> I never followed what MAC solved that OAuth 1.0A did not solve. Would >> someone elaborate? We do have an RFC for signing requests, there are lots of >> libraries already. Why the desire to reinvent OAuth 1.0A? >> >> -- Dick >> >> On Aug 10, 2012, at 8:00 AM, Rob Richards wrote: >> >>> I think you nailed it which that statement. Up until now it as been back >>> and forth about one or the other. Personally I prefer to used layered >>> security and not relying on a single point of attack. It's unrealistic to >>> say everyone is going to want/need/be able to use (take your pick) >>> signed/encrypted JWT. MAC at least offers an alternative, less complicated >>> solution. >>> >>> Rob >>> >>> On 8/10/12 10:41 AM, Richer, Justin P. wrote: >>>> What about security in depth? Signing + TLS is more secure than either >>>> alone, isn't it? >>>> >>>> -- Justin >>>> >>>> On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote: >>>> >>>>> Hi Bill, >>>>> >>>>> thanks for the feedback. Let's have a look at this use case: >>>>> >>>>> You need to provide me a bit more information regarding your use case. >>>>> Could you please explain >>>>> >>>>> 1) Who is authenticated to whom? >>>>> 2) What plaintext connection are you talking about? >>>>> 3) What is the problem with encrypted connections? Is this again the "TLS >>>>> has so bad performance" argument? >>>>> 4) Since you are talking about cookies and making them more secure are >>>>> you trying to come up with a general solution to better cookie security - >>>>> a topic others are working on as well. >>>>> 5) What is the threat you are concerned about? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> PS: I would heavily argue against standardize a security mechanism that >>>>> offers weaker protection than bearer when the entire argument has always >>>>> been "Bearer is so insecure and we need something stronger." >>>>> >>>>> On Aug 9, 2012, at 9: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 <ve7...@ve7jtb.com> >>>>>> To: William Mills <wmills_92...@yahoo.com> >>>>>> Cc: Dick Hardt <dick.ha...@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.ha...@gmail.com> >>>>>>> To: William Mills <wmills_92...@yahoo.com> >>>>>>> Cc: "oauth@ietf.org" <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 >>>>>>> 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 >>>> _______________________________________________ >>>> 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
