Not deeply acquainted with the Flickr scenario, but it occurs to me to ask: If OAuth 1.0 is working well for them, why don’t they just keep using it? I.e. if there’s already a good solution in place for people who require secure authn/authz over insecure channels, why would we go the extra work of duplicating that in OAuth 2 territory? -T
On Fri, Feb 15, 2013 at 8:09 AM, William Mills <wmills_92...@yahoo.com>wrote: > I'll repeat the use case for Flickr, which requires OAuth 1.0a type > capabilites that OAuth 2 does not provide. Simply stating "move to HTTPS" > is not a viable response here. > > ------------------------------ > *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:* Friday, February 15, 2013 7:22 AM > *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference > Call - 11th February 2013 > > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
