[oauth] Re: signing post requests
Check out http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html EHL --~--~-~--~~~---~--~~ 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: signing post requests
> I think Perryn posted to the oauth-ruby list, where we > should continue this discussion. Yes, sorry I intended for the discussion of the ruby implementation on the oauth-ruby list. The reason I posted it here too was to ask about the spec ( although that isn't very clear from my original post ) The spec only seems to set out how to include a post body in the signature if it is x-www-form-urlencoded data, and indeed EHL has replied stating that this is all that is supported. I am currently working on a project to expose a developer api to our systems. The vision is for this to be a RESTful interface where we exchange payloads of XML. For some operations, the payload would be passed in a post body. Hence, this raises a few questions for me a) It would appear then that oAuth is unsuitable for this type of undertaking? I am a bit surprised as I would have thought it would be a common use case - Is there a reason why this was explicitly not supported? b) Is anyone out there doing this type of thing? Have you extended oAuth to do it? If not, what are you using? c) Not really a question, but the only reason this came to my attention is that the signatures did not match because the provider interpreted the entire payload as a parameter name. I suspect that this is a rails foible, so on other platforms the signatures may match because the payload is not included in the signature at either end. If people haven't noticed this, they may not realise their payloads are insecure. cheers Perryn --~--~-~--~~~---~--~~ 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] Parameters required for fetching Google data services using OAuth
Hi Guys, Can you tell me the parameters required for fetching Google data services through AJAX request OAuth)?. I have got the authorized access token. But still I cannot able to fetch data using that. Thanks Razak K --~--~-~--~~~---~--~~ 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: iPhone UIWebView, OAuth and User-Agent trust
Hi Darren, On 2 Feb 2009, at 09:40, Darren Bounds wrote: > Recently my colleague and I began looking a little closer at the > iPhone SDK in an effort to research how to best incorporate an OAuth > authorization model. Naturally UIWebView was front and center as it > currently provides the only method (at least that I'm aware of) for an > application to transition between itself and the browser without > requiring the user to re-launch the application. While at a glance, > this appeared ideal for OAuth, I became concerned when it was apparent > that all interaction, including HTTP request/response data, would be > fully accessible to the parent application via UIWebView. > I'm curious if the group has any thoughts or greater insight into > UIWebView security model and its impact on user-agent trust and > privacy on the iPhone. Hopefully I've missed something. With Fire Eagle, we came to the same wary conclusion and our current response is to say ‘Don't use UIWebViews (or equivalent) please’. However, there's a little bit more to the iPhone OS ux that you've not covered here, which alleviates the user manually relaunching apps. In short, iPhone OS2 allows you to register application protocols (such as ‘pownce://’) and use that to callback from the web app. The result is that you app gets relaunched gracefully after auth is completed, without any manual intervention. We documented all of our Fire Eagle related advice, and tried to cover the basics of creating app-protocols on major platforms: http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice Cheers, Ben --~--~-~--~~~---~--~~ 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: Distinction between Request Token and Access token
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 2, 2009 at 9:20 AM, Hans Granqvist wrote: > > It's a trade-off I am sure, but I would have loved it if the > standard had > decoupled the token issuer from the token verifier. In that way, > you would > not need the dance of triage; the consumer simply present a correct > token > to access a resource. "Correctness" can be ascertained solely from the > presented token + presenter's identity. In that way the token can > be issued > by anyone at anytime. > > SAML and Kerberos anyone? ;) I've thought the same thing. OpenID-OAuth Hybrid is exactly about that separation, replacing the old issuing dance with a new one. Verification needs to stay the same. At that point, the only difference between OAuth and SAML or Kerberos is that there is no standard way to present credentials to Authorization endpoint. I assume this will be handled by an extension in the near future, allowing one consumer to present its credentials to authorize another consumer's token. I think someone might be calling it transferable tokens in some extension? I've also hoped the token would begin to take a more capability-like role. All that would be needed would be to explicitly mention the resources the token grants access to, and the rights it provides. http://josephholsten.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmHgR8ACgkQrPgSa0qMrmE1agCfeec4lFTZaUAHeYHs6kjGzhzc 9ZkAn0QxWVvzbu44YZDddTgBYs1xKIzj =nV99 -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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: Distinction between Request Token and Access token
On Mon, Feb 2, 2009 at 9:20 AM, Hans Granqvist wrote: > > > The reasoning behind this is that while "scope" is a common approach, > > it's not the only approach. For example, I may want to simply limit > > access to "read-only/write-only/read-write", or maybe (e.g., for > > academic article databases) "link/abstract/full article", or any > > number of other possibilities and intersections. There's no way that > > OAuth could or should describe these possibilities. > > But... could not all operations be reduced to a set of HTTP operations > on URLs? As HTTP verbs against a representation? > > It seems anything that you want to manipulate should be able to be > represented itself as a resource. Although I have mellowed a bit, one of > my pet peeves around OAuth is that the protocol doesn't follow this web > philosophy. I'm curious what you think about Ian McKellar's concept of "authorized changesets": http://ianloic.com/2009/01/05/a-different-model-for-web-services-authorization/ The time delay to approve the changes sounds less than ideal, but still worth contemplating. > It's a trade-off I am sure, but I would have loved it if the standard had > decoupled the token issuer from the token verifier. In that way, you would > not need the dance of triage; the consumer simply present a correct token > to access a resource. "Correctness" can be ascertained solely from the > presented token + presenter's identity. In that way the token can be issued > by anyone at anytime. > > SAML and Kerberos anyone? ;) I don't think that that's the behavior that we saw in the wild. Perhaps it's something to bring up on the OAuth list for future work? Chris -- Chris Messina Citizen-Participant & Open Web Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # 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] Re: Unable to fetch data from service provide using OAuth
> I am passing all the required parameters. but still I am not getting > any output. > > I am getting connection timed out error. > > I have got the access token along with token secret. Using that, I am > trying to fetch calender data. When you try to fetch the feed with the access token, Google responds with a redirect. The URL of the redirect will contain an extra session parameter that wasn't in your original request, so your OAuth signature will be invalid for this request. Therefore, you cannot just follow the redirect. Instead, you need to generate a fresh request. --~--~-~--~~~---~--~~ 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 only for HTTP request signing?
Hi, IMHO, you should raise this in the IETF list as it pertains to the charter. I think this is an important topic. Cheers |-Original Message- |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf |Of Onyx Raven |Sent: Monday, February 02, 2009 11:16 AM |To: oauth@googlegroups.com |Subject: [oauth] OAuth only for HTTP request signing? | | |I see the following line in the ITEF charter: | | * A mechanism for signing HTTP requests with the token-secret pair | |Is the 'core' OAuth specification going to be limited only to HTTP, or |is there opportunity and reason to make it a general method of signing |method, resource and parameters of a programmatic request for the |purpose of consumer authorization and user credential delegation? It |seems like other protocols could use the same signing and delegation |methodology (probably with some hybrid using HTTP), but may not be |'traditional' HTTP (eg, XMPP http://xmpp.org/extensions/xep-0235.html) |during requests. Or, would the 'extensions' go the other way, defining |how other protocols might use the same methods, or in a generic sense? | |I guess I wonder if defining only HTTP and not calling out generic |usage could make using OAuth in other areas somewhat more difficult |from a standards perspective. | |(I wasn't sure which list to ask this on - it seems somewhat more to |do with Core than the current discussions on the ITEF list) | | --~--~-~--~~~---~--~~ 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] OAuth only for HTTP request signing?
I see the following line in the ITEF charter: * A mechanism for signing HTTP requests with the token-secret pair Is the 'core' OAuth specification going to be limited only to HTTP, or is there opportunity and reason to make it a general method of signing method, resource and parameters of a programmatic request for the purpose of consumer authorization and user credential delegation? It seems like other protocols could use the same signing and delegation methodology (probably with some hybrid using HTTP), but may not be 'traditional' HTTP (eg, XMPP http://xmpp.org/extensions/xep-0235.html) during requests. Or, would the 'extensions' go the other way, defining how other protocols might use the same methods, or in a generic sense? I guess I wonder if defining only HTTP and not calling out generic usage could make using OAuth in other areas somewhat more difficult from a standards perspective. (I wasn't sure which list to ask this on - it seems somewhat more to do with Core than the current discussions on the ITEF list) --~--~-~--~~~---~--~~ 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: iPhone UIWebView, OAuth and User-Agent trust
Darren, Please join us on the new Objective-C OAuth list: http://groups.google.com/group/oauth-objective-c -Jon On Mon, Feb 2, 2009 at 9:40 AM, Darren Bounds wrote: > > Recently my colleague and I began looking a little closer at the > iPhone SDK in an effort to research how to best incorporate an OAuth > authorization model. Naturally UIWebView was front and center as it > currently provides the only method (at least that I'm aware of) for an > application to transition between itself and the browser without > requiring the user to re-launch the application. While at a glance, > this appeared ideal for OAuth, I became concerned when it was apparent > that all interaction, including HTTP request/response data, would be > fully accessible to the parent application via UIWebView. > > From my perspective, one of the greatest architectural features of the > OAuth and OpenID protocols is the complete absence of any requirement > the user place trust in the application they're authorizing or > authenticating to. This doesn't appear to be possible through > UIWebView as the application has the ability to capture any and all > interaction, regardless of whether SSL is employed. > > I'm curious if the group has any thoughts or greater insight into > UIWebView security model and its impact on user-agent trust and > privacy on the iPhone. Hopefully I've missed something. > > > References: > > UIWebView > > https://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIWebView_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40006950-CH3-SW11 > > UIWebViewDelegate > > https://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIWebViewDelegate_Protocol/Reference/Reference.html > > NSURLRequest > > https://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Classes/NSURLRequest_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSURLRequest > > > Thanks, > Darren > > -- > darren bounds > dar...@cliqset.com > > > > --~--~-~--~~~---~--~~ 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: Unable to fetch data from service provide using OAuth
For Google specific issues, you will find more help here: http://groups.google.com/group/Google-Accounts-API Vince. On Mon, Feb 2, 2009 at 6:12 AM, Razak wrote: > > Hi Guys, > > I am using Google API for fetching data from service provider using > OAuth through AJAX request. > > I am passing all the required parameters. but still I am not getting > any output. > > I am getting connection timed out error. > > I have got the access token along with token secret. Using that, I am > trying to fetch calender data. I > > have used all the parameters specified in the Google spec. I have > changed the content type to > > application/atom+xml also. but no luck. > > Can you tell me the parameters required for fetching data?. Do you any > code that works well for this?. > > Thanks in advance. > > Razak K > > > > > --~--~-~--~~~---~--~~ 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] iPhone UIWebView, OAuth and User-Agent trust
Recently my colleague and I began looking a little closer at the iPhone SDK in an effort to research how to best incorporate an OAuth authorization model. Naturally UIWebView was front and center as it currently provides the only method (at least that I'm aware of) for an application to transition between itself and the browser without requiring the user to re-launch the application. While at a glance, this appeared ideal for OAuth, I became concerned when it was apparent that all interaction, including HTTP request/response data, would be fully accessible to the parent application via UIWebView. >From my perspective, one of the greatest architectural features of the OAuth and OpenID protocols is the complete absence of any requirement the user place trust in the application they're authorizing or authenticating to. This doesn't appear to be possible through UIWebView as the application has the ability to capture any and all interaction, regardless of whether SSL is employed. I'm curious if the group has any thoughts or greater insight into UIWebView security model and its impact on user-agent trust and privacy on the iPhone. Hopefully I've missed something. References: UIWebView https://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIWebView_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40006950-CH3-SW11 UIWebViewDelegate https://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIWebViewDelegate_Protocol/Reference/Reference.html NSURLRequest https://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Classes/NSURLRequest_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSURLRequest Thanks, Darren -- darren bounds dar...@cliqset.com --~--~-~--~~~---~--~~ 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: Distinction between Request Token and Access token
> The reasoning behind this is that while "scope" is a common approach, > it's not the only approach. For example, I may want to simply limit > access to "read-only/write-only/read-write", or maybe (e.g., for > academic article databases) "link/abstract/full article", or any > number of other possibilities and intersections. There's no way that > OAuth could or should describe these possibilities. But... could not all operations be reduced to a set of HTTP operations on URLs? As HTTP verbs against a representation? It seems anything that you want to manipulate should be able to be represented itself as a resource. Although I have mellowed a bit, one of my pet peeves around OAuth is that the protocol doesn't follow this web philosophy. It's a trade-off I am sure, but I would have loved it if the standard had decoupled the token issuer from the token verifier. In that way, you would not need the dance of triage; the consumer simply present a correct token to access a resource. "Correctness" can be ascertained solely from the presented token + presenter's identity. In that way the token can be issued by anyone at anytime. SAML and Kerberos anyone? ;) Hans --~--~-~--~~~---~--~~ 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: signing post requests
It sounds like the ruby library may be accidentally pulling in those parameters. I think Perryn posted to the oauth-ruby list, where we should continue this discussion. b. On Mon, Feb 2, 2009 at 4:07 PM, Eran Hammer-Lahav wrote: > > OAuth core does not support body signatures expect for www-encoded-form. > > EHL > >> -Original Message- >> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf >> Of Perryn Fowler >> Sent: Monday, February 02, 2009 4:37 AM >> To: OAuth Ruby >> Cc: oauth@googlegroups.com >> Subject: [oauth] signing post requests >> >> >> I have set up a small test consumer app and a small test provider app >> - both rails apps. >> The consumer app is using the oauth ruby gem and the provider app is >> using the plugin. >> (I have found and addressed the issues that have been mentioned here >> recently with the plugin and the new version of the gem) >> >> I am trying to post some XML from the consumer app to the provider app >> and authorize it via oAuth. >> >> Unfortunately I keep getting signature verification errors. >> >> The problem seems to be that the raw XML is being posted as the >> request body. The consumer app does not appear to consider this to >> qualify as a 'parameter' for the purposes , while the provider app >> does ( probably because rails does?) >> >> Admittedly the spec only really mentions bonafide parameters, but it >> would seem in this use case you would definately want to have the xml >> payload included in the signature.. >> >> or have I missed something? >> >> >> cheers >> Perryn >> >> > > > > --~--~-~--~~~---~--~~ 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: signing post requests
OAuth core does not support body signatures expect for www-encoded-form. EHL > -Original Message- > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf > Of Perryn Fowler > Sent: Monday, February 02, 2009 4:37 AM > To: OAuth Ruby > Cc: oauth@googlegroups.com > Subject: [oauth] signing post requests > > > I have set up a small test consumer app and a small test provider app > - both rails apps. > The consumer app is using the oauth ruby gem and the provider app is > using the plugin. > (I have found and addressed the issues that have been mentioned here > recently with the plugin and the new version of the gem) > > I am trying to post some XML from the consumer app to the provider app > and authorize it via oAuth. > > Unfortunately I keep getting signature verification errors. > > The problem seems to be that the raw XML is being posted as the > request body. The consumer app does not appear to consider this to > qualify as a 'parameter' for the purposes , while the provider app > does ( probably because rails does?) > > Admittedly the spec only really mentions bonafide parameters, but it > would seem in this use case you would definately want to have the xml > payload included in the signature.. > > or have I missed something? > > > cheers > Perryn > > --~--~-~--~~~---~--~~ 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: Distinction between Request Token and Access token
I see. Which resources are accesible and which are not are part of an offline agreement between Service Provider and User, and hence are out of the scope of the spec. And I agree with your reasoning about the temporal states. Thanks a lot to all of you, you've helped me a lot. Greetings, Jorgito --~--~-~--~~~---~--~~ 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] Unable to access OAuth Tokens in the first attempt.
Hi Guys, I am using Google's OAuth for accessing data using AJAX. We are facing a problem while accessing request & access tokens in OAuth. Sometimes we are getting the tokens in the first attempt itself & some times we are not at all getting the tokens with the same set of parameters in the request. I am passing the correct set of parameters for the token's request What would be the problem? Thanks in advance. Razak K --~--~-~--~~~---~--~~ 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] Unable to fetch data from service provide using OAuth
Hi Guys, I am using Google API for fetching data from service provider using OAuth through AJAX request. I am passing all the required parameters. but still I am not getting any output. I am getting connection timed out error. I have got the access token along with token secret. Using that, I am trying to fetch calender data. I have used all the parameters specified in the Google spec. I have changed the content type to application/atom+xml also. but no luck. Can you tell me the parameters required for fetching data?. Do you any code that works well for this?. Thanks in advance. Razak K --~--~-~--~~~---~--~~ 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] signing post requests
I have set up a small test consumer app and a small test provider app - both rails apps. The consumer app is using the oauth ruby gem and the provider app is using the plugin. (I have found and addressed the issues that have been mentioned here recently with the plugin and the new version of the gem) I am trying to post some XML from the consumer app to the provider app and authorize it via oAuth. Unfortunately I keep getting signature verification errors. The problem seems to be that the raw XML is being posted as the request body. The consumer app does not appear to consider this to qualify as a 'parameter' for the purposes , while the provider app does ( probably because rails does?) Admittedly the spec only really mentions bonafide parameters, but it would seem in this use case you would definately want to have the xml payload included in the signature.. or have I missed something? cheers Perryn --~--~-~--~~~---~--~~ 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: Distinction between Request Token and Access token
On Mon, Feb 2, 2009 at 9:23 AM, Jorgito wrote: > > Krishna: that's exactly what I mean, granularity in time and > granularity in the space of resources. The granularity in time is > already implemented in OAuth, but the granularity in resources... > maybe it's implicit in some field of some message, but I can't find it > in the spec! The granularity of resources isn't implicit in any field; it's up to the Service Provider to decide what resources can be accessed. How the Consumer and Service Provider agree on which resources to give access to (in the Authorization step), is entirely dependent on the Service Provider's API. The reasoning behind this is that while "scope" is a common approach, it's not the only approach. For example, I may want to simply limit access to "read-only/write-only/read-write", or maybe (e.g., for academic article databases) "link/abstract/full article", or any number of other possibilities and intersections. There's no way that OAuth could or should describe these possibilities. As far as the scalability of temporal states, the raw storage of OAuth tokens over time isn't an issue; for the largest organizations like Google, storage of key-value pairs is trivial and "infinitely" scalable. For smaller organizations with up to around 100 million OAuth tokens, a single modern database server should be able to easily handle the load, particularly if caching layers are employed. b. --~--~-~--~~~---~--~~ 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: Query regarding callback & hd parameter in OAuthAuthorizeToken
Thank you John --~--~-~--~~~---~--~~ 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: Distinction between Request Token and Access token
Indeed, the draft of Scalable OAuth takes to account the problem of giving access to concrete resources at the Service Provider, as well as other problems I had detected such as token revocation and renewal. Thank you very much to all of you who have tried to help me :-) Jorgito --~--~-~--~~~---~--~~ 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: Java OAuthClient.access
Hi John,
I think in the end, this would make development much easier. Although
it does put the responsibility of error handling on the developer, I
think this is better in the longrun as the magic way of doing it might
not always be how the developer wants to handle it. For example, at
the moment I'm still having issues getting the upload stuff to work,
and I think this change might end up making that a lot easier.
On Jan 31, 1:59 am, John Kristian wrote:
> I propose to extend the Java oauth-core library to better support
> accessing protected resources, as follows. Please let me know if this
> is a bad idea, or there's a better way.
>
> In brief, I propose to add a method to OAuthClient:
>
> /** Send a request and return the response. */
> public OAuthResponseMessage access (OAuthMessage request,
> ParameterStyle style) throws IOException;
>
> Unlike the existing 'invoke' method, it won't try to decide whether
> the response indicates success; it will merely return the response. A
> typical caller would evaluate the response, something like this:
>
> OAuthClient client = ...;
> OAuthAccessor accessor = ...;
> OAuthMessage request = new ...;
> request.addRequiredParameters (accessor);
> OAuthResponseMessage response = client.access (request,
> ParameterStyle.AUTHORIZATION_HEADER);
> switch(response.getHttpResponse().getStatusCode()) {
> case 200: ...
> case 400: ...
>
> I'm a little worried about feature creep: this is a step toward a
> general purpose HTTP client library. But it's a tolerably small step,
> I hope. I don't want to try to reproduce all the features of the
> Apache HTTP client libraries.
--~--~-~--~~~---~--~~
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: Distinction between Request Token and Access token
Hi Krishna and Praveen. Sorry for the delay, but during weekends I don't have Internet connection. Krishna: that's exactly what I mean, granularity in time and granularity in the space of resources. The granularity in time is already implemented in OAuth, but the granularity in resources... maybe it's implicit in some field of some message, but I can't find it in the spec! Praveen: very interesting link. I proceed to read it, maybe it's the answer to my questions :) Greetings, Jorgito --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
