Sorry. I have to disagree. The way 1.0 is written, it is not a shortcut to turn it into a token for 2.
Phil Sent from my phone. On 2013-02-15, at 13:04, William Mills <wmills_92...@yahoo.com> wrote: > >I've brought it up before, but I think it might be worthwhile, at least as > >an exercise, to define a method to get OAuth1-style tokens from an OAuth2 > >token endpoint. You'd defer to OAuth1 for how to use them >with a protected > >resource. > > YES! > > From: Justin Richer <jric...@mitre.org> > To: Tim Bray <twb...@google.com> > Cc: William Mills <wmills_92...@yahoo.com>; IETF oauth WG <oauth@ietf.org> > Sent: Friday, February 15, 2013 12:54 PM > Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - > 11th February 2013 > > So that you can fetch and manage all your tokens using the same code > paths as the OAuth2 services. The "get a token" part will be identical to > Oauth2 Bearer (except for some details of what comes back from the token > endpoint, of course), it's the "use a token" bit that really changes and is > up in the air. You get to use scopes, and state, and refresh tokens, and all > the other good stuff. > > I've brought it up before, but I think it might be worthwhile, at least as an > exercise, to define a method to get OAuth1-style tokens from an OAuth2 token > endpoint. You'd defer to OAuth1 for how to use them with a protected resource. > > -- Justin > > On 02/15/2013 11:49 AM, Tim Bray wrote: >> 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 > > > > _______________________________________________ > 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
