[oauth] Re: Version Preference
Option 3. Cheers k/ |-Original Message- |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf |Of Blaine Cook |Sent: Friday, May 01, 2009 1:25 AM |To: oauth@googlegroups.com |Subject: [oauth] Version Preference | | |We need to build some consensus around the version preference. As I |see it, there are several options: | |1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) |2. 1.0a (with oauth_version=1.0a) |3. 1.1 | |Please indicate your support for one of these options, and try to |refrain from arguing your case here. The other thread remains open for |that purpose. I would especially like to hear from library |implementers here, and others who have not voiced their opinions in |the other threads. | |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] Oauth header integrity
My first cut at an outline draft - attached to my blog http://doubleclix.wordpress.com/2009/04/03/oauth-header-hash/ Naturally leveraged Brian's body hash spec figuratively and literally. There is lot of work to be done from formatting to processing model to examples and running code. Also need to find a way to get a sub-directory in oauth.googlecode.com (I couldn't find a way and that is why I tacked on to my blog. Would appreciate any help) Does this look like something we want to pursue ? And also does it reflect the current thinking ? Cheers have a nice weekend 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] Header Integrity
I will byte ;o) @all, I am thinking of developing a header integrity proposal - a header hash taking lead from Brian's body hash. First, is there anybody attempting this ? I am sure Brian is not. Second, while I think this is inevitable - one form or another, I also do not want to rush in. My thought is to start simple and then add complexity as and when needed. I think we should have a selective header hash or if that turns out to be problematic, sign a list of prescriptive headers if that makes it easier. I will unearth old discussions on this topic and find common ground. Is this a good idea or better left alone ? Cheers k/ |-Original Message- |From: oauth-extensi...@googlegroups.com [mailto:oauth- |extensi...@googlegroups.com] On Behalf Of Brian Eaton |Sent: Thursday, April 02, 2009 2:52 PM |To: oauth-extensi...@googlegroups.com |Subject: [oauth-extensions] Re: last call for comments on body signing | | |I'm familiar with the dangers of content-sniffing, but in practice |they cause problems when serving content, not when receiving content. |I don't know of a single practical attack based on tampering with the |content type sent from the client. When I've asked for examples of |such attacks in the past, they've all boiled down to servers doing |things that are completely insecure no matter how many signatures you |add to the request. =) | |Somebody else can write the HTTP header integrity spec and code. The |same approach used for body hash would be easy to extend. | |On Thu, Apr 2, 2009 at 2:25 PM, Ben Adida b...@adida.net wrote: | | | Hi Brian, | | I like the body hash extension quite a bit, especially the way it | retrofits into the existing oAuth protocol. I also see that you said | no HTTP header integrity, but... I think this extension definitely | needs to verify the content-type, given all of the security issues | related to content-type-sniffing and the fact that it is relatively | easy to find markup that masquerades as one content type but is then | sniffed diferently and causes all sorts of security problems. | | See the soon-to-be-presented Oakland security paper: | http://www.adambarth.com/papers/2009/barth-caballero-song.pdf | | So, I'm definitely not asking for full HTTP header integrity, but | content-type seems to go hand-in-hand with body-signing... any chance | that can be added as, say, oauth_content_type in the Authorization | header + SBS? | | -Ben | | On Mar 23, 11:51 am, Brian Eaton bea...@google.com wrote: | Progress update: | | There is a new draft out, with clarifications based on feedback and | implementation experience: | | |http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/4/spec | | There are pending shindig code reviews for the implementation: | | |http://codereview.appspot.com/27054/showhttp://codereview.appspot.com/28 |042/showhttp://codereview.appspot.com/28075/show | | Cheers, | Brian | | On Wed, Mar 18, 2009 at 9:26 AM, Brian Eaton bea...@google.com |wrote: | Yes, we're pushing this to be an optional, backwards-compatible, |part | of the OAuth specification. I've gotten good feedback from the |OAuth | community so far. | | The backwards compatible piece is pretty important; the idea is |that | clients can opt-in to body signing without breaking existing | compatibility with existing service providers. | | On Tue, Mar 17, 2009 at 10:20 PM, Charlie Jiang cji...@yahoo- |inc.com wrote: | | Hi Brian, | | Sorry to be very late to comment on this. Are we suggesting to |push this | to be part of OAuth spec? If so, have we talked to them? | | -Charlie | | -Original Message- | From: opensocial-and-gadgets-s...@googlegroups.com | [mailto:opensocial-and-gadgets-s...@googlegroups.com] On Behalf Of |Brian | Eaton | Sent: Thursday, March 12, 2009 9:29 AM | To: oauth@googlegroups.com; oauth-extensi...@googlegroups.com; | opensocial-and-gadgets-s...@googlegroups.com | Subject: [opensocial-and-gadgets-spec] last call for comments on |body | signing | | Hi folks - | | I've neglected the body signing specification for a few months and |I'd | like to wrap it up. A fresh draft is here: | | |http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/3/spec.h |tm | l | | Changes: | - language cleaned up to be more precise | - more detailed example | | Things that have not changed: | - no, I'm not going to do anything about HTTP header integrity. | Write | another spec if you want that. | | I'm aiming to have a couple of reference implementations and a |final | spec by next Friday, March 20th. | | Cheers, | Brian | | | | | --~--~-~--~~~---~--~~ 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: FYI: State of the (OAuth) Union
Eran, Excellent write-up. Couple of quick points: a) Instead of another easy-to-read specification document of some kind, might be easier to write an OAuth Primer (similar to what W3C does). The document can have a section on Lessons learned from implementations. Naturally all of these will get folded into the RFC. b) You had mentioned lack of good open source libraries. I agree that it is important to have good libraries. Which libraries do need work ? Is there a list of tasks or some sort of pointers ? If we have a Wiki page and a list of work to be done - even at a very high granular level - then it will make it easier for folks to pitch-in as time permits. c) BTW, moving to IETF is very good. A standard under a well-accepted body like IETF makes it easier for corporations to adopt. In the process, we also get visibility from the security community plus a deliberate-systemic approach for growth. Cheers k/ |-Original Message- |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf |Of Eran Hammer-Lahav |Sent: Monday, March 02, 2009 8:42 AM |To: oauth@googlegroups.com |Cc: oa...@ietf.org |Subject: [oauth] FYI: State of the (OAuth) Union | | |http://www.hueniverse.com/hueniverse/2009/03/state-of-the-oauth- |union.html | |OAuth Core 1.0 was declared as final specification almost a year and a |half ago. The overall reception was incredible with almost overnight |adoption from major web players like Google, Yahoo, and MySpace. We even |got the attention of the major internet standard bodies, approaching us, |some officially, some less so, to bring the work over. It has been a |good year for community-driven specifications with OAuth leading the |charge. | |During the past year, we've also seen a lot of new ideas and new |requirements coming up. Most people are not aware that there are about |15 proposed extensions for OAuth covering a wide range of topics. There |is also a lot of confusion regarding what is going on with the |specification, how should extension be proposed (and made official), |and recent announcements. | |This post will try to answer some of the questions I receive from people |on a daily basis. If you care about OAuth, implemented it or plan to, or |have any dependency on the specification, technology, or community, this |should be a helpful read. If I missed an important question, please let |me know in the comments. | |* What's Up? |* What is the Status of OAuth Core 1.0? |* Is there a New Version Coming? |* What is Being Done to Make the Current Specification Easier to |Read? |* Is OAuth Moving to the IETF? |* Why the IETF? |* Why does the IETF want OAuth? |* Who Made You In Charge (to Bring OAuth to the IETF)? |* Why isn't the Current Specification Good Enough? Why Seek a |Standard? |* OAuth doesn't Address My Use Case, How can I Extend it? |* Any Upcoming OAuth Events? | |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: OAuth FAIL
The agent is a overused term and we still need to differentiate between the service provider and the service aggregator. What about service originator, service provider/cloud provider/service aggregator and service consumer ? Or some version of it. Then we can talk about SO Key or SP key or SC key and other artifacts thereof. Cheers k/ |-Original Message- |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf |Of Eran Hammer-Lahav |Sent: Monday, March 02, 2009 5:46 PM |To: oauth@googlegroups.com |Subject: [oauth] Re: OAuth FAIL | | |I would like to change the entire Service Provider and Consumer terms. |Just |use Server, Client, and User-Agent... | |Yes, Consumer Key is AWEFUL! I think we can change it. The migration |path is |going to be trivial (accept both for a while). | |EHL | | |On 3/2/09 5:37 PM, Brian Eaton bea...@google.com wrote: | | | | Ah, I totally forgot about the whole consumer key nomenclature. | | It would make me incredibly happy if OAuth talked about consumer | name and consumer secret, because crypto geeks and others tend to | think that keys are secrets. The OAuth consumer key is not secret, | thus leading to confusion. | | Given that oauth_consumer_key is baked into the protocol, this might | be a lost cause. | | On Mon, Mar 2, 2009 at 5:28 PM, Manger, James H | james.h.man...@team.telstra.com wrote: | OAuth¹s use of ³Consumer Developer² versus ³Consumer² can be |confusing. | | | | It can sound like the OAuth spec is trying to distinguish: the |software | developer who wrote a web app; from a web site where the web app is | deployed. A software developer can write lots of web apps. A web app |can be | installed on lots of independent web sites. I don¹t think this is the | intention. The desired difference is between a human (³Application |Owner²) | who can complete a registration process, and a computer program | (³Application²) that is configured with keys and secrets. | | | | It might be clearer to avoid the ³Consumer Developer² term perhaps |saying | that a Key and Secret must be obtained for a Consumer from the |Service | Provider. | | | | James Manger | james.h.man...@team.telstra.com | Identity and security team Chief Technology Office Telstra | | | | | | --~--~-~--~~~---~--~~ 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 k/ |-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] Re: Problem accessing OAuthAccessToken
John, Good point and thanks for the details. I think we are talking about the same thing, but possibly in a slightly different context. Let me elaborate my understanding. a) In steps #c and #d of the flow diagram, the oauth_token is optional. So, in cases, where it is not used, the unauthorized authorized requestTokens would be the same b) Yep, the act of Step 2, will change the state of the SP. But that does not necessarily mean that the state would be persisted at the SP side. c) In 6.2.1, the SP can require the oauth_token (the unauthorized requestToken, in this case) be present for step #c. And it can require a callback URL be present. d) In which case, in step #d an oauth_token (the authorized requestToken, in this case) would be sent back - section 6.2.3 e) The spec does not say clearly if the token sent back in 6.2.3 is the same as the one in 6.2.1 f) Couple of scenarios I was looking at have the (possibility of the) OAuth engine separate and loosely coupled with the services. For example OAuth engine in a firewall or a separate OAuth service for a collection of UC services. In all these cases, embedding the state in the token is attractive. Having said that, thanks for this discussion, I doubt now, if one can really afford not to go back to the OAuth engine to check the state. While it might be choreographically possible, it might not be wise from a security perspective. g) In any case, I would like to get the insight on the inclusion of the tokens in 6.2.1 and 6.2.3. If they are the same, why exchange them ? Is it for the optimization at the consumer side ? Were there any other scenarios ? And why call them by two names - authorized and unauthorized tokens - if they are the same ? Thoughts ? Cheers k/ |-Original Message- |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf |Of John Kristian |Sent: Saturday, January 31, 2009 6:56 PM |To: OAuth |Subject: [oauth] Re: Problem accessing OAuthAccessToken | | |We're not communicating clearly, I fear. Let's use the terms from the |OAuth Core 1.0 specification section 6 |http://oauth.net/core/1.0/#anchor9 | |There are two tokens: a request token and an access token. The |service provider chooses the tokens. They may be different. The |service provider may pack data into the tokens, but this isn't |specified by OAuth. | |There are three steps: | |1. The Consumer obtains an unauthorized Request Token. |2. The User authorizes the Request Token. |3. The Consumer exchanges the Request Token for an Access Token. | |Step 2 doesn't produce a new token. It changes state in the service |provider, so the service provider associates authority (permission) |with the request token. | |On Jan 31, 3:07 pm, Krishna Sankar (ksankar) ksan...@cisco.com |wrote: | I thought they *need not* be the same - because a service | provider could conceivably encode some opaque values in the | tokens and those might be different in the unauthorized | authorized requestTokens. I am actually planning on these | two being different. Does the spec specify that these two | tokens should be the same ? | | --~--~-~--~~~---~--~~ 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: Confused about oauth
Joe, What you are looking for is something *loosely* like a cookie. No, OAuth does not have that type of feature. As you might well know, usually this is done via client side cookies or plain login. Most probably, I am missing something - maybe we can explore further if we know more about the specific application requirement. Also guaranteed unique permanent id is not that easy, especially across distributed systems. Having said that OAuth has place holder for domain/application specific parameters where one could possibly embed a permanent identifier. As John mentioned, an OAuth extension specification could be a good idea. Cheers k/ From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Chris Messina Sent: Tuesday, December 23, 2008 12:10 PM To: oauth@googlegroups.com Subject: [oauth] Re: Confused about oauth I can't give you a technical answer for this, but no, OpenID does identity (and claimed identifiers), whereas OAuth substitutes a token and consumer key for username and password. That said, you essentially identify requests by the consumer key, and allow them through if they're signed with the proper access token. The combination of the two more or less (given my rudimentary comprehension of how this all works) gives you a way to identify requests and who they're coming from, but not in the same way that OpenID is intended for verification of long-lived/durable identifiers. Hopefully someone more technical can correct me if I'm wrong. Chris On Mon, Dec 22, 2008 at 6:12 PM, Joe Bowman bowman.jos...@gmail.com wrote: I'm interested in using oauth for a site I'm working on, but I'm a bit confused about one thing. Does the oauth protocol return some sort of permanent identifier for the user I can store locally? That way I can create site specific profile information for the user, and every time that they log in using oauth, I will get something I can compare my database data to, to identify the user if they've already logged on previously? -- Chris Messina Citizen-Participant Open Web Advocate-at-Large Vote in the OpenID Board Election! http://tr.im/vote_oidf 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: [opensocial-and-gadgets-spec] Re: body signing for oauth and opensocial
Sorry, I meant binary in terms of either on or off - not binary signature. Cheers k/ |-Original Message- |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf |Of Blaine Cook |Sent: Thursday, December 11, 2008 7:10 AM |To: oauth@googlegroups.com |Subject: [oauth] Re: [opensocial-and-gadgets-spec] Re: body signing for |oauth and opensocial | | |On Wed, Dec 10, 2008 at 11:30 PM, Krishna Sankar (ksankar) |ksan...@cisco.com wrote: |Why can't we make it binary - just say header-signature- |required | or header-signature-not-required. And if required, sign all the |headers | or a set of well specified headers - no messy selection of which one |to | sign et al. | |Binary signing would be really difficult; the headers that the |consumer sees, and those that the service provider sees are |potentially very different with the interference of proxies, servers, |etc. | |OTOH, I agree that header signature selection is not at all appetising. | |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: [opensocial-and-gadgets-spec] Re: body signing for oauth and opensocial
Brian, Not yet. I need to do due diligence. For now, two questions: a) Header signing? Yes/No. I assume Yes - from your last e-mail. If not we should continue that thread . b) Assuming yes for #1 above, SP selects headers to sign. Yes/No. I assume No and that the spec specifies a (fixed) list of headers to sign. If we agree to the above, we add header signature mechanisms to the spec and the list of specific http headers we want to sign and the mechanics for signing them. If we do not agree to #1 and #2 above, we return to the feature presentation and argue if headers need signatures. Thoughts ? Cheers k/ P.S: Sorry for the paunchiness, am at the Big Nerd Ranch class in Banning Mills - a little far away from civilization (like Starbucks) ;o) Class is excellent, but one gets fried after the class ! |-Original Message- |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf |Of Brian Eaton |Sent: Wednesday, December 10, 2008 5:23 PM |To: opensocial-and-gadgets-s...@googlegroups.com |Cc: Louis Ryan; oauth@googlegroups.com; Scott Seely; Marc Worrell; |john.martin.ha...@gmail.com |Subject: [oauth] Re: [opensocial-and-gadgets-spec] Re: body signing for |oauth and opensocial | | |I think header signing and body signing can be done orthogonally. |Krishna, you mentioned you had solid use cases for this, so perhaps |you should propose a spec? | |On Wed, Dec 10, 2008 at 5:13 PM, Krishna Sankar (ksankar) |ksan...@cisco.com wrote: | Agreed good point. I did think about it implicitly, but didn't |address | explicitly. | | | | We should assume that intermediaries would add headers - but would |neither | add to the values of the set of headers we are interested in nor |delete | headers of interest to us. Is that a fair deterministic assumption ? |If | so, we should specify the headers that should be signed. Again, in a |binary | mode - sign the specified headers or not sign any of them. | | | | Cheers | | k/ | | | | From: opensocial-and-gadgets-s...@googlegroups.com | [mailto:opensocial-and-gadgets-s...@googlegroups.com] On Behalf Of |Kevin | Brown | Sent: Wednesday, December 10, 2008 3:42 PM | To: opensocial-and-gadgets-s...@googlegroups.com | Cc: Louis Ryan; oauth@googlegroups.com; Scott Seely; Marc Worrell; | john.martin.ha...@gmail.com | Subject: [opensocial-and-gadgets-spec] Re: body signing for oauth and | opensocial | | | | On Wed, Dec 10, 2008 at 3:30 PM, Krishna Sankar (ksankar) | ksan...@cisco.com wrote: | | Brian, |Now that we have beaten you to submission ;o), I think it | becomes complex by requiring arbitrary named headers to be signed, |with | choice. Lot of thorny issues - How would an SP convey this ? What | happens when this policy changes ? How would the error be sent back ? |et | al. | |Why can't we make it binary - just say header-signature- |required | or header-signature-not-required. And if required, sign all the |headers | or a set of well specified headers - no messy selection of which one |to | sign et al. | | You can't guarantee that the headers a container sends will be the |only ones | the remote site receives, for the same reason that you can't sign the |final | bytes transmitted and have to instead sign what you actually sent. | | |BTW, we also need to include the additional parameters in the | signature. (I am working on an end-to-end OAuth choreography for | enterprises, for a few specific domains and require couple of | domain-specific attributes to be passed around. So, my guess is that, | the optional parameters would be very popular) | |Agreed on minimal normalization. | |I also want the HMAC-AES as one of the mechanisms, but haven't | worked through the analysis of the bootstrap and the MEPs to make a | definite pitch for that feature. | | Cheers | k/ | | |-Original Message- | |From: opensocial-and-gadgets-s...@googlegroups.com |[mailto:opensocial- | |and-gadgets-s...@googlegroups.com] On Behalf Of Brian Eaton | | |Sent: Wednesday, December 10, 2008 8:23 AM | |To: opensocial-and-gadgets-s...@googlegroups.com | |Cc: Louis Ryan; oauth@googlegroups.com; Scott Seely; Marc Worrell; | |john.martin.ha...@gmail.com | | |Subject: [opensocial-and-gadgets-spec] Re: body signing for oauth and | |opensocial | | | | | | |(Backpedaling on this, given that just about everybody who has chimed | |on this thread except me thinks signing headers is a good idea. =) | | | |OK, how about this for a compromise on the question of signing |headers: | | | |1) Service providers may choose to require that certain headers be | |signed to guarantee their integrity. | |2) If service providers require header signing, consumers will need |to | |send a list of signed headers and their values to the server. | |3) Some normalization of the headers will be required. I'd suggest | |something really minimal (as little interpretation of header values |as | |is possible
