Re: [OAUTH-WG] Issue: Scope parameter

> So, let’s say there is an Authorization Server available at http://as.com and > it protects the http://foo.com and http://bar.com resources. > A client requests http://foo.com. The foo.com server responds with a > WWW-Auth that contains the http://as.com URI. The client then sends an access

Re: [OAUTH-WG] Issue: Scope parameter

On Thu, Apr 15, 2010 at 9:31 PM, Justin Smith wrote: > Great. > > > > So, let’s say there is an Authorization Server available at http://as.com > and it protects the http://foo.com and http://bar.com resources. > > > > A client requests  http://foo.com. The foo.com server responds with a > WWW-Aut

Re: [OAUTH-WG] Issue: Scope parameter

Great. So, let’s say there is an Authorization Server available at http://as.com and it protects the http://foo.com and http://bar.com resources. A client requests http://foo.com. The foo.com server responds with a WWW-Auth that contains the http://as.com URI. The client then sends an access t

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

On Thu, Apr 15, 2010 at 6:39 PM, Evan Gilbert wrote: > > On Thu, Apr 15, 2010 at 6:31 PM, Marius Scurtescu > wrote: >> >> OK, here is a concrete example: >> >> A Drupal (popular PHP based CMS) based web site wants to become an >> OAuth 2 client. Among other things it needs to implement a callback

Re: [OAUTH-WG] Issue: Scope parameter

> Is it important for an Authorization Server to be able to protect multiple > resources? YES > If so, how should the client specify which resource it intends to access (it > seems like that is required)? By redirecting the user to an authz URI that represents the intended resource.

Re: [OAUTH-WG] Issue: Scope parameter

