[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: Request for new Security Considerations text
Cool. Are there any other new security consideration sections we need to add, or is this the only one? EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Friday, May 08, 2009 3:39 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text I like it. On Fri, May 8, 2009 at 3:35 PM, Darren Bounds dar...@cliqset.com wrote: I'm good with that. So we're left with: Cross-Site Request Forgery (CSRF) Attacks Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the resource owner. Service Providers should strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the user at the consumer site intended to complete the OAuth negotiation with the service provider. Darren On Fri, May 8, 2009 at 6:28 PM, Brian Eaton bea...@google.com wrote: On Fri, May 8, 2009 at 3:16 PM, Darren Bounds dar...@cliqset.com wrote: While that's nice to have, I do not believe it's necessary to foil the attack. Acting purely on the identity of the user completes the OAuth dance is enough and can still be considered a secure consumer implementation. Not unless there is a user consent page presented before the consumer completes the linkage. You need some kind of user consent at the consumer side to verify that the user really intended to link the SP account to the consumer account. This is not totally out of the realms of normal CSRF protection, but it is a bit subtle. How about this: CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the user at the consumer site intended to complete the OAuth negotiation with the service provider. User intent can be divined in one of two ways: 1) mixed binding, where you make sure the user who started the process and the user who finished it are the same. 2) late binding, where the consumer asks the user whether they want to link their account. There are real-world examples of late binding being very useful as a UI optimization: http://code.google.com/apis/gadgets/docs/oauth.html#skip_popup Cheers, Brian -- darren bounds dar...@cliqset.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Request for new Security Considerations text
There were two others in my first note on this thread, one on UI redress, another on automated repeat approvals. On Mon, May 11, 2009 at 11:45 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Cool. Are there any other new security consideration sections we need to add, or is this the only one? EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Friday, May 08, 2009 3:39 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text I like it. On Fri, May 8, 2009 at 3:35 PM, Darren Bounds dar...@cliqset.com wrote: I'm good with that. So we're left with: Cross-Site Request Forgery (CSRF) Attacks Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the resource owner. Service Providers should strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the user at the consumer site intended to complete the OAuth negotiation with the service provider. Darren On Fri, May 8, 2009 at 6:28 PM, Brian Eaton bea...@google.com wrote: On Fri, May 8, 2009 at 3:16 PM, Darren Bounds dar...@cliqset.com wrote: While that's nice to have, I do not believe it's necessary to foil the attack. Acting purely on the identity of the user completes the OAuth dance is enough and can still be considered a secure consumer implementation. Not unless there is a user consent page presented before the consumer completes the linkage. You need some kind of user consent at the consumer side to verify that the user really intended to link the SP account to the consumer account. This is not totally out of the realms of normal CSRF protection, but it is a bit subtle. How about this: CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the user at the consumer site intended to complete the OAuth negotiation with the service provider. User intent can be divined in one of two ways: 1) mixed binding, where you make sure the user who started the process and the user who finished it are the same. 2) late binding, where the consumer asks the user whether they want to link their account. There are real-world examples of late binding being very useful as a UI optimization: http://code.google.com/apis/gadgets/docs/oauth.html#skip_popup Cheers, Brian -- darren bounds dar...@cliqset.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Discovery 1.0 status
The specific post you are looking for is: http://www.hueniverse.com/hueniverse/2009/03/xrdbased-oauth-discovery-sneakpeek.html EHL From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Chris Messina Sent: Monday, May 11, 2009 11:14 AM To: oauth@googlegroups.com Subject: [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.commailto:andrewarn...@gmail.com wrote: 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.comhttp://factoryjoe.com // diso-project.orghttp://diso-project.org // openid.nethttp://openid.net // vidoop.comhttp://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: Request for new Security Considerations text
I'm being lazy today. Can you fish those out and reply with something I can just cut/paste into the spec? :-) EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Monday, May 11, 2009 11:52 AM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text There were two others in my first note on this thread, one on UI redress, another on automated repeat approvals. On Mon, May 11, 2009 at 11:45 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Cool. Are there any other new security consideration sections we need to add, or is this the only one? EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Friday, May 08, 2009 3:39 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text I like it. On Fri, May 8, 2009 at 3:35 PM, Darren Bounds dar...@cliqset.com wrote: I'm good with that. So we're left with: Cross-Site Request Forgery (CSRF) Attacks Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the resource owner. Service Providers should strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the user at the consumer site intended to complete the OAuth negotiation with the service provider. Darren On Fri, May 8, 2009 at 6:28 PM, Brian Eaton bea...@google.com wrote: On Fri, May 8, 2009 at 3:16 PM, Darren Bounds dar...@cliqset.com wrote: While that's nice to have, I do not believe it's necessary to foil the attack. Acting purely on the identity of the user completes the OAuth dance is enough and can still be considered a secure consumer implementation. Not unless there is a user consent page presented before the consumer completes the linkage. You need some kind of user consent at the consumer side to verify that the user really intended to link the SP account to the consumer account. This is not totally out of the realms of normal CSRF protection, but it is a bit subtle. How about this: CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the user at the consumer site intended to complete the OAuth negotiation with the service provider. User intent can be divined in one of two ways: 1) mixed binding, where you make sure the user who started the process and the user who finished it are the same. 2) late binding, where the consumer asks the user whether they want to link their account. There are real-world examples of late binding being very useful as a UI optimization: http://code.google.com/apis/gadgets/docs/oauth.html#skip_popup Cheers, Brian -- darren bounds dar...@cliqset.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Request for new Security Considerations text
We can't really link to a website from the spec, only to other documents. Any other ideas to replace your reference to [1]? EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Monday, May 11, 2009 12:59 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text Service providers should protect the approval process against clickjacking (sometimes called UI redress) attacks. As of the time of this writing, no complete defenses against clickjacking are available. A survey of attacks and defenses may be found at [1]. Service providers can mitigate the risk of UI redress attacks through the following techniques: - javascript frame busting - javascript frame busting, and requiring that browsers have javascript enabled on the approval page - browser-specific anti-framing techniques - requiring password reentry before issuing OAuth tokens Automatic Repeat Approvals Some service providers may wish to automatically approve OAuth access requests from consumers who the user has already indicated they trust. For example: Consumer sends request token request User is redirected to service provider approval URL. Service provider detects that user has approved previous access requests from this consumer. Service provider does not prompt the user for approval, and instead redirects the user back to the consumer. Consumer fetches approved access token for user. Automatic repeat approvals create additional security risks by removing the need for a consumer to possess an access token to fetch a user's data. If no automatic repeat approval is used, the attacker must use social engineering to convince the user to approve access. Once automatic approvals are implemented social engineering is no longer necessary. Compromise of the consumer secret is sufficient to gain automatic access to a user's data. Service providers can mitigate the risks associated with automatic repeat approval flows by limiting the scope of access tokens returned for such approvals. [1] http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_( UI_redressing) On Mon, May 11, 2009 at 11:55 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: I'm being lazy today. Can you fish those out and reply with something I can just cut/paste into the spec? :-) EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Monday, May 11, 2009 11:52 AM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text There were two others in my first note on this thread, one on UI redress, another on automated repeat approvals. On Mon, May 11, 2009 at 11:45 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Cool. Are there any other new security consideration sections we need to add, or is this the only one? EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Friday, May 08, 2009 3:39 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text I like it. On Fri, May 8, 2009 at 3:35 PM, Darren Bounds dar...@cliqset.com wrote: I'm good with that. So we're left with: Cross-Site Request Forgery (CSRF) Attacks Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the resource owner. Service Providers should strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the user at the consumer site intended to complete the OAuth negotiation with the service provider. Darren On Fri, May 8, 2009 at 6:28 PM, Brian Eaton bea...@google.com wrote: On Fri, May 8, 2009 at 3:16 PM, Darren Bounds dar...@cliqset.com wrote: While that's nice to have, I do not believe it's necessary to foil the attack. Acting purely on the identity of the user completes the OAuth dance is enough and can still be considered a secure consumer implementation. Not unless there is a user consent page presented before the consumer completes the linkage. You need some kind of user consent at the consumer side to verify that the user really intended to link the SP account to the consumer account. This is not totally out of the realms of normal CSRF protection,
[oauth] Re: Request for new Security Considerations text
Wikipedia is about as formal as you're going to get for the moment: http://en.wikipedia.org/wiki/Clickjacking On Mon, May 11, 2009 at 1:27 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: We can't really link to a website from the spec, only to other documents. Any other ideas to replace your reference to [1]? EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Monday, May 11, 2009 12:59 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text Service providers should protect the approval process against clickjacking (sometimes called UI redress) attacks. As of the time of this writing, no complete defenses against clickjacking are available. A survey of attacks and defenses may be found at [1]. Service providers can mitigate the risk of UI redress attacks through the following techniques: - javascript frame busting - javascript frame busting, and requiring that browsers have javascript enabled on the approval page - browser-specific anti-framing techniques - requiring password reentry before issuing OAuth tokens Automatic Repeat Approvals Some service providers may wish to automatically approve OAuth access requests from consumers who the user has already indicated they trust. For example: Consumer sends request token request User is redirected to service provider approval URL. Service provider detects that user has approved previous access requests from this consumer. Service provider does not prompt the user for approval, and instead redirects the user back to the consumer. Consumer fetches approved access token for user. Automatic repeat approvals create additional security risks by removing the need for a consumer to possess an access token to fetch a user's data. If no automatic repeat approval is used, the attacker must use social engineering to convince the user to approve access. Once automatic approvals are implemented social engineering is no longer necessary. Compromise of the consumer secret is sufficient to gain automatic access to a user's data. Service providers can mitigate the risks associated with automatic repeat approval flows by limiting the scope of access tokens returned for such approvals. [1] http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_( UI_redressing) On Mon, May 11, 2009 at 11:55 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: I'm being lazy today. Can you fish those out and reply with something I can just cut/paste into the spec? :-) EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Monday, May 11, 2009 11:52 AM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text There were two others in my first note on this thread, one on UI redress, another on automated repeat approvals. On Mon, May 11, 2009 at 11:45 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Cool. Are there any other new security consideration sections we need to add, or is this the only one? EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Friday, May 08, 2009 3:39 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text I like it. On Fri, May 8, 2009 at 3:35 PM, Darren Bounds dar...@cliqset.com wrote: I'm good with that. So we're left with: Cross-Site Request Forgery (CSRF) Attacks Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the resource owner. Service Providers should strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the user at the consumer site intended to complete the OAuth negotiation with the service provider. Darren On Fri, May 8, 2009 at 6:28 PM, Brian Eaton bea...@google.com wrote: On Fri, May 8, 2009 at 3:16 PM, Darren Bounds dar...@cliqset.com wrote: While that's nice to have, I do not believe it's necessary to foil the attack. Acting purely on the identity of the user completes the OAuth dance is enough and can still be considered a secure consumer implementation. Not unless there is a user consent page presented before the consumer completes the linkage. You need some kind of user consent at the
[oauth] Re: Request for new Security Considerations text
Why do we need any link? Why isn't it enough to just say 'Clickjacking' and let people find out more info on their own. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Monday, May 11, 2009 1:41 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text Wikipedia is about as formal as you're going to get for the moment: http://en.wikipedia.org/wiki/Clickjacking On Mon, May 11, 2009 at 1:27 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: We can't really link to a website from the spec, only to other documents. Any other ideas to replace your reference to [1]? EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Monday, May 11, 2009 12:59 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text Service providers should protect the approval process against clickjacking (sometimes called UI redress) attacks. As of the time of this writing, no complete defenses against clickjacking are available. A survey of attacks and defenses may be found at [1]. Service providers can mitigate the risk of UI redress attacks through the following techniques: - javascript frame busting - javascript frame busting, and requiring that browsers have javascript enabled on the approval page - browser-specific anti-framing techniques - requiring password reentry before issuing OAuth tokens Automatic Repeat Approvals Some service providers may wish to automatically approve OAuth access requests from consumers who the user has already indicated they trust. For example: Consumer sends request token request User is redirected to service provider approval URL. Service provider detects that user has approved previous access requests from this consumer. Service provider does not prompt the user for approval, and instead redirects the user back to the consumer. Consumer fetches approved access token for user. Automatic repeat approvals create additional security risks by removing the need for a consumer to possess an access token to fetch a user's data. If no automatic repeat approval is used, the attacker must use social engineering to convince the user to approve access. Once automatic approvals are implemented social engineering is no longer necessary. Compromise of the consumer secret is sufficient to gain automatic access to a user's data. Service providers can mitigate the risks associated with automatic repeat approval flows by limiting the scope of access tokens returned for such approvals. [1] http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_( UI_redressing) On Mon, May 11, 2009 at 11:55 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: I'm being lazy today. Can you fish those out and reply with something I can just cut/paste into the spec? :-) EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Monday, May 11, 2009 11:52 AM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text There were two others in my first note on this thread, one on UI redress, another on automated repeat approvals. On Mon, May 11, 2009 at 11:45 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Cool. Are there any other new security consideration sections we need to add, or is this the only one? EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Friday, May 08, 2009 3:39 PM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text I like it. On Fri, May 8, 2009 at 3:35 PM, Darren Bounds dar...@cliqset.com wrote: I'm good with that. So we're left with: Cross-Site Request Forgery (CSRF) Attacks Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the resource owner. Service Providers should strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the user at the consumer site intended to complete the OAuth negotiation with the service provider. Darren On Fri, May 8, 2009 at 6:28 PM,
[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: Request for new Security Considerations text
Does the OpenID Hybrid Protocol need to be amended to mention that Hybrid should not use auto-approval for OAuth tokens? Allen Brian Eaton wrote: Automatic Repeat Approvals Some service providers may wish to automatically approve OAuth access requests from consumers who the user has already indicated they trust. For example: Consumer sends request token request User is redirected to service provider approval URL. Service provider detects that user has approved previous access requests from this consumer. Service provider does not prompt the user for approval, and instead redirects the user back to the consumer. Consumer fetches approved access token for user. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
