Hi Bill, I think one needs to compare the costs/impact of HTTPS on one side and the implementation of integrity protection and replay detection on the other. We had this discussion several times.
regards, Torsten. Am 15.02.2013 um 08:08 schrieb William Mills <wmills_92...@yahoo.com>: > I fundamentally disagree with that too. OAuth 2 is the *framework*, one > which supports multiple token types. Bearer tokens were the first credential > type defined. > > OAuth 1.0a also requires HTTPS transport for authentication and getting the > token. > > There are real use cases for tokens usable over plain text with integrity > protection. > > -bill > > From: Torsten Lodderstedt <tors...@lodderstedt.net> > To: William Mills <wmills_92...@yahoo.com> > Cc: Mike Jones <michael.jo...@microsoft.com>; Justin Richer > <jric...@mitre.org>; Phil Hunt <phil.h...@oracle.com>; IETF oauth WG > <oauth@ietf.org> > Sent: Thursday, February 14, 2013 10:05 PM > Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - > 11th February 2013 > > Hi Bill, > > OAuth 2.0 took a different direction by relying on HTTPS to provide the basic > protection. So the need to have a token, which can be used for service > requests over plain HTTP is arguable. My understanding of this activity was, > the intend is to provide additional protection on top of HTTPS. > > regards, > Torsten. > > Am 15.02.2013 um 02:31 schrieb William Mills <wmills_92...@yahoo.com>: > >> I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth >> 2.0 solved in the first place.", unless "solving" means does not address the >> need for it at all. >> >> OAuth 2 does several good things, but it still lacks a defined token type >> that is safe to user over plain text HTTP. 1.0a solved that. >> >> From: Mike Jones <michael.jo...@microsoft.com> >> To: Justin Richer <jric...@mitre.org>; Phil Hunt <phil.h...@oracle.com> >> Cc: IETF oauth WG <oauth@ietf.org> >> Sent: Thursday, February 14, 2013 1:44 PM >> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - >> 11th February 2013 >> >> I'm in favor of reusing the JWT work that this WG is also doing. :-) >> >> I'm pretty skeptical of us inventing another custom scheme for signing HTTP >> headers. That was the impediment to OAuth 1.0 adoption that OAuth 2.0 >> solved in the first place. >> >> -- Mike >> >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >> Justin Richer >> Sent: Tuesday, February 12, 2013 9:35 AM >> To: Phil Hunt >> Cc: IETF oauth WG >> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - >> 11th February 2013 >> >> That's my reading of it as well, Phil, thanks for providing the >> clarification. One motivator behind using a JSON-based token is to be able >> to re-use some of the great work that the JOSE group is doing but apply it >> to an HTTP payload. >> >> What neither of us want is a token type that requires stuffing all query, >> header, and other parameters *into* the JSON object itself, which would be a >> more SOAPy approach. >> >> -- Justin >> >> On 02/12/2013 12:30 PM, Phil Hunt wrote: >> > Clarification. I think Justin and I were in agreement that we don't want >> > to see a format that requires JSON payloads. We are both interested in a >> > JSON token used in the authorization header that could be based on a >> > computed signature of some combination of http headers and body if >> > possible. >> > >> > Phil >> > >> > @independentid >> > www.independentid.com >> > phil.h...@oracle.com >> > >> > >> > >> > >> > >> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote: >> > >> >> Here are my notes. >> >> >> >> Participants: >> >> >> >> * John Bradley >> >> * Derek Atkins >> >> * Phil Hunt >> >> * Prateek Mishra >> >> * Hannes Tschofenig >> >> * Mike Jones >> >> * Antonio Sanso >> >> * Justin Richer >> >> >> >> Notes: >> >> >> >> My slides are available here: >> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt >> >> >> >> Slide #2 summarizes earlier discussions during the conference calls. >> >> >> >> -- HTTP vs. JSON >> >> >> >> Phil noted that he does not like to use the MAC Token draft as a starting >> >> point because it does not re-use any of the work done in the JOSE working >> >> group and in particular all the libraries that are available today. He >> >> mentioned that earlier attempts to write the MAC Token code lead to >> >> problems for implementers. >> >> >> >> Justin responded that he does not agree with using JSON as a transport >> >> mechanism since this would replicate a SOAP style. >> >> >> >> Phil noted that he wants to send JSON but the signature shall be computed >> >> over the HTTP header field. >> >> >> >> -- Flexibility for the keyed message digest computation >> >> >> >> From earlier discussion it was clear that the conference call >> >> participants wanted more flexibility regarding the keyed message digest >> >> computation. For this purpose Hannes presented the DKIM based approach, >> >> which allows selective header fields to be included in the digest. This >> >> is shown in slide #4. >> >> >> >> After some discussion the conference call participants thought that this >> >> would meet their needs. Further investigations would still be useful to >> >> determine the degree of failed HMAC calculations due to HTTP proxies >> >> modifying the content. >> >> >> >> -- Key Distribution >> >> >> >> Hannes presented the open issue regarding the choice of key >> >> distribution. Slides #6-#8 present three techniques and Hannes asked >> >> for feedback regarding the preferred style. Justin and others didn't >> >> see the need to decide on one mechanism - they wanted to keep the >> >> choice open. Derek indicated that this will not be an acceptable >> >> approach. Since the resource server and the authorization server may, >> >> in the OAuth 2.0 framework, be entities produced by different vendors >> >> there is an interoperability need. Justin responded that he disagrees >> >> and that the resource server needs to understand the access token and >> >> referred to the recent draft submission for the token introspection >> >> endpoint. Derek indicated that the resource server has to understand >> >> the content of the access token and the token introspection endpoint >> >> just pushes the problem around: the resource server has to send the >> >> access token to the authorization server and then the resource server >> >> gets the result back (which he the >> n >> > a >> >> gain needs to understand) in order to make a meaningful authorization >> >> decision. >> >> >> >> Everyone agreed that the client must receive the session key from the >> >> authorization server and that this approach has to be standardized. It >> >> was also agreed that this is a common approach among all three key >> >> distribution mechanisms. >> >> >> >> Hannes asked the participants to think about their preference. >> >> >> >> The questions regarding key naming and the indication for the intended >> >> resource server the client wants to talk to have been postponed. >> >> >> >> Ciao >> >> Hannes >> >> >> >> >> >> _______________________________________________ >> >> 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