I get the point, but I’ll set that aside for a moment. Is it important for an Authorization Server to be able to protect multiple resources? If so, how should the client specify which resource it intends to access (it seems like that is required)? From: oauth-boun...@ietf.org [mailto:oauth-boun

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 > a user, another for direct client calls. I agree. > > I agree with Marius that these two endpoints are different enough to be > separate. > One is only used by

Re: [OAUTH-WG] Issue: Scope parameter

> I don’t see how the presence of a scope parameter hurts interoperability. Scopes so far have all been specific to a specific service. Knowing how Google uses ‘scope’ tells you nothing about interoperating with Microsoft. Requesting access to specific sets of resources is important. However

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

On Thu, Apr 15, 2010 at 6:31 PM, Marius Scurtescu wrote: > OK, here is a concrete example: > > A Drupal (popular PHP based CMS) based web site wants to become an > OAuth 2 client. Among other things it needs to implement a callback > endpoint. > > Ideally this endpoint would look something like: >

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

OK, here is a concrete example: A Drupal (popular PHP based CMS) based web site wants to become an OAuth 2 client. Among other things it needs to implement a callback endpoint. Ideally this endpoint would look something like: http://example.com/oauth/back Depending on what web server is used and

Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

I strongly favour specifying 2 separate endpoints: one for where to redirect a user, another for direct client calls. I agree with Marius that these two endpoints are different enough to be separate. One is only used by users via browsers. The other is only used by client apps. These are differ

Re: [OAUTH-WG] Issue: restriction on values characters

> I would like to proposal that the spec remains mute on the allowed parameter > values The spec isn't mute. Currently, the draft spec uses HTTP's 'token' production for the value of an access token. Perhaps not surprising given the names. The ABNF for HTTP's 'token' allows only 89 characters. I

Re: [OAUTH-WG] Issue: Scope parameter

I don't see how the presence of a scope parameter hurts interoperability. It think scope needs to be a 1st class citizen in the spec, not an extension. Without it, a client cannot request access to a specific set of resources (whether its represented as a string, URI, or anything else). Does the

Re: [OAUTH-WG] Native applications capable of handling callbacks

Thanks for the response Eran, that helps clarify things. I'm hoping to have some in-person discussions with some Googlers tomorrow to hopefully sort out the technical details of these flows. Will report back to the list with any findings. -Original Message- From: Eran Hammer-Lahav [mail

Re: [OAUTH-WG] Rename callback => callback_uri

How about oauth_callback? Marius On Thu, Apr 15, 2010 at 2:41 PM, Luke Shepard wrote: > We already had one developer try it out and get confused because the server > tried to treat the callback URL as a JSONP callback. > > > > The protected resource typically accepts “callback” as a parameter

Re: [OAUTH-WG] Rename callback => callback_uri

We already had one developer try it out and get confused because the server tried to treat the callback URL as a JSONP callback. The protected resource typically accepts "callback" as a parameter to support JSONP. If a developer accidentally passes in callback there (maybe they got confused) th

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

On Apr 15, 2010, at 3:15 PM, Marius Scurtescu wrote: > I really think we should keep a standard parameter prefix like > "oauth_". What are the issue with having a prefix? I think the downside is the extra bytes on the wire. The upside is that this might prevent accidental collision with OAuth p

Re: [OAUTH-WG] Issue: Scope parameter

Even put it on the wiki (http://wiki.oauth.net/) if you don't want to deal with IETF formatting yet. Eran and I are happy to clean stuff up. :) On Thu, Apr 15, 2010 at 12:51 PM, Eran Hammer-Lahav wrote: > 1. Write it > 2. Comply with naming policy of new parameters* > 3. Publish and get feedback

Re: [OAUTH-WG] Issue: Scope parameter

1. Write it 2. Comply with naming policy of new parameters* 3. Publish and get feedback. 4. Fix and repeat #3 as needed. 5. Register new parameter name* :-) * Pending new parameter name policy For now just call it 'scope'. EHL On 4/15/10 12:38 PM, "Marius Scurtescu" wrote: Sure. Do we have

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

On 4/15/10 12:36 PM, "Marius Scurtescu" wrote: > On Thu, Apr 15, 2010 at 12:27 PM, Eran Hammer-Lahav > wrote: >> >> On 4/15/10 12:15 PM, "Marius Scurtescu" wrote: >> >>> I really think we should keep a standard parameter prefix like >>> "oauth_". What are the issue with having a prefix? >>

Re: [OAUTH-WG] Issue: Scope parameter

Sure. Do we have a mechanism to define extensions? Marius On Thu, Apr 15, 2010 at 12:26 PM, David Recordon wrote: > Marius, why don't we write a one page spec which defines scope as an > extension? We end up with agreement around if scope is a useful > parameter and a simple parameter name for

Re: [OAUTH-WG] Issue: specificity of the assertion flow

Not at all...the submission is largely focused on the generic assertion flow. It simply adds additional detail to the current text, and clarifies/corrects some of the expected usage patterns. There is a SAML profiling of the flow at the end of the submission, but it's a small percentage of wh

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

On Thu, Apr 15, 2010 at 12:27 PM, Eran Hammer-Lahav wrote: > > On 4/15/10 12:15 PM, "Marius Scurtescu" wrote: > >> I really think we should keep a standard parameter prefix like >> "oauth_". What are the issue with having a prefix? > > I really think we shouldn't. :-) > > Requests are longer for

Re: [OAUTH-WG] Issue: Scope parameter

Don't they need to pass any other extension parameter around too? What makes this one so special? EHL On 4/15/10 12:20 PM, "Marius Scurtescu" wrote: I still have not seen any arguments why scope structure is needed for interop. Client and server side libraries do not need to understand the sc

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

On Thu, Apr 15, 2010 at 12:22 PM, David Recordon wrote: > I thought we already settled this (though am having a hard time > finding the specific thread).  Either we spec for interop or for > vendors being able to twist the spec in their own ways. I vote for > interop. :) Lost you. Where do I argu

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

On 4/15/10 12:15 PM, "Marius Scurtescu" wrote: > I really think we should keep a standard parameter prefix like > "oauth_". What are the issue with having a prefix? I really think we shouldn't. :-) Requests are longer for no reason. You need to show how a prefix actually helps. Otherwise, it

Re: [OAUTH-WG] Issue: Scope parameter

Marius, why don't we write a one page spec which defines scope as an extension? We end up with agreement around if scope is a useful parameter and a simple parameter name for multiple vendors (because it is an extension). Since you seem to be advocating for including scope the most, would you mind

Re: [OAUTH-WG] Issue: add refresh token as optional in all access token requests

+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 practicality > reasons. Adding refresh token as optional in all access token requests is > required to enable upgrading a

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

I thought we already settled this (though am having a hard time finding the specific thread). Either we spec for interop or for vendors being able to twist the spec in their own ways. I vote for interop. :) On Thu, Apr 15, 2010 at 12:15 PM, Marius Scurtescu wrote: > I really think we should kee

Re: [OAUTH-WG] Issue: Scope parameter

I still have not seen any arguments why scope structure is needed for interop. Client and server side libraries do not need to understand the scope, they just pass it around. Client and server code do need to understand the scope, but we are not dealing with that. Yes, a scope parameter does not b

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

