[oauth] Re: ProtectServe: centralized and formalized authorization for distributed SPs
Thanks very much to Chris for forwarding this to the more exciting list :-), and obviously we're still keen to get people's thoughts. Eve On Apr 2, 2009, at 7:46 PM, Eran Hammer-Lahav wrote: > This is what made me want to close it. Total lack of activity there > while this list is very active. This is where you get people to pay > attention. > > EHL > > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On > Behalf Of Chris Messina > Sent: Thursday, April 02, 2009 7:41 PM > To: oauth@googlegroups.com > Cc: Eve Maler > Subject: [oauth] Fwd: [oauth-extensions] ProtectServe: centralized > and formalized authorization for distributed SPs > > Just when Eran thought the OAuth Extensions list should go away... > > Check this out: > -- Forwarded message -- > From: Eve Maler > Date: Thu, Apr 2, 2009 at 4:04 PM > Subject: [oauth-extensions] ProtectServe: centralized and formalized > authorization for distributed SPs > To: oauth-extensi...@googlegroups.com > > > > I've been following the recent discussions of four-legged OAuth, > multiple-SP OAuth, and so on with a great deal of interest. Over the > last few days I've published some descriptions of an extension > (application?) of OAuth that I've been working on with a team here at > Sun, which we call ProtectServe. It's something like all of the > above, but also -- I think -- a somewhat distinct set of use cases. I > delayed posting here about it until we could prepare our draft > protocol flows for publication, and now we've done that. > > We'd be very interested to get your comments and feedback on any > aspect of this, and to find out if the use cases across the various > proposed extensions are similar enough to be combined. My > ProtectServe colleagues Paul Bryan and Hubert Le Van Gong are also on > this list, and I hope they will help me in fielding any questions. > > Here are the blog posts I've done on ProtectServe, in chronological > order: > > http://www.xmlgrrl.com/blog/archives/2009/03/23/to-protect-and-to-serve/ > http://www.xmlgrrl.com/blog/archives/2009/03/29/protectserve-getting-down-to-use-cases/ > http://www.xmlgrrl.com/blog/archives/2009/04/02/protectserve-draft-protocol-flows/ > > Thanks, > > Eve > -- > Chris Messina > Citizen-Participant & > Open Web Advocate > > factoryjoe.com // diso-project.org // vidoop.com > This email is: [ ] bloggable[X] ask first [ ] private > Eve Maler eve.maler @ sun.com Emerging Technologies Directorcell +1 425 345 6756 Sun Microsystems Identity Softwarewww.xmlgrrl.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: a simple view of the OAuth security issue
Other than injecting identification into OAuth explicitly, *and* then using a uniform identification system on both the consumer and service provider side (e.g. OpenID), strong equivalence -- test(B==C) -- is impossible. And if identification in any one case is associated with a sufficiently weak or phishable means of authentication, strong equivalence may come into question again. There is great value in OAuth remaining agnostic on the identification question -- for example, it allows OAuth to be applied in "brownfield" situations where the consumer and service provider started out with different systems, vs. creating a hard dependency on a disruptive change to those systems. Many of my use cases depend on parties applying OAuth dynamically without knowing yet if the same identification system is in use. I hope there is interest in developing a solution for the weaker form of equivalence -- min Prob(B! =C) -- perhaps in addition to the strong form. Eve On Apr 26, 2009, at 8:13 AM, Nat wrote: > > > > =...@san Francisco via iPhone > > On 2009/04/26, at 5:38, John Kemp wrote: > >> >> On Apr 26, 2009, at 12:32 AM, Nat Sakimura wrote: >> >>> >>> I agree that "2. test(B==C) , i.e., verify that the user at B is the >>> same user at C" is >>> not the same as "2b. min Prob(B!=C)". >>> >>> The former is clearly more desirable. >> >> +1 >> >>> >>> If someone logs in to the both sites using something like OpenID, >>> then it is trivially achieved without much user interaction impact, >>> assuming OpenID AuthN is safe enough. For example, make >>> verified_identifier a part of tokens. Then, user AuthN at the >>> SP can be done automagically by browser redirect. >> >> Assuming that the "verified_identifier" is the same at both sites, >> and >> that the same user doesn't maintain two OpenIDs... >> > > It is either the verified identifiers matches (among other things) > thus the access is granted or does not match and the authorization > fails. > >> - johnk >> >>> >>> >>> =nat >>> >>> On Sat, Apr 25, 2009 at 8:26 PM, pkeane wrote: >>>> >>>> Sorry: >>>> >>>> Almost all of the proposed solution attempt to minimize the >>>> possibility that user at B is NOT the same as user at C. >>>> >>>> is what it should say... >>>> >>>> On Apr 25, 10:19 pm, pkeane wrote: >>>>> Here is an attempt to help spell out the OAuth security in simple >>>>> terms and thus provide a framework to judge various proposed >>>>> fixes. I >>>>> float this as either a useful shared assumption OR a strawman to >>>>> knock >>>>> down so the the issue can be addressed in some other way. >>>>> >>>>> Eran, in his explanation, outlined there steps that are not >>>>> connected >>>>> but *need* to be connected for the protocol to be secure. >>>>> >>>>> A. user initiates a consumer-to-provider handshake >>>>> B. user logs in to provider (or verifies they are logged in) and >>>>> authorizes this handshake from the provider side >>>>> C. now back at the consumer, users does useful things based on the >>>>> securely transacted handshake >>>>> >>>>> The OAuth spec MUST accomplish either of the following to close >>>>> the >>>>> security hole: >>>>> >>>>> 1. verify that the user at A is the same user at B >>>>> 2. verify that the user at B is the same user at C >>>>> >>>>> Almost all of the proposed solution attempt to minimize the >>>>> possibility that user at B is the same as user at C. Is that >>>>> enough? >>>>> It's true that actual "verification" will impact the user >>>>> experience >>>>> negatively (as actual authentication/verification inevitably >>>>> does). >>>>> >>>>> It's probably worth thinking about what "verification" means and >>>>> how >>>>> that might be achieved. Otherwise, I think the community needs to >>>>> decide if "minimizing possibility" is enough. >>>>> >>>>> --peter keane >>>>> >>>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> http://www.sakimura.org/en/ >>> >>>> >> >> >>> > > > Eve Maler eve.maler @ sun.com Emerging Technologies Directorcell +1 425 345 6756 Sun Microsystems Identity Softwarewww.xmlgrrl.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: a simple view of the OAuth security issue
Peter, thanks for putting the PIN idea in context for me. This is perhaps a dumb question, but since testing equivalence of the *user* (a bag of protoplasm) is sort of a last-mile problem anyway, and since -- if I'm understanding the long Security Advisory discussion thread correctly -- even PINs have social engineering risks, aren't we really just looking for ever-better ways to do "weak" equivalence rather than testing true equivalence? Eve On Apr 27, 2009, at 8:01 AM, Peter Keane wrote: > > On Mon, Apr 27, 2009 at 9:42 AM, Eve Maler wrote: >> >> Other than injecting identification into OAuth explicitly, *and* then >> using a uniform identification system on both the consumer and >> service >> provider side (e.g. OpenID), strong equivalence -- test(B==C) -- is >> impossible. And if identification in any one case is associated with >> a sufficiently weak or phishable means of authentication, strong >> equivalence may come into question again. >> >> There is great value in OAuth remaining agnostic on the >> identification >> question -- for example, it allows OAuth to be applied in >> "brownfield" >> situations where the consumer and service provider started out with >> different systems, vs. creating a hard dependency on a disruptive >> change to those systems. Many of my use cases depend on parties >> applying OAuth dynamically without knowing yet if the same >> identification system is in use. I hope there is interest in >> developing a solution for the weaker form of equivalence -- min >> Prob(B! >> =C) -- perhaps in addition to the strong form. >> > > Hi Eve- > > I completely agree on the need for OAuth to be agnostic re: > identification. My various scenarios "verify" B==C entail a > "temporary" agreement. Specifically, a PIN (or "valet key" as I > called it in a previous proposal) that the user can remember just for > completing the handshake. Essentially, identity in the "local" scope > rather than identity in the "global" scope (e.g., OpenID). OAuth > hooking into a global scope identity creates a dependency that makes > OAuth much less attractive. > > I'm not convinced we need to settle for prob(B!=C), but if a local > scope shared identity mechanism is not implemented (or seen to be too > detrimental to UX), that may be the case. > > --peter > > > >>Eve >> >> On Apr 26, 2009, at 8:13 AM, Nat wrote: >> >>> >>> >>> >>> =...@san Francisco via iPhone >>> >>> On 2009/04/26, at 5:38, John Kemp wrote: >>> >>>> >>>> On Apr 26, 2009, at 12:32 AM, Nat Sakimura wrote: >>>> >>>>> >>>>> I agree that "2. test(B==C) , i.e., verify that the user at B is >>>>> the >>>>> same user at C" is >>>>> not the same as "2b. min Prob(B!=C)". >>>>> >>>>> The former is clearly more desirable. >>>> >>>> +1 >>>> >>>>> >>>>> If someone logs in to the both sites using something like OpenID, >>>>> then it is trivially achieved without much user interaction >>>>> impact, >>>>> assuming OpenID AuthN is safe enough. For example, make >>>>> verified_identifier a part of tokens. Then, user AuthN at the >>>>> SP can be done automagically by browser redirect. >>>> >>>> Assuming that the "verified_identifier" is the same at both sites, >>>> and >>>> that the same user doesn't maintain two OpenIDs... >>>> >>> >>> It is either the verified identifiers matches (among other things) >>> thus the access is granted or does not match and the authorization >>> fails. >>> >>>> - johnk >>>> >>>>> >>>>> >>>>> =nat >>>>> >>>>> On Sat, Apr 25, 2009 at 8:26 PM, pkeane wrote: >>>>>> >>>>>> Sorry: >>>>>> >>>>>> Almost all of the proposed solution attempt to minimize the >>>>>> possibility that user at B is NOT the same as user at C. >>>>>> >>>>>> is what it should say... >>>>>> >>>>>> On Apr 25, 10:19 pm, pkeane wrote: >>>>>>> Here is an attempt to help spell out the OAuth security in >>>>>>> simple >>>
[oauth] OAuth won an award at the European Identity Conference!
Congrats to the entire OAuth community! OAuth won an award for "best new/improved standard in IAM & GRC" (that's "identity and access management" and "governance, risk, and compliance"). If you're curious what this conference and the awards are all about, people have been tweeting it pretty heavily; look for #eic. Eve Eve Maler eve.maler @ sun.com Emerging Technologies Directorcell +1 425 345 6756 Sun Microsystems Identity Softwarewww.xmlgrrl.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth won an award at the European Identity Conference!
(Sorry, been traveling...) There's a physical statuette thingie and a paper certificate that come with the virtual honor :-), and I'll bring those to IIW to transfer them into your care. Will try to take a nice picture of those this weekend. More info about all the award winners can be found here: Award story: http://www.kuppingercole.com/topstory/07.05.2009 Picture: http://www.kuppingercole.com/gallery/eic2009/IMG_6317.jpg.html Sharing the award in the same category with OAuth were ArisID (an open- source project for identity governance frameworks) and its companion standard CARML, and also the Information Card Foundation. Though I didn't see all the talks given this past week, it's possible that my talk was the only one that spent a fair amount of time on OAuth. I believe they're putting videos of all the talks online, but you may have had to attend the conference to get access; will let y'all know. (I'll also put my slides up on my own site soon.) Here's an interview I gave right after doing the talk, where (iirc) the goodness of OAuth got discussed a bit: http://www.id-conf.com/blog/2009/05/06/another-interview/ Lots more interviews of speakers and participant are here: http://www.youtube.com/user/kuppingercole Eve On May 6, 2009, at 10:13 PM, Chris Messina wrote: > Thanks for the note, Eve, and for receiving the award on our behalf! > > Is there anything else we should know about the award? > > Chris > > On Wed, May 6, 2009 at 8:20 PM, Eve Maler wrote: > > Congrats to the entire OAuth community! OAuth won an award for "best > new/improved standard in IAM & GRC" (that's "identity and access > management" and "governance, risk, and compliance"). If you're > curious what this conference and the awards are all about, people have > been tweeting it pretty heavily; look for #eic. > >Eve > > -- > Chris Messina > Open Web Advocate > > factoryjoe.com // diso-project.org // openid.net // vidoop.com > This email is: [ ] bloggable[X] ask first [ ] private > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Seeking feedback on UMA's use of OAuth and discovery mechanisms
The User-Managed Access effort[1], previously mentioned on this list as "ProtectServe", intends to solve user-driven permissioning (authorization) problems at Internet scale. It is designed to be modular, and to reuse and profile existing technology as much as possible. Therefore, we have attempted to "stay out of the business of authentication", profiling OAuth lightly in order to do so. The UMA group would be grateful for your feedback on our intended usage of OAuth and its emerging discovery methods. Details can be found in the worked example in our spec[2]; various explanatory materials about UMA in general are available as well.[3] Briefly, the UMA protocol has four distinct parties vs. OAuth's three: there's an authorizing user, a consumer/client (which we call a"requester"), an SP/server (which we call a "host"), and an authorization manager. We compose three instances of OAuth to introduce all these parties appropriately to each other: there's user/host/AM (three-legged), requester/host (two-legged), and requester/AM (another two-legged). Because of our goals to allow most of these parties to meet fairly dynamically, we are leaning quite heavily on XRD and LRDD for discovery; various simplifying assumptions could probably be made to simplify this picture, however. (If you find UMA's use cases and design center interesting, you'd be very welcome at the table.[4]) Thanks, Eve UMA group chair [1] http://kantarainitiative.org/confluence/display/uma/Home [2] http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol [3] http://kantarainitiative.org/confluence/display/uma/UMA+Explained [4] http://signup.kantarainitiative.org/?selectedGroup=11 Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
[oauth] Re: [OAUTH-WG] Seeking feedback on UMA's use of OAuth and discovery mechanisms
Thanks for taking a look, and I'd say your gloss of it is exactly right. The idea is that externalizing the authorization function from many hosts to a clever enough AM service (there are plenty of UX implications here in addition to protocol stuff) could let you keep better track of your digital footprint, apply consistent policy across various categories (per host, per requester, per resource class...), and even help you extract promises (or payments) from the requester before granting access. The one sub-relationship among the four parties that is the *least* dynamic is the user's introduction of the host to the AM. It's the one prerequisite step before the actual authorization flow. LRDD/XRD comes into play in that first step too, though, enabling the host to learn how to begin authenticating to the AM and subsequently how to send (OAuth-enabled) UMA access requests to it. Swimlane diagrams of the steps are linked off here: > http://kantarainitiative.org/confluence/display/uma/UMA+Explained ...as is a flowchart of the post-step-1 authorization flow. Eve On 23 Nov 2009, at 6:53 PM, John Panzer wrote: > It sounds very interesting. In OAuth terms, I think it adds, to the basic > OAuth 3 legged flow, the ability to delegate the authorization decisions > 'normally' made out of band of the OAuth protocol to a completely separate > service. Aftet 60 seconds looking at it, my first silly question is how the > AM service is determined -- it looks like everything is based on LRDD > starting from the resource being accessed? > > -- > John Panzer / Google > jpan...@google.com / abstractioneer.org / @jpanzer > > > > On Mon, Nov 23, 2009 at 6:04 PM, Eve Maler wrote: > The User-Managed Access effort[1], previously mentioned on this list as > "ProtectServe", intends to solve user-driven permissioning (authorization) > problems at Internet scale. It is designed to be modular, and to reuse and > profile existing technology as much as possible. Therefore, we have attempted > to "stay out of the business of authentication", profiling OAuth lightly in > order to do so. > > The UMA group would be grateful for your feedback on our intended usage of > OAuth and its emerging discovery methods. Details can be found in the worked > example in our spec[2]; various explanatory materials about UMA in general > are available as well.[3] > > Briefly, the UMA protocol has four distinct parties vs. OAuth's three: > there's an authorizing user, a consumer/client (which we call a"requester"), > an SP/server (which we call a "host"), and an authorization manager. We > compose three instances of OAuth to introduce all these parties appropriately > to each other: there's user/host/AM (three-legged), requester/host > (two-legged), and requester/AM (another two-legged). Because of our goals to > allow most of these parties to meet fairly dynamically, we are leaning quite > heavily on XRD and LRDD for discovery; various simplifying assumptions could > probably be made to simplify this picture, however. > > (If you find UMA's use cases and design center interesting, you'd be very > welcome at the table.[4]) > > Thanks, > >Eve >UMA group chair > > [1] http://kantarainitiative.org/confluence/display/uma/Home > [2] http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol > [3] http://kantarainitiative.org/confluence/display/uma/UMA+Explained > [4] http://signup.kantarainitiative.org/?selectedGroup=11 > > > Eve Maler > e...@xmlgrrl.com > http://www.xmlgrrl.com/blog > ___ > OAuth mailing list > oa...@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] Finer-grained access control in OAuth?
ird-party app, the app can access all of >>> user's data in arbitrary way. It is helpful to allow users control 1) >>> which portion of his/her data will be exposed to third-party apps 2) >>> what operations are allowed (read? write? update? etc). >>> I believe OAuth community must have considered this problem before. >>> But it's not included in the spec. I wonder whether there has been >>> serious discussions on this problem. >>> Anyone can point me to some related resources/pages/threads? >>> Thanks >>> >>> Gerald >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "OAuth" group. >>> To post to this group, send email to oa...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> oauth+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/oauth?hl=en. >>> >> >> >> >> -- >> Chris Messina >> Open Web Advocate, Google >> >> Personal: http://factoryjoe.com >> Follow me on Buzz: http://buzz.google.com/chrismessina >> ...or Twitter: http://twitter.com/chrismessina >> >> This email is: [ ] shareable[X] ask first [ ] private >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth" group. >> To post to this group, send email to oa...@googlegroups.com. >> To unsubscribe from this group, send email to >> oauth+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/oauth?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To post to this group, send email to oa...@googlegroups.com. > To unsubscribe from this group, send email to > oauth+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. > Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] Re: What's in an access token?
Hi Jørn, For what it's worth, in the UMA work (built on top of OAuth), we are working on the option for a resource server to outsource the validation of the token back out to the authorization server, rather than validating it locally. Since in our case the two servers may be in different administrative domains, this can greatly simplify the configuration that would have to happen between them, as well as present other new opportunities. (E.g., the authorization server can serve as a true policy decision point.) There is also an aspect of claims-based authorization in UMA, but we do it a little differently than you might be thinking. The client may need to present claims to the authz server in order to satisfy user policy (agrees to terms XYZ, controls em...@domain.com, is over 18...), which leads to an access token being granted. Eve On 1 Sep 2010, at 10:34 PM, Jørn Wildt wrote: > Yes, SWT or similar was what I was looking for. But all I could find > was, well, nothing, and people indicating that SWT is dead - or at > least not part of OAuth. > > Originally I was looking for a claims based security standard for a > REST API. That's why I ended up with OAuth - but having finally > figured out the inner workings of OAuth, I see that OAuth is not > claims based (at least not in the token). It's only federated, which > is certainly good! But I was hoping to find something for REST that > SAML does for SOAP: a standard for sending claims with each request. > > Thanks, Jørn > > On Sep 1, 10:19 pm, Dick Hardt wrote: >> There were a couple of documents that described standard access tokens. SWT >> (Simple Web Token was one of those) >> >> The WRAP and OAuth work specifically were token agnostic. >> >> -- Dick >> >> On 2010-08-31, at 11:54 PM, Jørn Wildt wrote: >> >>> Thanks! So OAuth is only concerned with the actual exchange of the >>> authorization token and access token - not what's in them. Further: >>> it's up to the OAuth vendor to decide how it should handle those >>> tokens internally. >> >>> For instance: When an end user grants access to something, then this >>> is registered internally in the application, and when a resource >>> webservice receives the access token, it looks it up in the internal >>> register to see what it is valid for? The specs say nothing about what >>> the webservice should do with that token. Right? >> >>> /Jørn >> >>> On Sep 1, 7:58 am, John Kristian wrote: >>>> It's vendor specific. >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "OAuth" group. >>> To post to this group, send email to oa...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> oauth+unsubscr...@googlegroups.com. >>> For more options, visit this group >>> athttp://groups.google.com/group/oauth?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To post to this group, send email to oa...@googlegroups.com. > To unsubscribe from this group, send email to > oauth+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. > > Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
[oauth] Good list of OAuth open source?
The list at http://oauth.net/code/ seems really random and out of date. Does anyone have a current list of open-source software that supports OAuth, including drafts of 2.0? Thanks, Eve Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
Re: [oauth] Question about the OAuth RFC
OAuth has a "soft" assumption, which surfaces in the passage you quote among a few other places, that the resource owner is the party operating the client. I'd say the original OAuth flows made a harder assumption around this, but V2.0 is more of a framework that admits profiling delegated authorization for multiple purposes. The User-Managed Access (UMA) profile of OAuth challenges the assumption by defining a resource owner and a requesting party, where they may or may not be identical, and then defining flows that enable a strict separation between them, including allowing the resource owner to be completely offline and unavailable when a requesting party, wielding some client app, attempts access to a protected resource. OAuth's assumption, and a way to start rectifying it, is discussed in Nat Sakimura's blog post here: http://nat.sakimura.org/2012/12/30/re-limitations-of-the-oauth-2-0-definition-of-client/ The broader implications of allowing a truly autonomous third party can be seen in this I-D, which accompanies the UMA technical spec: http://tools.ietf.org/html/draft-maler-oauth-umatrust-00 Eve On 19 Mar 2013, at 8:10 PM, John Smith wrote: > Hi all, I have a question about the Oauth RFC. > > I'm reading this RFC on Oauth: > http://tools.ietf.org/html/rfc6749 > > I get to this point: > > Quote > In the traditional client-server authentication model, the client > requests an access-restricted resource (protected resource) on the > server by authenticating with the server using the resource owner's > credentials. In order to provide third-party applications access to > restricted resources, the resource owner shares its credentials with > the third party. This creates several problems and limitations: > > Who would be the resource owner in this case? The client? I see primarily 3 > parties involved: the host, the client and the 3rd party that wants what the > client has access to. > > > This is how I view this universe based on reading that paragraph. > > ++ ++ +-+ > | Client | --- > | Resource Owner | --- > | Resource Server | > ++ ++ +-+ > So, lets say that the "Resource Server" is facebook and the "Resource Owner" > is Bob (he posts pictures and greets his friends on there), but he would like > to give access to a Desktop app -- the "Client" -- to collect some metrics on > his media (the scope of this access can be defined). So, "Resource Owner" > Bob would log into "Resource Server" facebook, generate a token and paste it > into the "Client" Desktop app and have that little puppy go on its merry way. > > Is my explanation sensible? Am I missing something? > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to oauth+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to oauth+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [oauth] Question about the OAuth RFC
Here's my take. If you are the resource owner and also the "requesting party" operating a particular client (the classic OAuth case), you should typically be able to visit the app that serves as the authorization server, "browse" among the various clients that were granted access on your behalf, and revoke access to selective clients. You can see this at work with, e.g., Twitter: While logged in to its site, go to Settings->Apps, and you'll see all the clients that were given access previously on your say-so. You can hit the "Revoke access" button for any one client, which immediately revokes that client's ability to do what it was doing before. It's up to the AS app to provide this revocation function and to give you audit-style visibility into what that client did; the sky's the limit, but it's not dictated by OAuth itself. HTH! Eve On 19 Mar 2013, at 10:12 PM, John Smith wrote: > Ok. I think I get it. I'll probably be asking more questions about this :) . > > Basically, if I wanted to give a client access to a resource and then monitor > what the client does with the resource (enters data, pulls reports, etc.), > oauth would provide me a means to do this, yes? It would also allow me to > grant access in certain instances based on the way the authentication server > is configured, yes? > > On Wednesday, March 20, 2013 1:01:46 AM UTC-4, Eve Maler wrote: > OAuth has a "soft" assumption, which surfaces in the passage you quote among > a few other places, that the resource owner is the party operating the > client. I'd say the original OAuth flows made a harder assumption around > this, but V2.0 is more of a framework that admits profiling delegated > authorization for multiple purposes. > > The User-Managed Access (UMA) profile of OAuth challenges the assumption by > defining a resource owner and a requesting party, where they may or may not > be identical, and then defining flows that enable a strict separation between > them, including allowing the resource owner to be completely offline and > unavailable when a requesting party, wielding some client app, attempts > access to a protected resource. > > OAuth's assumption, and a way to start rectifying it, is discussed in Nat > Sakimura's blog post here: > > http://nat.sakimura.org/2012/12/30/re-limitations-of-the-oauth-2-0-definition-of-client/ > > The broader implications of allowing a truly autonomous third party can be > seen in this I-D, which accompanies the UMA technical spec: > > http://tools.ietf.org/html/draft-maler-oauth-umatrust-00 > > Eve > > On 19 Mar 2013, at 8:10 PM, John Smith wrote: > >> Hi all, I have a question about the Oauth RFC. >> >> I'm reading this RFC on Oauth: >> http://tools.ietf.org/html/rfc6749 >> >> I get to this point: >> >> Quote >> In the traditional client-server authentication model, the client >> requests an access-restricted resource (protected resource) on the >> server by authenticating with the server using the resource owner's >> credentials. In order to provide third-party applications access to >> restricted resources, the resource owner shares its credentials with >> the third party. This creates several problems and limitations: >> >> Who would be the resource owner in this case? The client? I see primarily >> 3 parties involved: the host, the client and the 3rd party that wants what >> the client has access to. >> >> >> This is how I view this universe based on reading that paragraph. >> >> ++ ++ +-+ >> | Client | --- > | Resource Owner | --- > | Resource Server | >> ++ ++ +-+ >> So, lets say that the "Resource Server" is facebook and the "Resource Owner" >> is Bob (he posts pictures and greets his friends on there), but he would >> like to give access to a Desktop app -- the "Client" -- to collect some >> metrics on his media (the scope of this access can be defined). So, >> "Resource Owner" Bob would log into "Resource Server" facebook, generate a >> token and paste it into the "Client" Desktop app and have that little puppy >> go on its merry way. >> >> Is my explanation sensible? Am I missing something? >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth" group. >> To unsubscribe from this group and stop receiving emails from it, send an >>
