> 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 direct client requests *only* when they *request a
token*.
Clients might make any variety of direct requests unrelated to OAuth.
Latest is always at:
http://github.com/theRazorBlade/draft-ietf-oauth
(xml is always up to date. txt and html when I can. Atom feed available)
---
Latest changes:
- Split authorization endpoint to authorization and token endpoints.
- Shortened type parameter values to just the flow name.
- Rem
On 4/16/10 6:00 PM, "Evan Gilbert" wrote:
> - Add text to the spec to give overview of options for native app developers
I need a proposal.
EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
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
You should also accept 'oauth_token'. That's one place a prefix makes sense
because there is no telling what a protected resource URI might look like.
EHL
On 4/16/10 6:24 PM, "Luke Shepard" wrote:
Oh, and fwiw, we dropped the prefix EVERYWHERE. So even the protected resource
just takes "acce
Marius
> When replacing the placeholders with actual values, how do you know
> what encoding should be used? Does URL encoding work in all cases?
%-escaping any chars outside the 66 chars works in (almost) all
cases.
The only exception is if you want a non-ASCII value substituted into a domain
>> 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
Oh, and fwiw, we dropped the prefix EVERYWHERE. So even the protected resource
just takes "access_token", not "oauth_access_token", for consistency.
From: Luke Shepard
Sent: Friday, April 16, 2010 6:23 PM
To: 'Eran Hammer-Lahav'; Marius Scurtescu
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Issue: Author
So, I originally favored the prefix, as I couldn't see how you would not do it.
But I've recently implemented OAuth prototype and written some apps against it,
and I have to say, I like not having the prefix. Most developers don't care
that they are using OAuth - they just want to talk to a serv
We are going in circles. We are just not going to agree on this.
I don't think we should have a parameter prefix for OAuth-specific calls, you
think we should. Time to let other people express their view on this. I'm sure
both of us can live with both options.
EHL
On 4/16/10 5:58 PM, "Marius
A few of us from Google & Facebook had a face-to-face discussion today to
talk through the differences / similarities between Native App, Web
Callback, and User-Agent.
>From the discussion it seemed that the current Native Application flow is
equivalent to Web Callback flow, with:
1. A redirect to
On Fri, Apr 16, 2010 at 7:34 AM, Eran Hammer-Lahav wrote:
> First, this argument only holds for callbacks, not for the authorization
> endpoint.
And why is that? This argument applies exactly the same way to the
authorization endpoint. The same Drupal site can also be an OAuth 2.0
Authorization S
On 4/16/10 5:03 PM, "Brian Eaton" wrote:
On Thu, Apr 15, 2010 at 12:38 PM, Chuck Mortimore
wrote:
> Could you please take another glance at what I posted? There are a number
> of changes to the general assertion flow that are required for it to reflect
> how this will be used in a lot of scena
On Thu, Apr 15, 2010 at 12:38 PM, Chuck Mortimore
wrote:
> Could you please take another glance at what I posted? There are a number
> of changes to the general assertion flow that are required for it to reflect
> how this will be used in a lot of scenarios.
> (A) The client sends an access t
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
I'll just go with redirect_uri.
EHL
On 4/16/10 1:57 PM, "Evan Gilbert" wrote:
On Fri, Apr 16, 2010 at 1:45 PM, Eran Hammer-Lahav wrote:
We should use the right term, not just the less conflicting term.
The Web Callback flow uses a callback from the server to the client - this is
not a red
Blaine,
Hannes,
The interim meeting was a good idea.
Is it certain that the meeting will be held?
Those who have to fly to Mountain View would need to buy the tickets in
advance. Do you know when the meeting-related details will be available?
With thanks,
Zachary
-Original Message-
> In terms of format, it suggests:
>
> format
>REQUIRED. The format of the assertion as defined by the authorization
>server. The format MUST be a URI which designates a profile of the
>assertion flow.
>
> I personally think this is all that is required. It would be nice if these
>
On Fri, Apr 16, 2010 at 1:45 PM, Eran Hammer-Lahav wrote:
> We should use the right term, not just the less conflicting term.
>
> The Web Callback flow uses a callback from the server to the client – this
> is not a redirection. The User-Agent flow uses a redirection which is
> fundamentally diff
I'll split them to: Authorization endpoint and Toke endpoint. In the
WWW-Authenticate header I'll add a parameter for each (instead of one) for
lightweight discovery (which we can keep, change, or drop later).
EHL
On 4/15/10 6:22 PM, "James Manger" wrote:
I strongly favour specifying 2 separ
We should use the right term, not just the less conflicting term.
The Web Callback flow uses a callback from the server to the client - this is
not a redirection. The User-Agent flow uses a redirection which is
fundamentally different from a callback.
If you don't want to use callback and want
Because we use a single (or two) endpoints for different flows.
EHL
On 4/16/10 9:07 AM, "Richard Barnes" wrote:
Why do we need to label the requests according to which flow they
belong to?
Apologies if this is a dumb question; haven't read the latest draft.
On Apr 15, 2010, at 1:31 PM, Eran
+1 for redirect_uri -- highest semantic value imho.
-Naitik
On Apr 16, 2010, at 12:05 PM, Evan Gilbert wrote:
> We should use the same name in the User-Agent and Web Callback flows. Also,
> although the authorization server won't be allowing JSONP requests,
> "callback" has become a bit of
On Fri, Apr 16, 2010 at 12:35 PM, Luke Shepard wrote:
> The spec officially protects against collisions: All OAuth-specific
> endpoints shouldn't accept extra parameters, and the protected resources
> need only worry about "access_token".
>
Callback URIs may have their own parameters (not in the
The spec officially protects against collisions: All OAuth-specific endpoints
shouldn't accept extra parameters, and the protected resources need only worry
about "access_token".
The issue is softer - in this case, we are anticipating and preventing what
would otherwise be a common source of d
On Fri, Apr 16, 2010 at 12:26 PM, Richard Barnes wrote:
> Ok, I think I get it. Thanks for the explanation.
>
> It seems we have a collision of layers here! When OAuth parameters are
> being passed as request parameters (GET or POST), they can collide with
> parameters being used by an applicat
Ok, I think I get it. Thanks for the explanation.
It seems we have a collision of layers here! When OAuth parameters
are being passed as request parameters (GET or POST), they can collide
with parameters being used by an application (e.g., for JSONP). In
effect, encoding OAuth in this wa
Talked with Luke and now remember earlier conversations about two
URLs. We'll likely do www.facebook.com for user interactions and
api.facebook.com for server stuff.
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
We should use the same name in the User-Agent and Web Callback flows. Also,
although the authorization server won't be allowing JSONP requests,
"callback" has become a bit of a defacto standard for JSONP and it would be
nice to use a term that isn't overloaded?
Can we make them both "redirection"?
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
When replacing the placeholders with actual values, how do you know
what encoding should be used? Does URL encoding work in all cases?
Marius
On Fri, Apr 16, 2010 at 7:33 AM, Manger, James H
wrote:
> A partial solution to colliding parameter names and long URIS would be to
> use URI templates.
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 user
In either case, we should not restrict the access token U
Facebook API requests are protected resources. They can be called either in a
browser or in a server-to-server environment.
For example, a JSONP call for my name looks like this:
https://api.facebook.com/restserver.php?api_key=361900759629&call_id=1271436355034&callback=FB.RestServer._c
+1 to this
Mark McGloin
>On 16/04/2010 17:08, Richard Barnes wrote:
>Sure, this seems sensible, especially with the *optional* part.
>On Apr 15, 2010, at 3:22 PM, David Recordon wrote:
>> +1, remember discussing this a week or so ago on the list
>>
>>> On Thu, Apr 15, 2010 at 12:12 PM, Era
Could you clarify a little more the environment in which this
confusion arose? What do you mean when you say "The protected
resource typically accepts 'callback' as a parameter to support
JSONP."? What sort of software are you including in this?
--Richard
On Apr 15, 2010, at 5:41 PM, Lu
Sure, this seems sensible, especially with the *optional* part.
On Apr 15, 2010, at 3:22 PM, David Recordon wrote:
+1, remember discussing this a week or so ago on the list
On Thu, Apr 15, 2010 at 12:12 PM, Eran Hammer-Lahav > wrote:
Not all the flows return a refresh token for security or
Why do we need to label the requests according to which flow they
belong to?
Apologies if this is a dumb question; haven't read the latest draft.
On Apr 15, 2010, at 1:31 PM, Eran Hammer-Lahav wrote:
I renamed the values of the 'type' parameter as follows:
WC-A: web_callback_access_request
You are make my point. A scope parameter is useless without another
vendor-specific spec in which case the vendor spec can define its own scope
parameter. The argument of library support doesn't hold because libraries must
pass any extension parameter anyway.
If people still want a scope parame
One thing missing from the current access token responses is any indication of
where the token can be used.
This seems potentially dangerous as the token might be included when, say,
following links or redirects from a protected resource.
The solution is probably fairly easy: specify the li
It isn’t clear to me how those options are better for interop than a scope
parameter in the token request.
Also, the proposal forces the protected resource to know the context of the
request and respond with the appropriate URI. This simply won’t work in many
situations. For example, let’s say
By definition the header ABNF is going to limit the allowed characters. There
is no way around that. As of right now, the only problem is with the token
value because the other fit well with the 'token' ABNF. The signature is
already base64 encoded and included as a quoted string.
So the questi
> We will need to choose an encoding method for the header values
Not if we restrict the allowed chars in tokens to a very safe set of ~64 chars.
> and percent-encoding seems to make the most sense
It makes sense in URIs. In HTTP headers, however, I think it is more novel.
There are quoted stri
On 4/15/10 6:09 PM, "James Manger" wrote:
>> I would like to proposal that the spec remains mute on the allowed parameter
>> values
>
> The spec isn't mute.
Yep, but we are not there yet. The ABNF was just copied over from another
draft and not updated yet. We will need to choose an encoding
BTW, making this change includes dropping the client state parameter and
allowing clients to add their own state parameter to the callback.
EHL
On 4/16/10 7:34 AM, "Eran Hammer-Lahav" wrote:
First, this argument only holds for callbacks, not for the authorization
endpoint. Since this problem
I really like it, but it is too complicated and requires a standard template
format (which will need to be profiled to be practical). This is going in the
wrong direction...
EHL
On 4/16/10 7:33 AM, "James Manger" wrote:
A partial solution to colliding parameter names and long URIS would be t
First, this argument only holds for callbacks, not for the authorization
endpoint. Since this problem is easily solved with a simple web server
configuration, I don't think it is as bad as you make it sound. I'm sure that
the Drupal community will find a solution if there are valuable OAuth 2.0
A partial solution to colliding parameter names and long URIS would be to use
URI templates.
For instance, in a 401 response when a client app tries to access a protected
resource, instead of an authz URI, return a template for an authz URI. The
template would include OAuth field names in squ
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
Mark,
> James, how does your proposal work if the client needs access
> to more than one set of resources?
I think a client app will need service-specific knowledge to realise it needs
access to more than one set of resources (ie the app needs to know how the
service divides resources into sets
I know we will control scope server side based on the calling client
I can see why others may want to have a scope parameter though to allow a
client app to decrease the scope they request (assuming short duration
access), e.g. client app is entitled to request contacts and files based on
their c
My point though is why remove the Native app flow and then replace it with
something that relies on having to warn the user about possible phishing
attacks in your UI, like FlickR does. I would find it difficult to get that
approved here in IBM
I must look again at Luke Sheppard's suggestion for c
51 matches
Mail list logo