Hey John, On 4/15/10 12:08 PM, "John Kemp" wrote: > Hello, > > On Apr 15, 2010, at 2:27 PM, Eran Hammer-Lahav wrote: > >> OAuth 2.0 flows use a single authorization endpoint (with 'type' parameter). >> This endpoint is OAuth-specific but must allow for extension parameters >> (standard or ven

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

I really think we should keep a standard parameter prefix like "oauth_". What are the issue with having a prefix? Not having such a prefix will lead to collisions with query parameter on the authz server endpoints or on the callback URL. Even if state is not passed with additional parameters on ca

[OAUTH-WG] Issue: add refresh token as optional in all access token requests

Not all the flows return a refresh token for security or practicality reasons. Adding refresh token as optional in all access token requests is required to enable upgrading a token to a token with secret. It also can make the spec slightly shorter by not having to repeat all the parameters. We nee

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

Hello, On Apr 15, 2010, at 2:27 PM, Eran Hammer-Lahav wrote: > OAuth 2.0 flows use a single authorization endpoint (with 'type' parameter). > This endpoint is OAuth-specific but must allow for extension parameters > (standard or vendor-specific). > > The issue is how to best allow for extensions

[OAUTH-WG] Issue: Scope parameter

WRAP includes a loosely defined scope parameter which allows for vendor-specific (and non-interoperable) use cases. This was requested by many working group members to be included in OAuth 2.0 with the argument that while it doesn't help interop, it makes using clients easier. The problem with a g

Re: [OAUTH-WG] Issue: specificity of the assertion flow

If I recall correctly, it doesn't define the format parameter, just gives one fixed value for the SAML flow. Either way, I am suggesting we keep the SAML flow out of the spec, keeping just the general assertion flow, with better format definition. EHL On 4/15/10 11:55 AM, "Chuck Mortimore" w

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

We can setup a wiki page as a starting point while people wait for the IANA registry. EHL On 4/15/10 11:48 AM, "record...@gmail.com" wrote: I think there will be a warming up period though as vendors prototype with parameters before any sort of registry is setup. This should be manageable giv

Re: [OAUTH-WG] Issue: specificity of the assertion flow

+1. Did anyone have a chance to review the proposal I made here?I have a couple of people from the SAML community reviewing it offline, but would welcome feedback from this group. The sample text is attached to this post: http://www.ietf.org/mail-archive/web/oauth/current/msg01735.html O

[OAUTH-WG] Issue: 'username' parameter proposal

Evan Gilbert proposed a 'username' request parameter to allow the client to limit the end user to authenticate using the provided authorization server identifier. The proposal has not been discussed or supported by others, and has not received a security review. Proposal: Obtain further discussion

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

I think there will be a warming up period though as vendors prototype with parameters before any sort of registry is setup. This should be manageable given that we have a fairly small community right now working on the spec. On Thu, Apr 15, 2010 at 11:46 AM, Eran Hammer-Lahav wrote: > Me too. I t

Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

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

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

Me too. I think a vendor-name prefix will work just fine. By definition anything with a prefix-period will be defined as vendor-specific and not for interop. As long as we keep the registration lightweight people should register new parameters and increase interop. EHL On 4/15/10 11:37 AM, "r

[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. 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. -

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

I prefer no extension URIs since they make requests longer and really have never taken off in OpenID. On Thu, Apr 15, 2010 at 11:27 AM, Eran Hammer-Lahav wrote: > OAuth 2.0 flows use a single authorization endpoint (with 'type' parameter). > This endpoint is OAuth-specific but must allow for ext

[OAUTH-WG] Issue: Authorization endpoint parameter extension policy

OAuth 2.0 flows use a single authorization endpoint (with 'type' parameter). This endpoint is OAuth-specific but must allow for extension parameters (standard or vendor-specific). The issue is how to best allow for extensions defining new parameters. The danger is common parameter names ('scope',

[OAUTH-WG] Issue: specificity of the assertion flow

The assertion flow included in the specification doesn't offer enough to provide interop. Previous discussions ruled out the idea of offering a single SAML 2.0 based flow. Proposal: Leave the flow as a generic assertion flow, using SAML 2.0 as an example, and defining the syntax/values of the form

Re: [OAUTH-WG] Issue: restriction on values characters

I trust your experience here, so +1. On Thu, Apr 15, 2010 at 10:56 AM, Eran Hammer-Lahav wrote: > Given the current proposal for signatures (no parsing of the request URI or > body, or any encoding), I would like to proposal that the spec remains mute > on the allowed parameter values. > > While

[OAUTH-WG] Issue: restriction on values characters

Given the current proposal for signatures (no parsing of the request URI or body, or any encoding), I would like to proposal that the spec remains mute on the allowed parameter values. While it is best to issue values that do not require any encoding (or decoding when receiving a token response),

Re: [OAUTH-WG] Native applications capable of handling callbacks

On 4/14/10 10:32 AM, "Luke Shepard" wrote: > Sorry, I missed this thread. It dovetails with my objections raised in the > other thread (³Combining the native application and user-agent flows²) > > The question of whether OAuth should support custom URL protocols seems a bit > academic. In pr

[OAUTH-WG] Twitter @anywhere

Side note to the standards process, but I thought people would be interestedthe new Twitter @anywhere framework seems to be an early variant of the User-Agent flow: https://oauth.twitter.com/2/authorize?oauth_callback_url=http%3A%2F%2Ftheoddbit.com%2Fatanywhere%2F&oauth_mode=flow_web_client&

[OAUTH-WG] Shorter authorization endpoint type names

I renamed the values of the 'type' parameter as follows: WC-A: web_callback_access_request WC-T: web_callback_token_request NA-A: native_app_access_request NA-T: native_app_token_request UA-A: user_agent_request DV-A: device_access_request DV-T: device_token_request UP-T: username_password_request

Re: [OAUTH-WG] Combining the Native application and User-agent flows

On Thu, Apr 15, 2010 at 6:53 AM, Mark Mcgloin wrote: >> On 15/04/2010 07:52, Brian Eaton wrote: > >>> As a security person, I'm hesitant to bring this up, but perhaps the > Device >>> Flow should just be the flow for native client apps. > >>I'm open to this. > >>For native apps: the native app ca

Re: [OAUTH-WG] Process / timeline for OAuth 2.0

Thanks for the responses - they were very helpful. On Thu, Apr 15, 2010 at 5:12 AM, Eran Hammer-Lahav wrote: > > > > On 4/15/10 12:04 AM, "Evan Gilbert" wrote: > > > - What does it mean to have successive drafts? And if we move an issue to > the > > next draft, what does that practically mean? >

Re: [OAUTH-WG] Combining the Native application and User-agent flows

> On 15/04/2010 07:52, Brian Eaton wrote: >> As a security person, I'm hesitant to bring this up, but perhaps the Device >> Flow should just be the flow for native client apps. >I'm open to this. >For native apps: the native app can open a web browser with the device >code on the URL. The code

Re: [OAUTH-WG] Combining the Native application and User-agent flows

I worked off that text and the main issue with it is that it is just a developer guide, not a spec. Every implementation can be completely different. The proposed text is basically making some choices. EHL On 4/14/10 9:17 PM, "Chuck Mortimore" wrote: I believe this is basically how the draft

Re: [OAUTH-WG] Combining the Native application and User-agent flows

On 4/14/10 5:23 PM, "Marius Scurtescu" wrote: > The client_secret would have to be optional then. This may be needed > anyhow to support an "unregistered" Web Callback flow. > > Also, the callback URL may need to be optional, because some native > apps cannot receive a callback. The Authz Ser

Re: [OAUTH-WG] Rename callback => callback_uri

I don't think it is that confusing. Its a completely different context from where JSON-P is used (note that in the User-Agent flow it is called something else). EHL On 4/10/10 12:35 PM, "Naitik Shah" wrote: With the simplified params, the callback url parameter is now just "callback". Since

Re: [OAUTH-WG] OAuth Interim Meeting

On 4/14/10 10:58 PM, "Eliot Lear" wrote: > 1.  Could we have remote participation so that those of us who are unable to > travel can join? Setting up a jabber room is trivial. An audio channel is harder but we can try. > 2.  Can you confirm that OAUTH will meet in Maastricht, and that the

Re: [OAUTH-WG] Process / timeline for OAuth 2.0

On 4/15/10 12:04 AM, "Evan Gilbert" wrote: > - What does it mean to have successive drafts? And if we move an issue to the > next draft, what does that practically mean? > - How does the bill become a law? Drafts are numbered but not versioned and they are not reference-able. They expire afte

[OAUTH-WG] Standardisation of a Java API

Hi all, I'm interested in working with other Java programmers to develop a standardised API for OAuth 2.0. I have reviewed the recent archives, but don't see anything in the way of discussion on this topic. If anyone can point me to a location where it is being discussed I'd be grateful. I thi

Re: [OAUTH-WG] Process / timeline for OAuth 2.0

At 00:04 15-04-10, Evan Gilbert wrote: I've been participating in the OAuth 2.0 discussions, but realized I don't know how the process is supposed to work for getting successive drafts and getting to an agreed upon spec and if we have a rough timeline. The "Informal Guide" didn't help that mu

[OAUTH-WG] Process / timeline for OAuth 2.0

I've been participating in the OAuth 2.0 discussions, but realized I don't know how the process is supposed to work for getting successive drafts and getting to an agreed upon spec and if we have a rough timeline. The "Informal Guide " didn't help that