Re: [OAUTH-WG] Request sent to http: instead of https:`

In which case, nothing the legit server does can help that client. Since they're talking to the evil. On Wednesday, October 13, 2010, Breno wrote: > Or a connection to evil will happen. > > On Wed, Oct 13, 2010 at 6:33 PM, Eran Hammer-Lahav > wrote: >> I don't think so. If you are not running a

Re: [OAUTH-WG] Request sent to http: instead of https:`

Or a connection to evil will happen. On Wed, Oct 13, 2010 at 6:33 PM, Eran Hammer-Lahav wrote: > I don't think so. If you are not running a server on port 80, the connection > will never happen and nothing bad will be send on the wire. > > EHL > >> -Original Message- >> From: oauth-boun.

Re: [OAUTH-WG] Request sent to http: instead of https:`

In our architecture, revoking the specific token would mean revoking access to the app, which is something we don't want to do. We just return an error message but do not invalidate the token. I think that this is fine. Since it doesn't work, it will only be encountered in development. On Oct 1

Re: [OAUTH-WG] Request sent to http: instead of https:`

Write it, and I'll get it incorporated. EHL > -Original Message- > From: Breno [mailto:breno.demedei...@gmail.com] > Sent: Wednesday, October 13, 2010 4:49 PM > To: Jeff Lindsay > Cc: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` > >

Re: [OAUTH-WG] Request sent to http: instead of https:`

I don't think so. If you are not running a server on port 80, the connection will never happen and nothing bad will be send on the wire. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of William Mills > Sent: Wednesday, October 13, 201

[OAUTH-WG] Call for Consensus on Document Split

Over the past few weeks, the working group debated the issues around the introduction of signatures and the structure of the specification. The working group seems to endorse the proposal to split the current specification into two parts: one including section 5 (bearer token) and the other includi

Re: [OAUTH-WG] Request sent to http: instead of https:`

> > This rather implies that we're specifying running a full server on port 80 > as a "stupid detector". We should tread carefully here. > Right, I suppose you're better off not responding on port 80 if possible. But I imagine this could be phrased in Section 5.0 roughly, "if the resource server

Re: [OAUTH-WG] Request sent to http: instead of https:`

This rather implies that we're specifying running a full server on port 80 as a "stupid detector". We should tread carefully here. > +1 for language in the spec describing how to handle this case > > On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay > wrote: > >> Hopefully you also invalidate the

Re: [OAUTH-WG] Request sent to http: instead of https:`

+1 for language in the spec describing how to handle this case On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay wrote: >> Hopefully you also invalidate the token (if bearer) since it was send over >> an insecure channel. > > Excuse my naivety, but perhaps that's worth putting in the spec? > >> >> EH

Re: [OAUTH-WG] Request sent to http: instead of https:`

> > Hopefully you also invalidate the token (if bearer) since it was send over > an insecure channel. > Excuse my naivety, but perhaps that's worth putting in the spec? > > EHL > > > -Original Message- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Bre

Re: [OAUTH-WG] Request sent to http: instead of https:`

Hopefully you also invalidate the token (if bearer) since it was send over an insecure channel. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Breno > Sent: Wednesday, October 13, 2010 11:31 AM > To: oauth@ietf.org > Subject: [OAUTH

Re: [OAUTH-WG] Request sent to http: instead of https:`

On Wed, Oct 13, 2010 at 2:00 PM, Paul Tarjan wrote: >> >>> At Facebook we issue an HTTP 400 with "invalid_request" as the error. >>> http://graph.facebook.com/me?access_token=blah&client_id=150629244948164 >>> (the client_id is to enable draft-10 error messaging). >> >> Without client_id you get a

Re: [OAUTH-WG] Request sent to http: instead of https:`

> >> At Facebook we issue an HTTP 400 with "invalid_request" as the error. >> http://graph.facebook.com/me?access_token=blah&client_id=150629244948164 >> (the client_id is to enable draft-10 error messaging). > > Without client_id you get a different error message (JSON as well, but > not OAuth2

Re: [OAUTH-WG] Request sent to http: instead of https:`

On Wed, Oct 13, 2010 at 1:46 PM, Paul Tarjan wrote: > At Facebook we issue an HTTP 400 with "invalid_request" as the error. > http://graph.facebook.com/me?access_token=blah&client_id=150629244948164 > (the client_id is to enable draft-10 error messaging). Without client_id you get a different err

Re: [OAUTH-WG] Request sent to http: instead of https:`

At Facebook we issue an HTTP 400 with "invalid_request" as the error. http://graph.facebook.com/me?access_token=blah&client_id=150629244948164 (the client_id is to enable draft-10 error messaging). On Oct 13, 2010, at 11:

[OAUTH-WG] Request sent to http: instead of https:`

Suppose server A documents that their endpoint X is at https://server.example.com/x; there's no service at the corresponding http location for security reasons. Client developer fatfingers URL as http://server.example.com/x What is the correct response? I understand that this is out of scope for

Re: [OAUTH-WG] Opensource impl yet?

Don't have SASL yet, but probably worth putting on that page: http://github.com/progrium/oauth2-appengine Intended for learning purposes. -jeff On Tue, Oct 12, 2010 at 10:32 PM, David Recordon wrote: > I haven't seen one. Have been trying to keep track of all the > implementation on http://wiki