Re: [OAUTH-WG] OAuth 2.0: client_secret, state

Actually, Brian and I discussed this very topic at some length after the OAuth after-party today. If you think about it, it is impossible to completely separate the Authz Server (AS) from the Protected Resource (PR) -- in all of the possible cases, the AS needs to be able to pass secure me

Re: [OAUTH-WG] What error codes do you need?

In case it's helpful, BCP 56 / RFC 3205 provides recommendations for using HTTP as a substrate for other protocols: ... in particular with respect to status codes: It's worth thinking about how that document appli

Re: [OAUTH-WG] OAuth 2.0: client_secret, state

Hey Allen, Thanks for the feedback! I'm planning to remove the client secret from the signature mechanism as I heard this from someone else as well. --David On Mon, Mar 22, 2010 at 4:20 PM, Allen Tom wrote: > Hi All - > > Regarding the client secret - one of the design goals for OAuth-WRAP was t

Re: [OAUTH-WG] What are the OAuth design principles?

My design principles would be the following as we already have protocols that solve many complex usecases 1. Simple programming model 3. Reduce deployment barriers 2. Limited or no client side code (works with a browser) 3. Replace username/password scenarios 4. No client side key distributio

Re: [OAUTH-WG] OAuth 2.0: client_secret, state

Hi All - Regarding the client secret - one of the design goals for OAuth-WRAP was to cleanly separate the AuthZ server from the Protected Resource. The Protected Resource should only have to know how to validate Access Tokens issued by its AuthZ server. The HMAC-SHA1 signature method defined in 4

[OAUTH-WG] What are the OAuth design principles?

Since the discussion in the "OAuth after-party" seemed to warrant bringing it up, I mentioned the UMA design principles/requirements document. You can find it here: http://kantarainitiative.org/confluence/display/uma/UMA+Requirements The discussion is around "Why can't Kerberos just be used fo

Re: [OAUTH-WG] OAuth 2.0: client_secret, state

Luke & David, The different security characteristics of TLS client certs (or TLS-PSK, or TLS-SRP, or HTTP BASIC, or cookies, or IPsec...) vs oauth_client_secret-in-body don't require any change to the *flow*. The interaction model does not change. We need to limit the complexity of adding new f

Re: [OAUTH-WG] What error codes do you need?

+1 to the problem reporting codes. We've found them very useful at LinkedIn. I'd also like to see throttling error codes, since many APIs support this concept. On Mon, Mar 22, 2010 at 3:02 PM, Justin Hart wrote: > Was there early discussion that had much of the work in the > ProblemReporting

Re: [OAUTH-WG] Understanding how OpenSocial uses OAuth 1.0a

On Fri, Mar 19, 2010 at 6:21 PM, Brian Eaton wrote: > > The gadget tells the container *where* to send the request.  So if > OpenSocial gadgets supported PLAINTEXT, a malicious gadget author, or > a malicious user of a gadget (they are pure javascript) could tell the > container "please send a req

Re: [OAUTH-WG] What error codes do you need?

Was there early discussion that had much of the work in the ProblemReporting extension included for 2.0? http://wiki.oauth.net/ProblemReporting On Mon, Mar 22, 2010 at 2:26 PM, Chris Messina wrote: > We've had this page on the wiki for some time... perhaps it could be > updated to actually offer

Re: [OAUTH-WG] A token use case

Hey Greg, I think that the Client Identifier and Secret flow should address this. It definitely needs to be called out better. --David On Mon, Mar 22, 2010 at 2:23 PM, Greg Brail wrote: > I'd like to describe a token-related use case that, right now, is how some > people are using parts of OAut

[OAUTH-WG] A token use case

I'd like to describe a token-related use case that, right now, is how some people are using parts of OAuth 1.0. I think it's a real use case and I'm wondering how the proposed OAuth 2.0 would handle it. (I'm on the IETF call too and it is very quiet.) We have seen APIs out there that require th

Re: [OAUTH-WG] What error codes do you need?

We've had this page on the wiki for some time... perhaps it could be updated to actually offer all the appropriate error codes (including those from HTTP) that are relevant? http://wiki.oauth.net/ErrorCases Chris On Mon, Mar 22, 2010 at 10:56 AM, David Recordon wrote: > In drafting OAuth 2.0 I

[OAUTH-WG] Reminder: OAuth WG Meeting Today 1pm PT

Please join us either in person (Anaheim, CA) or via WebEx/Jabber. Information about how to join via WebEx is here: http://www.ietf.org/meeting/77/webex.html General information about the session: http://www.ietf.org/proceedings/10mar/agenda/oauth.txt EHL smime.p7s Description: smime.p7s A

[OAUTH-WG] What error codes do you need?

In drafting OAuth 2.0 I removed a lot of the error codes throughout the flows and in this draft encouraged people to use HTTP status codes (like 1.0a does). I've heard the feedback from multiple people that they'd like more specific error codes than what can be expressed in HTTP. I'd like to use

Re: [OAUTH-WG] OAuth 2.0: client_secret, state

Thanks for the feedback! Inline... On Mon, Mar 22, 2010 at 5:11 AM, Manger, James H wrote: > Thanks for writing this draft for OAuth 2.0, David. > A couple of comments. > > 1. CLIENT SECRET > Client authentication needs to be independent of OAuth. > The Web Server Flow sends oauth_client_secret

Re: [OAUTH-WG] OAuth 2.0: client_secret, state

Few responses inline. On Mar 22, 2010, at 5:11 AM, Manger, James H wrote: > 1. CLIENT SECRET > Client authentication needs to be independent of OAuth. > The Web Server Flow sends oauth_client_secret to the access token request > endpoint along with other oauth_ parameters. This is a poor design.

Re: [OAUTH-WG] First draft of OAuth 2.0

Another +1 for "dynamic introduction". Putting the required details (eg user authz URI) in a 401 HTTP WWW-Authenticate header feels like a better approach to me than XRD in this instance. At the moment in the OAuth 2 draft (and in WRAP) identical 401 responses can mean: 1. Send the user to an au

[OAUTH-WG] OAuth 2.0: client_secret, state

Thanks for writing this draft for OAuth 2.0, David. A couple of comments. 1. CLIENT SECRET Client authentication needs to be independent of OAuth. The Web Server Flow sends oauth_client_secret to the access token request endpoint along with other oauth_ parameters. This is a poor design. Conside