[oauth] Fwd: Call For Participation - Opensocial V2 Specification
FYI. -- Forwarded message -- From: Paul Lindner lind...@inuus.com Date: Fri, Dec 10, 2010 at 9:12 AM Subject: Call For Participation - Opensocial V2 Specification To: opensocial-and-gadgets-s...@googlegroups.com [Please forward to any potential venues you deem appropriate] CALL FOR PARTICIPATION - OPENSOCIAL V2 The OpenSocial Open Standards and Open Source Alignment Advisory Committee would like your help designing the next version of OpenSocial. OpenSocial V2 is a major upgrade from the v1.x series and is tentatively scheduled to be available in mid-2011. * The Goal Our goal is to refresh the Opensocial technology stack so that it becomes an even better way to implement interoperable social experiences on the internet. A lot has changed in the three years since Opensocial was first proposed. The community has made a number of incremental improvements and added some big new features. We've also learned quite a bit about what works and what doesn't. We also realize that other communities have done great work and we would like to align OpenSocial with those other efforts. Areas of exploration include but are not limited to: - Aligning with Activity Streams, OStatus, SWAT0, and OEmbed - Deprecating or wholesale removal of little used features. - Removing ambiguity and tightening up the spec. Overall we're looking to define and get consensus for the framework and themes that will make the V2 specification successful. * Deliverables This group will deliver a document titled The OpenSocial v2 Framework for review by the Opensocial Board at their January 27th, 2010 meeting. It will: - Describes at a high level the changes we want to see in Opensocial. - Decides what's in-scope, out-of-scope and undecided. - Identifies Champions for each of these changes and volunteers that are willing to design and implement them. * The Process Recommendations will be developed in the open via the mailing list opensocial-and-gadgets-s...@googlegroups.com To coordinate and catalog the proposals we will use the wiki doc listed below. http://wiki.opensocial.org/index.php?title=Spec_Changes Each proposal should contain the following information: Scope of change (Large, Medium, Small) Reference to existing standard (if applicable) Champion Name Specification editor names and declarations of time commitment. We will follow the general rule of OpenSocial spec development, five +1 votes and no vetoes from Opensocial Foundation Members. Membership is open to anyone by visiting http://www.opensocial.org/opensocial-foundation/osf-membership-app.html * Key Dates December 16th - Opensocial v2 kickoff at Google in Mountain View, California USA. Please RSVP at http://www.eventbrite.com/event/1103748341/estwbreg Full notes will be taken. Weekly IRC chats starting December 20th #opensocial on freenode.net Schedule to be determined at the Kickoff meeting, the plan is to stagger times to accomodate Europe, Asia, North America January 20th, 2011 - cutoff for all proposals. January 27th, 2011 - present document for OpenSocial Board. Thank You! Paul Lindner Former Opensocial Community Board member VP Apache Shindig Project -- Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner -- 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.
Re: [oauth] GData and multiple accounts
This is a Google-specific request, but my initial reaction would be, no, it's not possible to bypass this screen since it's still up to the user's discretion to pick the account data they want to grant access to. Allowing a third-party to specify the account data that the user is granting access to seems to take away a necessary control from the user. That said, I'm sympathetic to the user experience hassle this adds to authorization flows, so there might be some way to optimize the dance. Chris On Wed, Aug 4, 2010 at 11:13 AM, PanosJee panos...@gmail.com wrote: Hi guys, i am using the Python lib to access Gmail and Contacts. Is it possible to bypass the screen that allows the user to select among multiple google accounts. I already know the account he wants to import so I ld like to display the Grant Access screen after the redirection as some other apps do. Any hints? -- 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 oauth%2bunsubscr...@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.
Re: [oauth] beginners guide to oAuth at http://hueniverse.com/oauth/ is down
I see that too. I've pinged Eran. It's up to him to provide us details about what's wrong with his server... :( Chris On Wed, May 26, 2010 at 6:38 AM, TomH thomas.hod...@gmail.com wrote: Hi, http://hueniverse.com/oauth/ I am seeing Error establishing a database connection Thanks, Tom -- 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 oauth%2bunsubscr...@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.
Re: [oauth] New OAuth java library
Done. Cheers! Chris On Tue, Apr 6, 2010 at 3:32 PM, Pablo Fernandez fernandezpabl...@gmail.comwrote: Hi, I've developed a new OAuth library for java that is intended to work with all APIs. It's called Scribe and has been featured in LinkedIn's developers forums: http://developer.linkedin.com/message/4568 The library is mature, is being used in production and it's the only one known to work out of the box with LinkedIn's implementation of OAuth. I'd like to have it's home page (github.com/fernandezpablo85/scribe) linked to the http://oauth.net/code/ page. It would be also a great idea to link LinkedIn's API to the list of OAuth implementers here: http://wiki.oauth.net/Implementations Thanks a lot! -- 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 oauth%2bunsubscr...@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.
Re: [oauth] Re: Using OAuth as SSO
I'm not an expert in this area per se, but I think what you actually need is something more like SAML combined with OpenID and/or OAuth. The information provided here might be relevant: http://code.google.com/apis/accounts/docs/OpenID.html#oauth Chris On Mon, Mar 29, 2010 at 11:09 AM, Adam apcau...@gmail.com wrote: I'd still like to know if there are any examples of SSO using OAuth to sign into gmail - I have found some examples for use with Twitter, but not Google. On Mar 29, 11:31 am, Adam apcau...@gmail.com wrote: On Mar 26, 4:39 pm, Chris Messina chris.mess...@gmail.com wrote: Why don't you want to do OpenID? The problem is that we are currently using CAS as our SSO, and since we are a large university invested in CAS, we cannot easily switch to OpenID. If we use OpenID, then a user would have to login to our system using CAS, and if they wanted to login to gmail, then they would have to authenticate with OpenID - this would sort of negate single sign-on, since the user would have to login twice. OAuth would allow us to keep a token on our side, and the user would only need to authenticate twice when they allow us access to their account using OAuth. -- 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 oauth%2bunsubscr...@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.
Re: [oauth] Using OAuth as SSO
OAuth can be used as a bastardized mechanism to do SSO, but it's not really recommended. OAuth only provides you with tokens, which could later be revoked, effectively destroying the identity that you're relying on. OpenID is the preferred way to achieve SSO because it provides you with a stable, reusable identifier. Twitter uses OAuth for SSO, but it's really kind of a mis-use of the technology, although in practice it kind of solves the problem. Essentially OpenID provides you with identity; OAuth provides you authorization to do things on behalf of a user. Since you're doing something on behalf of a user, you get a kind of temporary identity to do stuff but it's much more fragile than OpenID. Why don't you want to do OpenID? Chris On Fri, Mar 26, 2010 at 10:21 AM, Adam apcau...@gmail.com wrote: We currently use CAS for SSO. I'd like to have SSO into gmail, but do not want to switch to OpenID. Is it possible to use OAuth to login users into their gmail accounts? Or is OAuth only meant to retrieve user data? I am currently using SignPost to connect to OAuth... if it matters. Thanks. -- 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 oauth%2bunsubscr...@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.
Re: [oauth] Using OAuth as SSO
I do agree with that. But it is important to recognize where each came from, and what problems each respectively sought to address. Narrowing the divide between the two and making it easier to use both together is something I'm absolutely in favor of. Sent from my iPhone 2G On Mar 26, 2010, at 9:19 PM, David Recordon record...@gmail.com wrote: Agreed. There's a bunch of interesting things that could be done to bring OpenID and OAuth closer together. On Fri, Mar 26, 2010 at 7:15 PM, Ashish Jain iti...@gmail.com wrote: This is worth exploring further at the next OpenID Summit (assuming there is interest). RPs that we talk to have overlapping use cases and it's not fair to their developers to have completely independent SDKs (different signing mechanism, on boarding process etc). -Ashish --- Ashish Jain Sr. Product Manager, PayPal Identity Services email: ashish.j...@paypal.com cell: 303-548-4325 skype: itickr --- On Fri, Mar 26, 2010 at 7:16 PM, Robert Winch rwi...@gmail.com wrote: If you haven't seen this post, it may be of interest http://hueniverse.com/2009/04/introducing-sign-in-with-twitter-oauth-style-connect/ On Fri, Mar 26, 2010 at 5:20 PM, Paul Lindner lind...@inuus.com wrote: If a site has an api that returns a stable user identifier then OAuth can work fine as an SSO. I wouldn't go so far as to call it bastardized.. The big difference between OpenID and OAuth is the idiom used. OpenID is designed to not require prior registration for use -- multiple relying parties and providers can interoperate using URLs and attribute exchange. With OAuth you need a consumer key/secret for your site, and the APIs for attribute exchange change from provider to provider. On Fri, Mar 26, 2010 at 1:39 PM, Chris Messina chris.mess...@gmail.com wrote: OAuth can be used as a bastardized mechanism to do SSO, but it's not really recommended. OAuth only provides you with tokens, which could later be revoked, effectively destroying the identity that you're relying on. OpenID is the preferred way to achieve SSO because it provides you with a stable, reusable identifier. Twitter uses OAuth for SSO, but it's really kind of a mis-use of the technology, although in practice it kind of solves the problem. Essentially OpenID provides you with identity; OAuth provides you authorization to do things on behalf of a user. Since you're doing something on behalf of a user, you get a kind of temporary identity to do stuff but it's much more fragile than OpenID. Why don't you want to do OpenID? Chris On Fri, Mar 26, 2010 at 10:21 AM, Adam apcau...@gmail.com wrote: We currently use CAS for SSO. I'd like to have SSO into gmail, but do not want to switch to OpenID. Is it possible to use OAuth to login users into their gmail accounts? Or is OAuth only meant to retrieve user data? I am currently using SignPost to connect to OAuth... if it matters. Thanks. -- 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. -- 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. -- You received this message because you are subscribed to the Google
Re: [oauth] Re: Javascript OAuth Wrap
This comes from Luke Shepard: http://github.com/lshepard/oauth-wrap-demo http://github.com/lshepard/oauth-wrap-demoChris On Mon, Mar 22, 2010 at 9:10 PM, John Kristian jmkrist...@gmail.com wrote: http://wiki.oauth.net/OAuth-WRAP has some links that look relevant, although I haven't followed them. -- 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 oauth%2bunsubscr...@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.
Re: [oauth] Finer-grained access control in OAuth?
Hi Gerald, Your question is a good one — and gets at some of the challenges inherent in user authorization models. Specifically: when a user grants authorization, how do you effectively scope access and communicate that to the user? Should you or the user need to later change the scope of authorization, how do you do so? However, the way that you've described the problem is actually accurate. In fact, OAuth says nothing about how much (or how little) access a user MUST grant on a per instance basis. The amount of access authorized is dependent on the policies of the service provider and the user's relationship with the service provider. Therefore, a single OAuth token could access as little as your full name, say, or as much as all of your account details. OAuth says nothing about the scope of a given authorization instance. So technically, there's nothing to stop OAuth from behaving as you've described. The problem has much more to do with providing a user experience that is 1) comprehensible and 2) not annoying. While many people have said that they would love to have granular access and control over who has access to their data, in practice we find that people tend to click through authorization screens without really reading them. Getting people to take more care in authorizing third party access to their data would be a great thing, but is, for better or worse, outside the scope of OAuth. Chris On Sat, Mar 20, 2010 at 10:58 AM, Gerald jen...@gmail.com wrote: Hi, all I have been following OAuth work for some time. Also I have developed some apps using OAuth. One problem I encountered often is granularity of access. In current spec, after a user accepts the access request from a third-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 oauth%2bunsubscr...@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.
Re: [oauth] Broken DotNetOpenAuth Link
Fixed. Thanks for the report! On Wed, Feb 24, 2010 at 7:29 AM, brad dunbar dunba...@gmail.com wrote: The link at http://oauth.net/code (http://dotnetopenauth.net/includes) is broken. Perhaps it should just point to http://dotnetopenauth.net/ ? -- 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 oauth%2bunsubscr...@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.
Re: [oauth] Affinity between access tokens and consumer identity
You could imagine the use case of a licensing server sitting separate from the service provider that validates whether someone has the proper rights to view certain content. That's one possibility... Sent from my iPhone 2G On Feb 2, 2010, at 9:44 AM, Richard Barnes richard.bar...@gmail.com wrote: Blaine, Could you briefly describe what those cases are? I'm imagining something where you have one box that does the OAuth stuff and a separate one that actually accesses the resources; is that on the right track? --Richard On Tue, Feb 2, 2010 at 6:42 AM, Blaine Cook rom...@gmail.com wrote: On 1 February 2010 19:58, Onmyouji apeze...@gmail.com wrote: It looks like to me that in the spec there is no requirement for some affinity between the Consumer Key/Consumer Secret, and the Access token. Is this something that is considered out of scope? You're right, there's no spec-mandated affinity. However, server-side implementations should only allow requests that are made with an access token and the consumer key that was used to issue the access token. We didn't specify this because there are viable scenarios where you want access key portability. b. -- 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 . -- 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] Best Practice
On Mon, Jan 18, 2010 at 7:31 AM, John Panzer jpan...@google.com wrote: ...How many users actually check urls? How many are equipped to check urls with Unicode characters? Would it be possible to get 99% of the security with an iframe plus a button to pop out to a full window to complete the action? The latter would be chosen by a self selected group of people who actually check urls and are potentially giving up a high value password. I actually really like the way that the iPhone deals with this — it may not be ideal, but providing a real-only URL field seems like a nice compromise, where at least the user has SOME context for who's asking for their password: http://www.flickr.com/photos/factoryjoe/4287945431/ If the user is not going to check the URL or understand what it means, all the errors or warnings in the world aren't going to prevent that edge case that the browser's built-in protection system doesn't know about. Better is to make sure the user has *some* kind of contextual clue — and if they trust the client app anyway, then this is possibly about as good as we'll get with the tech that we currently have. Chris -- Chris Messina Open Web Advocate, Google Personal: http://factoryjoe.com Follow me on 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.
Re: [oauth] Best Practice
Agreed. It's very important the user be given at least two pieces of information: * the URL where they're entering their password * whether the connection is secure (ie using SSL) Since you could spoof this information in your app, it's generally a good idea to hand off to the local browser, where the user can leverage their current active session or any password mgmt tool. Chris Sent from my iPhone 2G On Jan 17, 2010, at 8:12, Paul Osman p...@eval.ca wrote: If the user cannot reliably see who is presenting the authorization- sign in window, they have no idea who they are giving their credentials to. This makes the whole point of delegated authorization moot, so I would consider it absolutely necessary to direct the user to a browser window where the location bar is visible. Cheers, Paul On 2010-01-17, at 10:17 AM, eco_bach wrote: Hi Building a Twitter application using OAuth. I'd like to embed the Twitter OAuth authorization-sign in window WITHIN my application. Is this considered a best practice, or is it always recommended to send the user to a new browser window for the service provider (Twitter in this case) authentication process? -- 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 . -- 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] Redirecting to the new 1.0 spec
+1 On Tue, Nov 24, 2009 at 10:55 AM, David Recordon record...@gmail.comwrote: Do it! On Mon, Nov 23, 2009 at 11:39 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: How do people feel about adding a note at the top of: http://oauth.net/core/1.0 http://oauth.net/core/1.0a Pointing visitors to the OAuth Core 1.0 RFC draft (pending IESG approval): http://tools.ietf.org/html/draft-hammer-oauth The new draft is significantly better and easier to read. We can't switch the content at the two URIs above because they are linked to the IPR agreements. We also shouldn't because those specs represent a community product that should be kept for future documentation and many existing links point there. For those not paying attention, the new draft also contains a few protocol changes and clarifications which may have a small impact in existing libraries. For the list of changes: http://tools.ietf.org/html/draft-hammer-oauth-07#appendix-A Comments? EHL -- 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 oauth%2bunsubscr...@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 oauth%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en. -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net 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.
[oauth] Re: [OAUTH-WG] OAuth WRAP
. Given the positive reception WRAP received at IIW and that capabilities in WRAP are expected to come out of the work in the IETF OAuth WG, there was consensus from the OAuth community to include WRAP as OAuth profiles. -- Dick On 2009-11-10, at 10:06 AM, Paul C. Bryan em...@pbryan.net wrote: Hi Dick: Given that WRAP is so different from OAuth (as I know it), other than the fact that OAuth could be used to negotiate the issuance of a WRAP refresh token, I'm curious why you chose to associate this with OAuth by giving it an OAuth prefix. It seems to me that it would only create confusion in this space. Paul On Tue, 2009-11-10 at 17:52 +, Dick Hardt wrote: At IIW last week, myself, Biran Eaton from Google and Allen Tom from Yahoo! presented what is now called OAuth WRAP The specs and discussion specific to those documents is at: http://groups.google.com/group/oauth-wrap-wg We plan to submit the document as an I-D next week when I-D submission is open again, and for further work to occur in the IETF OAuth WG. -- Dick ___ OAuth mailing list oa...@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list oa...@ietf.org https://www.ietf.org/mailman/listinfo/oauth ]] ___ OAuth mailing list oa...@ietf.org https://www.ietf.org/mailman/listinfo/oauth ]] ___ OAuth mailing list oa...@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net 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 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: Just wanted to quickly say hello
Hello! Which platform? Sent from my iPhone 2G On Nov 4, 2009, at 7:20, Anthony Broad-Crawford anth...@anthonybroadcrawford.com wrote: I write as I am incorporating OAuth into our platform sometime late December or early January. That being said, I (and a few of my colleagues) will probably be more active on the list and simply wanted to say hello. Cheers. Anthony Broad-Crawford www.anthonybroadcrawford.com www.twitter.com/broadcrawford This email is: [ x ] bloggable[ ] 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: A massive thank you to Fangel!
Ok, thanks. I might also point you to Eran's Editor's Cut of the spec: http://oauth.googlecode.com/svn/spec/core/unofficial/1.0ec/drafts/1/spec.html Chris On Sun, Aug 30, 2009 at 9:33 AM, David King da...@1daylater.com wrote: Indeed - tis an invaluable list! -- The work we did together was to create a *VERY* simple OAuth provider and consumer in PHP/MySQL. This was to give me a hands on feel for the spec and also overcome some of the ambiguities that it lays down. Not because the specs are bad - the nature of such a theoretical document leaves many parts up to the choice of the developer. For example, by implementing OAuth I'm having to rethink the way my current login scripts behave and interact with the new tokens - I've decided to do a complete rehaul of these routines which will actually simplify the process, rather cool! Before Fangel came over, my biggest stumbling block was actually *where* should I start coding? As its broken up into parts that all rely on each other, it seemed a bit like trying to figure out where to bite a basketball to start eating it... (what an odd metaphor!) -- Because times are pretty hectic (I'm busy setting up a new company with my brother) I can't commit any time at the moment to contribute to the project. HOWEVER, I do plan on creating a very simple consumer that both explains OAuth and provides sample HTML/Javascript code for people to dissect - this is so that contributors to our project have a good starting point to develop their code, I'll be *very* happy to give this back to the community! Cheers for responding :) -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net 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: A massive thank you to Fangel!
;) that's great! Glad to hear this list was of value to you! I wonder if any of that work could be shared with the wider group, to help us improve our documentation — or point to areas where there is improvement needed? Chris On Fri, Aug 28, 2009 at 6:42 PM, David King da...@1daylater.com wrote: A few months back I asked on these forums to find a UK developer and had a great response from Morten Fangel: http://groups.google.com/group/oauth/browse_thread/thread/76b630b20889118d Realised I hadn't updated the thread to say thank you - Fangel flew over from Denmark last month and helped me understand OAuth, we created a simple setup that demonstrated all the features of the specification. Next week I'm revisiting the code and will be integrating it into our API! Massive thanks guys! Great forum, excellent concept, but most of all, lovely Danish coders! -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net 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: Problem with URL format in Twitter 'favorite status' option.
Hi Mariusz, this group is really about OAuth and nit any specific use of it. You're unlikely to get an answer here, so I'd recommend visiting the Twitter Development Talk mailing list. Chris On Thursday, August 6, 2009, Mariusz mariusz...@gmail.com wrote: Hi! I know that it is mailing group of OAuth. :) However a lot of people of the group create a Twitter or Facebook client. So I hope that somebody will be able help me. :) I make small Twitter client in Java. Currently I make options: 'farourite status' and 'unfavourite status' and I have a strange problem. I always use format of url like this: (for 'follow user'): http://twitter.com/friendships/create.json?id= It works well in almost all cases. However it doesn't work in 'favourite status'. If I try: http://twitter.com/favorites/create.json?id=11 I will get error. But if I try: http://twitter.com/favorites/create/11.json everything works well. Could somebody tell me why I can't use first way of the URL? I would like to use link with parameters after '?' character. Why doesn't it work in 'favorite status' and 'unfavorite status'? I sorry for the offtopic. :) Mariusz -- Chris Messina Open Web Advocate Personal site: http://factoryjoe.com Twitter: http://twitter.com/chrismessina Diso Project: http://diso-project.org OpenID Foundation: http://openid.net 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: Design Rationale and FAQ
Hey Paul, It'd be great to collect these learnings and design rationales in an FAQ... It could/should live here: https://wiki.oauth.net/FAQ Alternatively, each question that your colleague asked could be entered into our Satisfaction forum and then answered, so that a discussion could emerge on each topic: http://getsatisfaction.com/oauth If you take that approach, I could simply take a Satisfaction widget and put it on an oauth.net FAQ page (my preference). Let me know. Chris On Thu, Jul 23, 2009 at 11:14 AM, Paul Lindner lind...@inuus.com wrote: Hi, Recently a colleague who is starting an implementation of OAuth asked me many questions about the design rationale of many of the steps involved in the OAuth protocol. I found a number of mailing list threads discussing the importance of each step and why it is present. If there's interest I can consolidate them into an FAQ. There was one suggestion that my colleague presented that I did not find an answer for: * Can one skip the access token exchange step and instead have the access token and access secret communicated to the consumer via the callback URL? (assuming OAuth 1.0a with signed callback URLs) Thanks Paul -- Chris Messina Open Web Advocate Personal site: http://factoryjoe.com Twitter: http://twitter.com/chrismessina Diso Project: http://diso-project.org OpenID Foundation: http://openid.net 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] WordPress 2.8 – XML-RPC and AtomPub Change s
Thought it was interesting to note that in WordPress 2.8 [1]: - Authentication is filterable now, allowing for alternative authentication methods like OAuth ( ticket#8941http://core.trac.wordpress.org/ticket/8941 and #8938 http://core.trac.wordpress.org/ticket/8938 ) Thanks to Will Norris for getting these changes in to core! Chris [1] http://josephscott.org/archives/2009/06/wordpress-2-8-xml-rpc-and-atompub-changes/ -- Chris Messina Open Web Advocate Personal site: http://factoryjoe.com Twitter: http://twitter.com/chrismessina Diso Project: http://diso-project.org OpenID Foundation: http://openid.net 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 -~--~~~~--~~--~--~---
Re: FW: [oauth] WG kickoff
What if you used [OAUTH-WG]? Seems like that would be a bit more obvious/scannable? Chris On Fri, May 29, 2009 at 9:01 PM, Peter Saint-Andre stpe...@stpeter.imwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/29/09 6:13 PM, Eran Hammer-Lahav wrote: We're starting... Please join us if you haven't done so yet. oa...@ietf.org BTW, a nit: I noticed that the subject lines for both oa...@ietf.org and oauth@googlegroups.com list are prefaced with the string [oauth]. To prevent confusion, I have changed the ietf.org list so that the string is [OAUTH] (in all caps), which is all that Mailman lets you do. It's not much, but it's something. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkogr5IACgkQNL8k5A2w/vyG9QCg1xW7D7xCpUXFZtzlzaKHZAEy fgYAoL2fkmLrV2621aDjCfJsc8b3psdQ =AghQ -END PGP SIGNATURE- -- Chris Messina Open Web Advocate Website: http://factoryjoe.com Twitter: http://twitter.com/chrismessina Facebook: http://facebook.com/chrismessina Diso Project: http://diso-project.org OpenID Foundation: http://openid.net 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: OAuth Discovery 1.0 status
The work is now being done on XRD. The latest drafts are here: http://www.hueniverse.com/hueniverse/2009/03/sunday-morning-ids.html Chris On Sat, May 9, 2009 at 4:56 PM, Andrew Arnott andrewarn...@gmail.comwrote: I see that the current http://oauth.net/discovery spec is marked as obsolete yet with no successor DRAFT. It was scheduled for a new draft in March but I don't see any update. I know many in the community are busy with the security problem, but can we get an idea of where the draft is at, or an updated timetable for its availability? Thanks. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire -- 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] Re: OAuth won an award at the European Identity Conference!
Done. http://blog.oauth.net/2009/05/11/oauth-wins-award-at-european-identity-conference/ On Sun, May 10, 2009 at 10:07 PM, John Panzer jpan...@acm.org wrote: Wow, this is great. Would be good to have some of this info linked to from oauth.net too :). Thanks Eve! Eve Maler wrote: (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 eve.ma...@sun.com 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 -- 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] Re: OAuth dissemination at bettersoftware conference in Italy
Great! Thanks for the update Simone! It would be great if we could assemble non-English resources on the wiki! Would you mind adding your slides to this page? https://oauth.pbworks.com/Presentations Thanks! Chris On Thu, May 7, 2009 at 1:06 PM, Simone Tripodi simone.trip...@gmail.comwrote: Hi all OAuth folks!!! Just to notify you that yesterday my colleague Lorenzo Cassulo and I participated in a conference [1] in Florence (Italy), to speak about digital identity and OpenID. In the afternoon, we did a workshop about the OpenStack, focusing the attention on OAuth and PortableContacts, and showing demos related to an hybrid OAuth consumer-provider[2]. We also presented a nice application to combine OpenID with Jabber/XMPP[3]. Being honest, the audience was very good and people enjoyed a lot OAuth protocol and relative applications :) Moreover, it was very nice also meeting Luca Mearelli (he participates in this mailing list too) who helped us in replying questions about OAuth, so have to say a big thanks to him :) Slides will be available online soon on the conference website and/or slideshare, for who is interested I'll send the links; unfortunately, they are written in Italian language, since the audience was totally Italian :P You can also read what happened following my twitter page on [4]. Best regards Simone Tripodi [1] http://www.bettersoftware.it/ [2] http://oauth.asemantics.com/hybrid/ [3] http://myid.asemantics.com/ [4] http://twitter.com/simonetripodi -- http://www.google.com/profiles/simone.tripodi -- 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] Re: Twitter Broke OAuth's Account?
Yeah, they've taken that account over and given it back a few times on and off. I don't know that we'd use it much, and I prefer Twitter to be support OAuth anyway, so I'll consider it 'contributed' to the cause. :) Chris On Wed, May 6, 2009 at 4:59 PM, Tane Piper t...@digitalspaghetti.me.ukwrote: Just checked in Tweetdeck and @Oauth still works, it's just the URL that is b0rked. Tane Piper http://digitalspaghetti.me.uk - Blog http://learningandroid.org - Learning Android email/gtalk: t...@digitalspaghetti.me.uk mobile: +447815 101802 twitter: http://twitter.com/tanepiper This email is: [ ] blogable [ x ] ask first [ ] private Sent from Edinburgh, City of Edinburgh, United Kingdom On Wed, May 6, 2009 at 3:56 PM, Tane Piper t...@digitalspaghetti.me.uk wrote: Hey, Just in passing I was on the site and I wanted to make sure I was following the OAuth twitter when I saw the link on the Google Code site. But it looks like Twitter, rather than check that OAuth had an account, have taken the URL for themselves for their own service. Now going to http://twitter.com/oauth takes you to an Applications Using Twitter page instead of the twitter stream! Might want to take that up with them. -- 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] Re: OAuth won an award at the European Identity Conference!
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 eve.ma...@sun.com 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 Eve Maler eve.maler @ sun.com Emerging Technologies Directorcell +1 425 345 6756 Sun Microsystems Identity Softwarewww.xmlgrrl.com/blog -- 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] Re: CANCELLED: San Francisco meetup this Tuesday 5pm
:( Seems like 5 people would be a good-sized group to actually get some real work done. Of course it's up to you and then folks who had signed up to attend, but I wouldn't be discouraged by what might appear to be a relatively small sized number of attendees. Chris On Mon, Apr 27, 2009 at 2:04 PM, Leah Culver leah.cul...@gmail.com wrote: Since less than 5 people have responded, I'm cancelling this meeting. Sorry about the short notice, Leah On Fri, Apr 24, 2009 at 2:42 PM, Leah Culver leah.cul...@gmail.comwrote: Hi all, My eyes hurt from trying to read long email threads. There's quite a few good ideas for helping protect against the current security issue and it will be helpful to get together to discuss. Here's the details: OAuth Meetup Tuesday, Apr 28th at 5pm Six Apart 548 4th Street I'll try to get the conference call stuff working too - more about this later. Sorry for the short notice! I'll try to summarize the meeting and get the notes back in the mailing list or wiki. Leah -- 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] Re: User Groups as Principals and OAuth
On Fri, Apr 24, 2009 at 9:53 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I am studying OAuth to be able to suggest and champion it to OpenSim community. Welcome Tommi! Would be great if you could advocate for OAuth in the OpenSim community! I am looking for a way to combine user identities to user groups and using groups as a principals in access lists of resources. In other words the normal user group pattern in distributed identity provider context. One of the requirements is that the use groups should be stored to identity providers storage and that the group should be able to have user identities from different identity providers as members. The resource provider should be able to somehow acquire information whether user is member of any of the groups in the resource access list if direct access rights of the user are not enough to access the resource. This certainly seems feasible with OAuth, but to my knowledge, few people have done this yet. Another way to do it would simply be to authorize multiple parties to get the same access token, or to have a list of access tokens assigned to a certain group that all have the same level of priveleges. As for identity, that's really where OpenID and OAuth can become a compelling solution set. Is this already somehow possible with OAuth or on the OAuth roadmap. Are there alternative or additional standards to accomplish this? If not, is this a good feature candidate or could these requirements be solved with different design pattern entirely? Well, we don't really have a roadmap, except moving OAuth to the IETF, but I would encourage you to look at Eve Maler's work called ProtectServe: 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/ http://www.xmlgrrl.com/blog/archives/2009/04/05/relationship-authorization-make-up-your-mind/ Chris -- Chris Messina Citizen-Participant 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] Re: San Francisco meetup this Tuesday 5pm
I'd like to point out that anyone can organize one of these events wherever they are — this need not happen in the Bay Area exclusively! Moreover, I encourage folks to get together and talk through this threat, how to exploit it and then develop solutions or fixes to what you came up with, face to face. These meetings can be as small as two people or as large as 20. It's up to you, so long as you're able to surface your learnings to this list, where we can all review and consider different approaches and ideas. OAuth is certainly not a west-coast only technology — and I'd love to see more folks getting together *wherever they are* and proposing solutions here, than focusing solely on what comes out of the Bay Area (speaking as a Bay Area resident). Chris On Fri, Apr 24, 2009 at 10:55 PM, Luca Mearelli luca.meare...@gmail.comwrote: On Fri, Apr 24, 2009 at 11:42 PM, Leah Culver leah.cul...@gmail.com wrote: OAuth Meetup Tuesday, Apr 28th at 5pm I'd have liked to participate (via conf call) but it's 2AM here in Italy :-) so I'll try to contribute via the ML, thanks for organizing it Luca -- Chris Messina Citizen-Participant 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] Re: Can OAuth be used to login to a consumer website?
On Wed, Apr 22, 2009 at 10:48 PM, Luca Mearelli luca.meare...@gmail.comwrote: On Thu, Apr 23, 2009 at 7:37 AM, Chris Messina chris.mess...@gmail.com wrote: To add to this perspective, OpenID is an assertion or identity protocol whereas OAuth is designed as an access or authorization protocol. ... That said, OAuth for Twitter authentication is okay, if you only ever want to authenticate Twitter users. ... Yes, we could say that an authorization delegation protocol might be used to identify a user by exchanging authorization for the access to a user-identifying end point (which is more or less what OAuth for Twitter authentication). I'm still thinking if this could or could not be extended to become a federated identity system (not that we need it, there's already OpenID for that!) The problem with OAuth for identity is discovery -- which OpenID, through its use of http:// URLs ( XRDS/YADIS) solves. It's this kind of ad-hoc discovery that makes OpenID better for identity. Chris Luca Mearelli -- Chris Messina Citizen-Participant 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] Re: Can OAuth be used to login to a consumer website?
?.. I am sorry if I haven't put the subject correct. But let me try to explain what I am trying to achieve. I will explain this using the example of www.stocktwits.com So as we know that one can login towww.stocktwits.comusingtwitter username and password, and the advantage that stocktwits have by making a user to sign in using the twitter username and password is 1) Everytime a user enters his twitter username and password in www.stocktwits.com, stocktwits can access the users protected resources from twitter. 2) stocktwits can create a profile for that user within the stocktwits for that user using his twitter username, like letting the user creates his portfolio. First Question: Iswww.stocktwits.comisgoodcandidate for implementing OAuth as a consumer and twitter as a service provider? Yes definitely. If the answer to first question is yes, Second Question: If stocktwits implement OAuth then isn't it every time a user has to go to stocktwits, and stocktwits have to ask the user to sign in with twitter and it will take the user to twitter page where user has to enter his username and password, and then user has to say yes to allow access to stocktwits to access his resources. Isn't this complicates thing. The user doesn't need to go to Twitter every time. All you need to do is store the OAuth token (the access token) for the user. You can then use this token over and over again to get new updates for the user. If I read it correct isn't it the access token is for single use and valid for one/two hour (one place I read one hour and in another place two hour) Third Question: How will stocktwits in OAuth case will allow user to create a portfolio, because in this case stocktwits will no longer have a username to save the portfolio against. You can fetch all the info for the user (including their username) with their OAuth token. If the OAuth token remains constant and it is not for single use and yes this can be done Hope that helps! Leah -- Chris Messina Citizen-Participant 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] Re: OAuth for installed apps
Dropbox handles this nicely: http://www.flickr.com/photos/factoryjoe/3446205237/ Chris On Wed, Apr 15, 2009 at 11:05 PM, John Kristian jmkrist...@gmail.comwrote: To support invalidating credentials (e.g. in case of theft), a service provider should enable a user to identify them. A user faced with a list of unintelligible keys can't decide which one to invalidate. They need to be labeled 'Picasa on my laptop' or 'Picasa at the office' or something meaningful to the user. On Apr 12, 10:57 pm, John Kristian jmkrist...@gmail.com wrote: The service provider would enable a user to revoke her access tokens, e.g. in case they're stolen. -- Chris Messina Citizen-Participant Open Web Advocate factoryjoe.com // diso-project.org // 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: OAuth for installed apps
Not that I have a solution, but I just wanted to point out that your criticism of OAuth basically holds for just about all forms of client-side token solutions in some form or another. Folks like Adobe and Microsoft have invested a lot in DRM to try to solve this problem, but if there's motivation, nothing is really 100% secure — or 100% scalable. The question is whether OAuth makes things better — and I think, generally it does. For a different take on your point, at least in the desktop case, your credentials can't be sold unless you sell the containing computer (see Twollow, for sale on Sitepoint for $1000, including its database with Twitter credentials: http://tr.im/twollow). Lastly, for an example of someone who's doing something LIKE what you're talking about... check out Multiplex: http://multiplexapp.com/ From what I understand, every download is shipped with a unique key that can be upgraded for access to the full version of the app... In that way, the download itself has a new consumer key embedded in it. I don't know how this scales across multiple machines or reinstallations, but at least someone is doing it... it's from the folks at Indy Labs: http://labs.indyhall.org/ Chris On Sun, Apr 12, 2009 at 10:57 PM, John Kristian jmkrist...@gmail.comwrote: I don't see how OAuth was designed for this. OAuth assumes that the consumer can keep a secret. If the consumer can't keep a secret, then the service provider can't really authenticate the consumer, and should inform the user of this fact. The user must decide whether to trust the consumer without help from the service provider. Why not just assume that the consumer secret won't be secret? All copies of the consumer would use the same consumer key and secret (baked into the software). Seems like this would fit better into a service provider's system for identifying consumers and users. Security would revolve around the access token and token secret. Each user/consumer pair would have its own access token and token secret. The service provider would enable a user to revoke her access tokens, e.g. in case they're stolen. Users sharing a computer complicates things. Can other users of the computer access my credentials (and abuse them)? As a rule, I wouldn't like other users to be able to revoke my access: they might abuse the privilege. -- Chris Messina Citizen-Participant Open Web Advocate factoryjoe.com // diso-project.org // 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] 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 eve.ma...@sun.com 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 Eve Maler eve.maler @ sun.com Emerging Technologies Directorcell +1 425 345 6756 Sun Microsystems Identity Softwarewww.xmlgrrl.com/blog -- Chris Messina Citizen-Participant Open Web Advocate factoryjoe.com // diso-project.org // 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: Security through obscurity?
Both of you are right. Technically there's no irrefutable way to prevent leaking tokens in desktop apps, so forcing pre-registration is simply a way to get developers to agree not to casually release what qualifies as confidential information. If you do leak said information (i.e. By embedding it in your desktop app) you agree to hold harmless the SP that provided you the token if/when they shut off your key. The two solutions are complements. Whether the legal solution fully recognizes the limitations of technical solution is another story. Chris On 3/25/09, Eran Hammer-Lahav e...@hueniverse.com wrote: That's simply not true. When you manually register an application you agree to legal terms with how you may or may not use the user's data you are accessing and other legal requirements. Without this agreement, users could sue the service provider for bad acts by the application. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Martin Atkins Sent: Wednesday, March 25, 2009 12:28 PM To: oauth@googlegroups.com Subject: [oauth] Re: Security through obscurity? Eran Hammer-Lahav wrote: But it does make the lawyers happy. Maybe the lawyers ought to listen to the technical folks telling them that requiring pre-registration of desktop apps achieves nothing whatsoever. It can't be healthy to have lawyers who believe they have an effective mechanism that is in fact completely ineffective. -- Chris Messina Citizen-Participant Open Web Advocate factoryjoe.com // diso-project.org // 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] Fwd: [Social] [Fwd: [Standards] UPDATED: XEP-0235 (OAuth Over XMPP)]
FYI. -- Forwarded message -- From: Peter Saint-Andre stpe...@stpeter.im Date: Tue, 24 Mar 2009 17:13:02 -0700 Subject: [Social] [Fwd: [Standards] UPDATED: XEP-0235 (OAuth Over XMPP)] To: XMPP and Social Networking, Two Great Tastes That Taste Great Together! soc...@xmpp.org FYI. My apologies about the namespace change, but this means we won't need to change it again when the spec advances to Draft. Peter Original Message Subject: [Standards] UPDATED: XEP-0235 (OAuth Over XMPP) Date: Tue, 24 Mar 2009 19:10:22 -0500 From: XMPP Extensions Editor edi...@xmpp.org Reply-To: XMPP Standards standa...@xmpp.org To: standa...@xmpp.org Version 0.7 of XEP-0235 (OAuth Over XMPP) has been released. Abstract: This specification defines an XMPP extension for delegating access to protected resources over XMPP, using the OAuth protocol. In the language of OAuth, a User can authorize a Consumer to access a Protected Resource that is hosted by a Service Provider; this authorization is encapsulated in a token that the User requests from the Service Provider, that the User shares with the Consumer, and that the Consumer then presents to the Service Provider in an access request. This specification assumes that OAuth tokens will be acquired via HTTP as defined in the core OAuth specification, then presented over XMPP to a Service Provider. The Protected Resources accessible over XMPP might include groupchat rooms, data feeds hosted at publish-subscribe nodes, media relays, communication gateways, and other items of interest. Changelog: Changed protocol namespace from urn:xmpp:tmp:oauth to urn:xmpp:oauth:0 to conform to XMPP Registrar policies; clarified protocol flow and error handling; corrected examples. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0235.xml?%40diffMode=u%40diffWrap=sr1=2146r2=2920u=3ignore=k= URL: http://www.xmpp.org/extensions/xep-0235.html -- Peter Saint-Andre https://stpeter.im/ -- Chris Messina Citizen-Participant Open Web Advocate factoryjoe.com // diso-project.org // 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: Security through obscurity?
I think that it ultimately depends on your security model and needs. If the benefit of hacking your consumer key is minor, then it's probably not that big a deal if it leaks; if you change your consumer key for every major or minor release, you'll at least be able to track usage and upgrade/downgrade permissions on a rolling basis That is, say you release v1.2 of your app with a new consumer key, you could deprecate v1.1's consumer to be used only for read operations — meaning that the user needs to reauthorize the app to gain full write functionality. This seems reasonable to me, and with work, could be made to be a fairly routine behavior. There's much made of security and making software watertight, but I find that most successful systems tend to be more lenient and accommodating and provide a mix of security with ways to recover when things go wrong. The solution above doesn't prevent all manner of attacks from happening, but at some point, you have to just take that risk and develop ways to mitigate against them. Maybe Allen can speak to how Flickr deals with this with both their Flickr Uploadr and the iPhoto '09 integration? Surely they have consumer keys? Chris On Mon, Mar 23, 2009 at 4:19 AM, Nial nia...@gmail.com wrote: It seems like the best way to move forward would be to have my widget contact my server and check for a change in consumer key/secret. Of course, it'd be easy for anyone to visit that address for the latest details, but it'd mean less hassle for the end-user. On Mar 23, 1:42 am, Allen Tom a...@yahoo-inc.com wrote: So how does this 3rd party server authenticate your widget? What's to stop someone from reverse engineering the protocol and requesting your CK/Secret? We believe that it is impossible to safeguard any secrets embedded in downloadable client applications. Someone with a debugger and some patience will be able to extract the secrets very quickly. Likewise, any secret protocol between a downloadable client and a server can also be easily reverse engineered. Therefore, it's impossible to securely identify a client application, and a downloadable client application's consumer key (even when signed with its consumer secret) is about as meaningful as your browser's HTTP User-Agent string. Unlike downloadable client applications, server based apps are able to safeguard their consumer secret, so it is possible to authenticate server based applications. Allen Nial wrote: This opens the question of whether or not to store my consumer key/ secret within the widgets JS files or request them from a third-party server as and when the widget is initialized. If I were to do the former (as I am currently), I'd have to put out a new version of my widget if my old consumer key/secret were compromised. Which I suppose begs the question: how often do such things occur? -- Chris Messina Citizen-Participant Open Web Advocate factoryjoe.com // diso-project.org // 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 -~--~~~~--~~--~--~---
Fwd: [oauth] OAuth Charter Finalized
FYI. -- Forwarded message -- From: Hannes Tschofenig hannes.tschofe...@gmx.net Date: Sun, 1 Mar 2009 15:05:38 +0200 Subject: [oauth] OAuth Charter Finalized To: Alexey Melnikov alexey.melni...@isode.com, Lisa Dusseault lisa.dussea...@messagingarchitects.com, chris.new...@sun.com, Blaine Cook rom...@gmail.com Cc: oa...@ietf.org Hi Lisa, Alexey, Chris, We have concluded our OAuth charter discussion on the mailing list. The charter text can be found below. Ciao Hannes Blaine --- Open Authentication Protocol (oauth) Last Modified: 2009-03-1 Chair(s): TBD Applications Area Director(s): Chris Newman chris.new...@sun.com Lisa Dusseault l...@osafoundation.org Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources on their behalf. * A mechanism for signing HTTP requests with the token-secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard, based upon draft-hammer-oauth-00.txt, that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (draft-hammer-oauth-00.txt) is used and the available extension points are going to be utilized. The WG will profile OAuth 1.0 in a way that produces a specification that is a backwards compatible profile, i.e. any OAuth 1.0 and the specification produced by this group must support a basic set of features to guarantee interoperability. Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. The Working Group is not tasked with defining a generally applicable HTTP Authentication mechanism (i.e., browser-based 2-leg scenerio), and should consider this work out of scope in its discussions. However, if the deliverables are able to be factored in such a way that this is a byproduct, or such a scenario could be addressed by additional future work, the Working Group may choose to do so. After delivering OAuth, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/sp ec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora-farrell-oauth-accesstoken-creds-00. Goals and Milestones: Apr 2009Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009Start of discussion about OAuth extensions the group should work on Oct 2009Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard Nov 2009Prepare milestone update to start new work within the scope of the charter ___ oauth mailing list oa...@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Chris Messina Citizen-Participant Open Web Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable
[oauth] Re: OAuth-like user experience examples
On Sat, Feb 21, 2009 at 6:55 AM, Christian Scholz / Tao Takashi (SL) tao.taka...@googlemail.com wrote: I guess you wanted to link to http://wiki.oauth.net/iPhoto-to-Flickr Whoops, thanks! Would be happy to have a discussion about these current examples, especially in light of some of the recent feedback from Twitter devs [1][2]. So I am wondering in the iPhone case how I can be sure that I am really at yahoo and not somewhere else. I don't see any URL, whether it's SSL or not etc. and even if I would this application could of course fake this as well (which I guess is also the point in [1]). So I agree with [1] that a better way would be something inside the OS to provide that but that this of course also might not happen (or at least soon). Exactly. Changing the OS is a long way off if people want to use these technologies today. As far as the security issues, this is a problem that was discussed recently on the OpenID User Experience list: First message: http://openid.net/pipermail/user-experience/2009-February/000298.html Follow the thread: http://openid.net/pipermail/user-experience/2009-February/thread.html I can't say that we came to a satisfying conclusion. However, one option could be to do the authentication bit in the app, and if the user is concerned about using the built-in browser, offer a link to sign in via the browser. Of course, if it's a nefarious app, they probably will just not include that link, and without UI consistency where people know to look for such a thing, that may be a moot option. Therein lies the argument *against* popping the authentication to the browser: if you're using a nefarious app and have launched it, you're probably hosed already. It's probably just a matter of time before some Jailbroken iPhone app for Facebook proves this point, so we're at a cross-roads between user education and usability. I also see this more as a problem for e.g. the iPhone where you usually need to close the application in order to jump to safari. This is not such a problem on the desktop and (as you demonstrate) has been done for quite a while with flickr. Pownce actually did this, and I don't think that the experience was all that bad: https://wiki.oauth.net/OAuth-for-Pownce-on-iPhone With using custom protocol handlers, you can make the experience quite smooth actually. Confining the user to the task at hand is a bit harder, but it's not impossible to handle the case where the user never completes authentication. I also agree with [2] that authenticating for multiple services might make this whole process a bit annoying. We might also face this issue in the proposed MMOX IETF working group[3] if we go with OAuth and in order to connect to a world you might first need to authorize various services (profile, inventory, contacts, IM, ...). Yeah, this is why I advocate for strong identity, and an identity hub that essentially talks to your federated services on your behalf, but is your single point of authorizing third party apps to interact with your stuff. I hope these visual examples help to demonstrate current practices in the wild. I know that this kind of thing freaks us out: http://www.flickr.com/photos/factoryjoe/3260710115/ ...but it's clear that that's not the case for all developers. 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] OAuth-like user experience examples
I uploaded two sets of screenshots today demonstrating an OAuth-like flow on the desktop and on the iPhone: iPhone: Flickit to Flickr http://wiki.oauth.net/Flickit-to-Flickr Desktop: iPhoto to Flickr http://wiki.oauth.net/Flickit-to-Flickr Would be happy to have a discussion about these current examples, especially in light of some of the recent feedback from Twitter devs [1][2]. Chris [1] http://blog.atebits.com/2009/02/fixing-oauth/ [2] https://twitter.pbwiki.com/oauth-desktop-discussion -- 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] OpenID Guides
I just discovered this site and thought that it was something that we really should continue doing for OpenID (and OAuth): http://guides.rubyonrails.org/ After reading Joseph's blog post yesterday: http://josephsmarr.com/2009/02/17/implementing-oauth-is-still-too-hard-but-it-doesnt-have-to-be/ It's clear that we must make these technologies easier to implement, and we can start by making more tools and recipes available. As you're doing your own implementation, please share feedback and your own approaches and take notes along the way where things didn't make sense or where the specs weren't clear. It would be great to get this feedback in one place, and then write documentation to help others avoid similar pitfalls. Feel free to use the respective wikis to documents these issues. Thanks! 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: Distinction between Request Token and Access token
On Mon, Feb 2, 2009 at 9:20 AM, Hans Granqvist h...@granqvist.com 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: Authentication API protected with OAuth
The PIN could actually be delivered out of band at the time of authorization (via SMS, for example). I agree that more shared secrets doesn't necessarily help things, but it's like FriendFeed's Remote Key... I'm not a huge fan of it since it puts the burden on the user to remember yet another SS, but insomuch as a PIN could enable a smoother desktop experience, as you've described, it might be worth prototyping at least. Chris On 1/29/09, George Fletcher gffle...@aol.com wrote: Yes, using a PIN instead of a password would work as well. The general principle is that the user is using a remembered shared secret to sign the request to prove they know it. The OAuth signature mechanism provides a convenient way to do the proof. One interesting question about your PIN idea is whether a PIN should be associated with a Consumer via some other, out-of-band provisioning process (i.e. the PIN is specific to the Consumer token). Or whether a PIN should be associated with a set of generic authorization capabilities. This is more useful if a user has only a few identities and a central way to manage authorization. In the current model of each SP also being the IdP for it's service, using a PIN model just increases the number of shared secrets the user has to remember. However, it does provide a way to authorize limited capabilities that passwords don't. As for software asking for passwords, I believe this has a relatively narrow scope. For instance the AOL desktop client asking for the AOL password. I agree that we should move away from the current model where Facebook asks for the AOL password when finding friends. Thanks, George Chris Messina wrote: Ah ha. I get it. That makes sense -- though it does seem like the goal should be to move away from asking for usernames and passwords. This, however, speaks to my concept of an account pin, where you could authorize desktop apps with an easy-to-remember pin that doesn't give you full account access, but only allows you to validate that you own the account. So you would have a full access password (seldom used) and an identification PIN -- almost like a security question (we know how well those work). So instead of a user inputting their username and password, they would input their username and PIN, and the PIN would be used to sign the request, proving to the SP that it's the right user -- and then the SP would provide the access token. Is that a similar but equally effective approach? Chris On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher gffle...@aol.com mailto:gffle...@aol.com wrote: Thanks for this history Chris. I remember it still being API authentication in the first drafts of the OAuth IPR document; because it was one of my comments on the doc:) Here is an example usage. Again, this is more about leveraging the OAuth signature mechanism than trying to represent the whole OAuth flow. Currently at AOL we have a clientLogin API that allows a client (think destop app or mobile device) to authenticate a user and then access services at AOL. Basically, the authentication credentials are exchanged for a token that is used subsequently to access the APIs. The user's credentials are only passed to the AOL authentication service, over SSL, for validation. With the method suggested, the same validation could take place but the password would not be present in the request. Instead it would be used to sign the request. The request is only valid if the receiving authentication system can generate the signature using the password for that user. The successful response of such a request would be the API access token currently used. Another possibility (the example from the initial discussion) is using this mechanism with TLS in order to return to the client a SAML Holder-of-Key Assertion. This is the same concept of exchanging one set of credentials for another credential (in this case a SAML Assertion). I realize that there are security issues with allowing a client or API based authentication mechanism, but there are certain cases where it provides a better user experience and the user is comfortable trusting the application/device. Thanks, George Chris Messina wrote: Hmm. Historically the separation came from the way the communities grew up actually. There were thoughts initially to make OAuth and extension of OpenID but because I was wary of the politics within the OpenID community, I pushed for keeping OAuth completely separate and avoid having to do anything with authentication (so that it could be used with OpenID, but would have its own adoption curve). The typo on the homepage was probably my fault, since, being the identity n00b, I didn't realize the difference
[oauth] Re: Authentication API protected with OAuth
Hmm. Historically the separation came from the way the communities grew up actually. There were thoughts initially to make OAuth and extension of OpenID but because I was wary of the politics within the OpenID community, I pushed for keeping OAuth completely separate and avoid having to do anything with authentication (so that it could be used with OpenID, but would have its own adoption curve). The typo on the homepage was probably my fault, since, being the identity n00b, I didn't realize the difference until after I went home from the DevHouse where I put up the homepage after a couple beers. It didn't change because (apparently!) no one else seemed to read it that closely. Funny how these things develop -- not always out of explicit intention, but just because of the time allotted to get the thing out the door! ...as for your idea, George, I think I get it, and it sounds interesting. Can you give a concrete example where that could be used today? Chris On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist h...@granqvist.com wrote: Yep. The entire authentication/authorization discussion is sadly muddled. The OAuth/OpenID hybrid proposal is adding to the confusion. Sometimes I feel like we (people who have interest in the two concepts) maintain there is a difference to justify standards' existence, even if it's largely an academic difference with no pragmatic real meaning. Other times it feels okay that they should be separate. Just one of those things, I guess. For the longest time oauth.net claimed OAuth was for API authentication and no one really noticed. The only thing worth being very strict about, IMO, is identity and authentication. Never the twain should meet. It's HMACs all the way down anyway :) Hans On Wed, Jan 28, 2009 at 12:02 PM, John Kristian jmkrist...@gmail.com wrote: Yes, a digital signature can be used for authentication. SSL/TLS is one example. OAuth specifies some signing algorithms that could be used for the purpose. But it seems dangerous to extend OAuth to do authentication as well as authorization. Better for OAuth to focus on doing one thing really well. -- 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: Authentication API protected with OAuth
Ah ha. I get it. That makes sense -- though it does seem like the goal should be to move away from asking for usernames and passwords. This, however, speaks to my concept of an account pin, where you could authorize desktop apps with an easy-to-remember pin that doesn't give you full account access, but only allows you to validate that you own the account. So you would have a full access password (seldom used) and an identification PIN -- almost like a security question (we know how well those work). So instead of a user inputting their username and password, they would input their username and PIN, and the PIN would be used to sign the request, proving to the SP that it's the right user -- and then the SP would provide the access token. Is that a similar but equally effective approach? Chris On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher gffle...@aol.com wrote: Thanks for this history Chris. I remember it still being API authentication in the first drafts of the OAuth IPR document; because it was one of my comments on the doc:) Here is an example usage. Again, this is more about leveraging the OAuth signature mechanism than trying to represent the whole OAuth flow. Currently at AOL we have a clientLogin API that allows a client (think destop app or mobile device) to authenticate a user and then access services at AOL. Basically, the authentication credentials are exchanged for a token that is used subsequently to access the APIs. The user's credentials are only passed to the AOL authentication service, over SSL, for validation. With the method suggested, the same validation could take place but the password would not be present in the request. Instead it would be used to sign the request. The request is only valid if the receiving authentication system can generate the signature using the password for that user. The successful response of such a request would be the API access token currently used. Another possibility (the example from the initial discussion) is using this mechanism with TLS in order to return to the client a SAML Holder-of-Key Assertion. This is the same concept of exchanging one set of credentials for another credential (in this case a SAML Assertion). I realize that there are security issues with allowing a client or API based authentication mechanism, but there are certain cases where it provides a better user experience and the user is comfortable trusting the application/device. Thanks, George Chris Messina wrote: Hmm. Historically the separation came from the way the communities grew up actually. There were thoughts initially to make OAuth and extension of OpenID but because I was wary of the politics within the OpenID community, I pushed for keeping OAuth completely separate and avoid having to do anything with authentication (so that it could be used with OpenID, but would have its own adoption curve). The typo on the homepage was probably my fault, since, being the identity n00b, I didn't realize the difference until after I went home from the DevHouse where I put up the homepage after a couple beers. It didn't change because (apparently!) no one else seemed to read it that closely. Funny how these things develop -- not always out of explicit intention, but just because of the time allotted to get the thing out the door! ...as for your idea, George, I think I get it, and it sounds interesting. Can you give a concrete example where that could be used today? Chris On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist h...@granqvist.com mailto:h...@granqvist.com wrote: Yep. The entire authentication/authorization discussion is sadly muddled. The OAuth/OpenID hybrid proposal is adding to the confusion. Sometimes I feel like we (people who have interest in the two concepts) maintain there is a difference to justify standards' existence, even if it's largely an academic difference with no pragmatic real meaning. Other times it feels okay that they should be separate. Just one of those things, I guess. For the longest time oauth.net http://oauth.net claimed OAuth was for API authentication and no one really noticed. The only thing worth being very strict about, IMO, is identity and authentication. Never the twain should meet. It's HMACs all the way down anyway :) Hans On Wed, Jan 28, 2009 at 12:02 PM, John Kristian jmkrist...@gmail.com mailto:jmkrist...@gmail.com wrote: Yes, a digital signature can be used for authentication. SSL/TLS is one example. OAuth specifies some signing algorithms that could be used for the purpose. But it seems dangerous to extend OAuth to do authentication as well as authorization. Better for OAuth to focus on doing one thing really well
[oauth] Fwd: [diso-project] PHP XRDS-Simple Library
Figured folks on these lists would be able to provide some feedback on Will's initial go at an XRDS-Simple library in PHP: -- Forwarded message -- From: Will Norris w...@willnorris.com Date: Fri, 26 Dec 2008 13:57:23 -0800 Subject: [diso-project] PHP XRDS-Simple Library To: diso-proj...@googlegroups.com I started on a XRDS-Simple library for PHP some time ago and would like to solicit some feedback. You can find the current code in the DiSo repository: http://diso.googlecode.com/svn/php/xrds-simple/trunk/ My motivation for writing this library is that all of the XRDS code I've seen thus far has been in the form of fetchers and parsers. No one as written an actual generic library for dealing with XRDS as far as I can tell. This becomes particularly important when we're needing to publish an XRDS document and need a clean way for other code (ie. WordPres plugins) to contribute additional services to be included. If you've looked at the existing XRDS-Simple plugin for WordPress, you'll note that the interface for contributing additional services into the document is less than ideal. This was okay at the time, but now we need something better. The library can be divided into three logical parts (which don't necessarily translate to separate code just yet): - Discovery: getting the XRDS-Simple document for a URI. Today, we have three basic methods of doing this (content negotiation, a special HTTP response header, and a special HTML link tag. In the future, this will very possibly (likely) include other methods such as DNS lookups, known URL locations (/site-meta), and different HTTP response headers (Link). - Marshalling/Unmarshalling: once we know where to get the XRDS document, we need to parse the XML into something we can work with in PHP. Similarly, when it comes time to publish an XRDS document, we need an easy way to convert our PHP structures into well formed XML. Today, this is not cleanly separated in the code, but I suspect it will need to be. This is particularly true if we want to support both PHP4 and PHP5. Right now I'm using the PHP DOM library for the marshalling, which is only available in PHP5. If we want to support PHP4, we'll need to write marshallers that use the DOM XML library. If the code is cleanly abstracted, this won't actually be very difficult. - Working with XRDS: the final logical part of the library has to do with working with the XRDS itself. Just the basic methods for adding and removing the actual elements like Services, Types, URIs, etc, as well as convenience methods for finding the highest priority URI for that service that supports a given type. I've got one or two of these convenience methods, but haven't thought all the way through how to expose them. While this library is currently based on the current XRDS-Simple spec, I fully expect to migrate it to the new XRD spec that comes out of the XRI TC. Right now I'm also only focussing on PHP5. As I mentioned above, writing a marshaller for PHP4 shouldn't be too difficult. I'm also using a lot of PHP5 conventions for objects that will need to be modified if we actually think PHP4 support is important enough. I'm not ready to make that call either way right now. Right now I'd love to hear any feedback on this. There are a couple of phpUnit tests to see how the pieces fit together. Does this seem like a logical approach to this problem? Am I overlooking anything really big? Thanks, Will -- 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 -~--~~~~--~~--~--~---
