Of *Manger, James H
*Sent:* Friday, April 16, 2010 9:52 PM
*To:* Eran Hammer-Lahav; OAuth WG
*Subject:* Re: [OAUTH-WG] Issue: Split the authorization endpoint into
two endpoints
> This has nothing to do with it. There is no PUT and DELETE or POST
with non-form body when *requesting a toke
, 2010 9:52 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Issue: Split the authorization endpoint into two
endpoints
> This has nothing to do with it. There is no PUT and DELETE or POST with
> non-form body when *requesting a token*.
It is relevant.
I don’t want to authenticate
separate functional API parameters, like
callback url, and authorization data.
regards,
Torsten.
Am 17.04.2010 06:52, schrieb Manger, James H:
Re: [OAUTH-WG] Issue: Split the authorization endpoint into
two endpoints
> This has nothing to do with it.
> How would use differentiate between the username and password profile and the
> client credentials profile, if you are using Basic or Digest?
Removing the client_secret from both flows still leaves one flow with
‘username’ and ‘password’ POST parameters (of the user, not client), which
indi
ent access to
OAuth authorization servers.
I would recommend to separate functional API parameters, like callback url, and
authorization data.
regards,
Torsten.
Am 17.04.2010 06:52, schrieb Manger, James H:
Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints
> Thi
Hammer-Lahav
Sent: Friday, 16 April 2010 4:41 AM
To: OAuth WG
Subject: [OAUTH-WG] Issue: Split the authorization endpoint into
two endpoints
OAuth 2.0 defines a single authorization endpoint with a 'type'
parameter
for the various flows and flow steps
ll
use “normal” auth when clients talk to the trusted
account/authorization system.
--
James Manger
*From:* Eran Hammer-Lahav [mailto:e...@hueniverse.com]
*Sent:* Saturday, 17 April 2010 12:58 PM
*To:* Manger, James H; Luke Shepard; John Kemp
*Cc:* OAuth WG
*Subject:* Re: [OAUTH-WG] Issue: Sp
rmal” auth
when clients talk to the trusted account/authorization system.
--
James Manger
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Saturday, 17 April 2010 12:58 PM
To: Manger, James H; Luke Shepard; John Kemp
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Split the authorizatio
This has nothing to do with it. There is no PUT and DELETE or POST with
non-form body when *requesting a token*.
We need to do a better job not to confuse accessing protected resources with
the flow calls. They are completely different.
EHL
On 4/16/10 7:02 PM, "James Manger" wrote:
>> In ei
>> In either case, we should not restrict the access token URL to POST-only.
>> A GET request is just as secure and can be much easier to write code for
> If you are using GET, then refresh tokens and client secrets will end
> up side by side in web server log files.
These are exactly the sort of
On Fri, Apr 16, 2010 at 9:58 AM, Luke Shepard wrote:
> I guess I would prefer two URLs as well, but I see the simplicity argument as
> well:
>
>>> Constraints for endpoints:
>>> access token URL: HTTPS and POST only, no user
>>> user authentication URL: HTTP or HTTPS, GET or POST, authenticated u
r to save some bytes.
--
James Manger
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, 16 April 2010 4:41 AM
To: OAuth WG
Subject: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints
OAuth
> Sent: Thursday, April 15, 2010 7:11 PM
> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Issue: Split the authorization endpoint into two
> endpoints
>
> On Apr 15, 2010, at 9:22 PM, Manger, James H wrote:
>
>> I strongly favour specifying 2 separate endpoi
On Fri, Apr 16, 2010 at 7:01 AM, Justin Richer wrote:
> I favor this approach as well. It feels cleaner to me to have a
> separation of purposes here. The two endpoints could always be collapsed
> in a particular implementation -- I've seen several OAuth 1.0
> implementations that do just this, u
emp
Sent: Thursday, April 15, 2010 7:11 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Split the authorization endpoint into two
endpoints
On Apr 15, 2010, at 9:22 PM, Manger, James H wrote:
> I strongly favour specifying 2 separate endpoints: one for where to redirect
I favor this approach as well. It feels cleaner to me to have a
separation of purposes here. The two endpoints could always be collapsed
in a particular implementation -- I've seen several OAuth 1.0
implementations that do just this, using a URL parameter to
differentiate between the request, acces
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Eran Hammer-Lahav
> Sent: Friday, 16 April 2010 4:41 AM
> To: OAuth WG
> Subject: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints
>
> OAuth 2.0 defines a single authorization endpoint wi
to the other to save some bytes.
--
James Manger
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, 16 April 2010 4:41 AM
To: OAuth WG
Subject: [OAUTH-WG] Issue: Split the authorization endpoint into two
Strongly for keeping one endpoint given that the spec uses type
extensively. A huge motivator in the 2.0 effort is simplicity for
client developers.
On Thu, Apr 15, 2010 at 11:41 AM, Eran Hammer-Lahav wrote:
> OAuth 2.0 defines a single authorization endpoint with a 'type' parameter
> for the va
OAuth 2.0 defines a single authorization endpoint with a 'type' parameter
for the various flows and flow steps. There are two types of calls made to
the authorization endpoint:
- Requests for Access - requests in which an end user interacts with the
authorization server, granting client access.
-
20 matches
Mail list logo
