Subject: Re: [OAUTH-WG] Draft progress update

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 1 Apr 2010 10:14:05 -0500

Eran,

The progress is good indeed.

I believe that the following comment on the draft applies also to some previous versions of OAuth specifications.

In my opinion, the description of step A of the Web Callback Flow implies that a client

is an HTTP server:

(A)  The web client initiates the flow by redirecting the end user's

        user-agent to the authorization endpoint ...

(If it is the HTTP redirection, then the client has to be an HTTP server).

If an OAuth client has to be an HTTP server in order to participate in OAuth flow, then the draft's definition of client appears to be incomplete:

client

         An HTTP client capable of making authenticated requests for

         protected resources using the OAuth protocol

Should not the definition reflect the fact that client has to be also an HTTP server (which appears to be the case at least for the Web Callback Flow)?

Zachary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, March 31, 2010 9:22 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft progress update

I'm making good progress working off David's draft and bringing text from

WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far

it is largely in line with David's proposal and the majority of changes are

purely editorial.

The only significant change I have made (which is of course open to debate)

is renaming all the authorization flows parameters. I dropped the oauth_

prefix (no real need since these are purely OAuth endpoints, not protected

resources), and made most of the parameter names shorter. I am not done so

they are not consistent yet.

You can follow my progress (changes every few hours) at:

http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth

.txt

Please feel free to comment on anything you like or dislike. I will publish

the whole thing as an I-D once it is feature complete for the WG to discuss

before we promote this to a WG draft.

I hope to be done with the initial draft by middle of next week (I'll be

flying most of Fri-Sat so no progress over the weekend).

EHL

_______________________________________________

OAuth mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 08:32:31 -0700

This is a correct observation but I am not sure if it would be useful to change the definition. The current definition isn't wrong, just (sometimes) incomplete. An OAuth client is an HTTP client speaking OAuth, but for the purpose of obtaining a token using the callback flow, it also has to have HTTP server capabilities. I don't think that voids the current definition.

I'll tweak the wording specific to the callback flow.

EHL

On 4/1/10 8:14 AM, "Zachary Zeltsan" <[email-masked]> wrote:

Eran,

client

Zachary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, March 31, 2010 9:22 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft progress update

EHL

---

From: Justin Smith <[email-masked]>
Date: Thu, 1 Apr 2010 18:06:16 +0000

Eran,

Good progress. A few comments below:

Sec. 2.2.  Flow Parameters:
Comment 1: The recommendation to keep access tokens less than 255 chars seems bizarre. I'd like to remove it entirely. Previous threads have discussed this.

General comment on the flows:
Comment 2: The scope parameter (from WRAP) is missing from all of the flows. How does the client indicate which protected resource it intends to access? In WRAP this was an optional parameter, but it seems important when a single AS controls access to many resources.

Sec. 2.3.  Client Credentials: "When requesting access from the authorization server, the client identifies itself using its authorization-server-issued client credentials."
Comment 3: This isn't the case when the client is presenting a token issued by another server. I suggest a change to something like the following: "When requesting access from the authorization server, the client identifies itself using client credentials known to the authorization server."   

Sec. 2.4.  User Delegation Flows: "Instead, the end user authenticates directly with the authorization server, and grants client access to its protected resources."
Comment 4: This is a minor nit, but the AS may not grant access to all of the PRs it controls access to. I suggest a change to something like the following: "... and grants client access to the requested protected resources."

Sec. 2.6.2.  SAML Assertion Flow: "Since requests to the authorization endpoint result in the transmission of plain text credentials in the HTTP request and response, ..."
Comment 5: In the case of the SAML assertion flow (or an assertion of another format), it isn't necessarily the case that the assertion is plain text. You might want to change it to: "...authorization endpoint may result in the...". 
Comment 6: why is expiration optional in the response? It seems like it should be mandatory (as it is in the other flows).

Sec. 2.6.1 Client Credentials Flow:
Comment 7: Why require a refresh token? Assumedly the client has to keep the client_id and client_secret, so why not just present them to the AS again for an access token? Brian/Marius/Dick brought this up earlier - you just might not have gotten there yet.

--justin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, March 31, 2010 6:22 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft progress update

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 11:37:37 -0700

+1 on all comments, except for some question on 6...

> Comment 6: why is expiration optional in the response? It seems like it should be mandatory (as it is in the other flows).

SAML assertions contain the expiry inside, the OAuth "expires"
parameter would be redundant, maybe this is way it is optional?

But, do we want to make this parameter required in general? Why not
leave it optional for all flows? What if an Authorization Server
implements some other mechanism to expire them (number of uses for
example) and a fixed expiry time does not make sense?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 12:23:20 -0700

Hi Justin,

On 4/1/10 11:06 AM, "Justin Smith" <[email-masked]> wrote:

> Comment 1: The recommendation to keep access tokens less than 255 chars seems
> bizarre. I'd like to remove it entirely. Previous threads have discussed this.

It's marked as an open issue. I personally don't care much either way but
can see the reasons behind those for and against a (short) hard limit.
Experience has shown this is a problem as most libraries assume a certain
size will work just fine and then blow up.

Last time it was debated here it didn't end with a consensus call so feel
free to ask the chairs for one or continue debating it.

> Comment 2: The scope parameter (from WRAP) is missing from all of the flows.
> How does the client indicate which protected resource it intends to access? In
> WRAP this was an optional parameter, but it seems important when a single AS
> controls access to many resources.

I removed it (for now) because it was (way way) under specified. The only
reason for a spec is interop. This parameter hurts interop because it forces
library to implement something they cannot understand, or understand based
on one deployment.

This debate has been going on for a long time and solving it by simply
adding a placeholder for scope without *any* structure or definition is not
how well designed protocols are written.

I have always maintained that OAuth needs a basic facility to negotiate
scope. It can be as simple as an opaque string identifying a set of
resources (e.g. HTTP auth realms), a JSON string of key/value pairs, etc.
But as present in WRAP and imported by David it is utterly useless (it is
and under-specified SHOULD - I am not really sure what it is to be used
for).

Write a proposal and we can add it back.

> Sec. 2.3.  Client Credentials: "When requesting access from the authorization
> server, the client identifies itself using its authorization-server-issued
> client credentials."
> Comment 3: This isn't the case when the client is presenting a token issued by
> another server. I suggest a change to something like the following: "When
> requesting access from the authorization server, the client identifies itself
> using client credentials known to the authorization server."

What token? The authorization endpoint isn't an OAuth-protected resource.
 
> Sec. 2.4.  User Delegation Flows: "Instead, the end user authenticates
> directly with the authorization server, and grants client access to its
> protected resources."
> Comment 4: This is a minor nit, but the AS may not grant access to all of the
> PRs it controls access to. I suggest a change to something like the following:
> "... and grants client access to the requested protected resources."

This isn't the old testament. No need to look for hidden meaning. The spec
is about getting access to protected resources, generally dealing with *a*
protected resource. How resources are segmented is beyond the scope. I think
it is more useful to talk about it using simpler assumptions - it doesn't
prevent the more complex use cases.

> Sec. 2.6.2.  SAML Assertion Flow: "Since requests to the authorization
> endpoint result in the transmission of plain text credentials in the HTTP
> request and response, ..."
> Comment 5: In the case of the SAML assertion flow (or an assertion of another
> format), it isn't necessarily the case that the assertion is plain text. You
> might want to change it to: "...authorization endpoint may result in the...".
> Comment 6: why is expiration optional in the response? It seems like it should
> be mandatory (as it is in the other flows).

I didn't really get to that part yet in my full rewrite - just imported it
with small changes. The new spec has a simple authorization endpoint and it
requires SSL/TLS (or other secure channels). The same applies to this flow.
The assertion might not be plain text but the resulting token is.

> Comment 7: Why require a refresh token? Assumedly the client has to keep the
> client_id and client_secret, so why not just present them to the AS again for
> an access token? Brian/Marius/Dick brought this up earlier - you just might
> not have gotten there yet.

Yep. On my list.

Thanks!

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 12:31:41 -0700

> parameter would be redundant, maybe this is way it is optional?

The token expiration doesn't have to be the same as the assertion.

> example) and a fixed expiry time does not make sense?

The expiration parameter should be optional everywhere. If it is not, its
because I didn't get to it (or messed up).

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 13:02:56 -0700

> The token expiration doesn't have to be the same as the assertion.

Yep, sorry, I got mixed up.

> because I didn't get to it (or messed up).

Sounds great.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 13:21:32 -0700

> Write a proposal and we can add it back.

Except for trivial cases, the client needs to have custom code to access and
process the protected resources. Scopes have meaning only for these
resources and while obtaining an access token I think the scope can be
treated as an opaque string.

There is another issue with removing the scope parameter. In most cases
a scope parameter will be needed in practice, if the spec does not specify
one then an additional non-standard parameter must be used. But you also
dropped the additional parameters.

I don't see why an opaque scope parameter would create any problems
for a library implementation. Working on such an implementation right
now and opaque scopes are perfectly fine.

> prevent the more complex use cases.

I think this ties in with the scope parameter. When requesting authorization,
if a client can also pass a scope parameter, then access is granted only
to the resources that accept that scope and not to all resources controlled
by this Authorization Server.

Marius

---

From: Justin Smith <[email-masked]>
Date: Thu, 1 Apr 2010 22:22:35 +0000

> now and opaque scopes are perfectly fine.

I completely agree. In practice this hasn't caused a problem. We discussed the idea of forcing an absolute URI here and whether it had to be the actual resource URI. That doesn't work when the AS uses the same access policy for multiple resources. Opaque seems like a fine proposal to me.

> What token? The authorization endpoint isn't an OAuth-protected resource.

In the case where you present a SAML (or other format) assertion, it is a kind of a protected resource - the resource is an access token.

> by this Authorization Server.

This is only a minor wording comment, but I think the idea is significant. The assumption that there is a 1:1 mapping between an AS and a PR seems out of place for the spec. It's easy to imagine that a single AS controls access to many resources (photos, friends, address books, etc.) - this is in fact what happens today. 

--justin

---

From: Allen Tom <[email-masked]>
Date: Thu, 01 Apr 2010 17:14:39 -0700

+1 on removing the recommendation to keep the tokens shorter than 255 chars.

While it's certainly a good idea to keep tokens reasonably compact, the same
way it's a great idea to keep URLs and Cookies short, the statement in the
spec doesn't really do much.

In practice, the tokens/urls/parameters need to be short enough such that
the resulting URLs are less than 2KB (to support useragents and proxy
servers that truncate long URLs) and that the HTTP Authorization header is
less than the maximum allowed size (?? chars).

I do acknowledge that it's ideal to specify a size limit on tokens - it
makes life easier for implementers so that they'll be able to size their
databases, and bandwidth/CPU constrained devices (aka mobile) will also
benefit from having compact tokens.

Allen

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Apr 2010 19:59:46 -0600

On 4/1/10 4:22 PM, Justin Smith wrote:
>> I don't see why an opaque scope parameter would create any
>> problems for a library implementation. Working on such an
>> implementation right now and opaque scopes are perfectly fine.
> 
> I completely agree. In practice this hasn't caused a problem. We
> discussed the idea of forcing an absolute URI here and whether it had
> to be the actual resource URI. That doesn't work when the AS uses the
> same access policy for multiple resources. Opaque seems like a fine
> proposal to me.
> 
>>> Comment 3: This isn't the case when the client is presenting a
>>> token issued by another server. I suggest a change to something
>>> like the following: "When requesting access from the
>>> authorization server, the client identifies itself using client
>>> credentials known to the authorization server."
>> 
> In the case where you present a SAML (or other format) assertion, it
> is a kind of a protected resource - the resource is an access token.
> 
>>> This isn't the old testament. No need to look for hidden meaning.
>>> The spec is about getting access to protected resources,
>>> generally dealing with *a* protected resource. How resources are
>>> segmented is beyond the scope. I think it is more useful to talk
>>> about it using simpler assumptions - it doesn't prevent the more
>>> complex use cases.
> 
>> I think this ties in with the scope parameter. When requesting
>> authorization, if a client can also pass a scope parameter, then
>> access is granted only to the resources that accept that scope and
>> not to all resources controlled by this Authorization Server.
> 
> This is only a minor wording comment, but I think the idea is
> significant. The assumption that there is a 1:1 mapping between an AS
> and a PR seems out of place for the spec. It's easy to imagine that a
> single AS controls access to many resources (photos, friends, address
> books, etc.) - this is in fact what happens today.

If that's true, then how does the Authorization Server know what scope
is appropriate at the Protected Resource? Does inclusion of the scope
parameter require a 1:1 mapping between AS and PR, or at least
communication between AS and PR?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Allen Tom <[email-masked]>
Date: Thu, 01 Apr 2010 19:21:43 -0700

The way we do this at Yahoo is that the developer must indicate what scopes
they want to access when registering for a client_identifier/secret.

Although we've done it this way for several years, we've gotten plenty of
feedback that client developers want the flexibility to specify the scopes
at user authorization time.

Allen

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Apr 2010 21:13:17 -0600

> at user authorization time.

OK, so the scope is something that the [developer of a] Client
establishes beforehand with the Authorization Service. But that still
doesn't tell us what a scope is. Does someone have a definition?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Luke Shepard <[email-masked]>
Date: Thu, 1 Apr 2010 21:07:30 -0700

On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote:

My preferred way of handling this is to have the Protected Resource throw a 403 Forbidden error, with an error message that specifies the scope needed - e.g., "oauth_scope_required=photo_read".

So an app that tries to access a protected resource should be able to programatically take the scope in the error message and then construct an OAuth authorization request to get that permission from the user. Even if the scope is totally opaque, it should still be possible for a library to handle them in this way.

I believe David or Eran were thinking of writing this into the spec?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 21:14:51 -0700

> doesn't tell us what a scope is. Does someone have a definition?

There isn't one - its service specific.

The easy ones are:

Duration
List of protected resources, URI wildcard, or name of protected segment
Read/write access or HTTP methods

3 years ago when we dropped the scope/token_attributes parameter from the
spec we decided to bring it back when we have enough deployment experience.
I strongly believe this rule still holds.

It would be great if those with OAuth 1.0a deployments can share how they
specify scope.

EHL

---

From: Allen Tom <[email-masked]>
Date: Thu, 01 Apr 2010 21:21:52 -0700

+1

How about if the Protected Resource returns an HTTP 302 redirect to the Auth
URL? The scope information can be encoded in the URL.

Allen

On 4/1/10 9:07 PM, "Luke Shepard" <[email-masked]> wrote:

> My preferred way of handling this is to have the Protected Resource throw a
> 403 Forbidden error, with an error message that specifies the scope needed -
> e.g., "oauth_scope_required=photo_read".
> 
> So an app that tries to access a protected resource should be able to
> programatically take the scope in the error message and then construct an
> OAuth authorization request to get that permission from the user. Even if the
> scope is totally opaque, it should still be possible for a library to handle
> them in this way.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 21:25:05 -0700

> I believe David or Eran were thinking of writing this into the spec?

How is this any better/different than plain old 401 with realm='something'.
Why not have the client request a token capable of accessing the realm
specified?

Before we go and invent a new mechanism that has exactly the same limited
capabilities, we should see if the existing one can be reused or improved
upon.

EHL

---

From: Luke Shepard <[email-masked]>
Date: Thu, 1 Apr 2010 21:48:06 -0700

Sure, I don't care about the exact mechanism - although "realm" and "scope" don't seem equivalent concepts.

Allen - I don't think a redirect is what we want, since the Protected Resource is typically server-to-server, or if done in a browser then it's not in a user-visible screen.

---

From: David Recordon <[email-masked]>
Date: Thu, 1 Apr 2010 22:46:23 -0700

401 seems more semantically correct, but I'm sure Eran knows the true answer. :)

+1 to this idea though. Helps client dynamically authorize users if it
turns out they didn't ask for the right scope.

On Thu, Apr 1, 2010 at 9:21 PM, Allen Tom <[email-masked]> wrote:
> OAuth authorization request to get that permission from the user. Even if
> the scope is totally opaque, it should still be possible for a library to
> handle them in this way.
>
> ________________________________

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 02 Apr 2010 11:18:25 +0200

The OAuth implementation at Deutsche Telekom uses a non-standard 
parameter "serviceId" to identity the protected resource the client 
wants to access. The client passes such an id as parameter when 
requesting a token. The authorization server knows all services it 
issues tokens for. The service id is used to
- constucts the screen for user consent
- create a token with the content required at that particular service.

I would vote for a similar parameter as part of the standard. So far, I 
have seen the "scope" parameter that way.

regards,
Torsten.

> On 4/1/10 6:59 PM, "Peter Saint-Andre"<[email-masked]>  wrote:
>
>    
>>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 2 Apr 2010 11:21:36 -0700

Hi Eran,

A few more comments:

1. Only one endpoint. While I think collapsing the access token and
refresh token URLs into one URL was a good think, keeping the user
authorization as a separate URL could be beneficial. I think there
should be 2 endpoints defined: access token and user authorization.
Calls to the access token endpoint are alway direct calls and
restricted to HTTPS and POST, and with many frameworks this can be
enforced through configuration. The user authorization endpoint is
always accessed with a browser.

2. Section 2.1: "The authorization endpoint advertised by the server
MUST NOT include a query or fragment components as defined by
[RFC3986] section 3." Why do we disallow query parameters? If we want
to enforce strict matching of callback URLs maybe we should just
demand that.

3. Section 2.2: "The values of the request and response parameters
defined in this section MUST only contain the following characters". I
asked in another thread what is the reason behind this limitation. Why
not any UTF-8 string?

4. Section 2.4.1.1: "The client directs the end user to the
constructed URI using an HTTP redirection response, or by other means
available to it via the end user's user-agent. The request MUST use
the HTTP "GET" method." Why do we enforce GET?

5. Section 2.4.2. Web Client Flow combines both rich app and
JavaScript flows. It think the two flows should be treated separately.

For the rich apps the flow should include a verification code step,
similar to Web Client Flow. Also, in this case the callback URL should
be optional and if not present the authorization server must display a
page with instructions and a special title.

For the JavaScript flow, the presence of an empty fragment in the
callback URL is a signal that the response should be put there? Can we
make it mandatory that the response always goes to the fragment? It is
not defined how is the response supposed to be encoded into the
fragment. I assume that also URL encoded, but it should be specified.

6. Sections 4.1.2 and 4.1.3, the parameter name should probably be
oauth_access_token.

7. Section 4.2, shouldn't we require a "version" parameter with value "2.0"?

Thanks,
Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 03 Apr 2010 10:25:12 +0200

You are right, there are different aspects of scope. Why not define one 
optional parameter per scope aspect?

Based on our experiences with implementing OAuth 1.0a at Deutsche 
Telekom, I see the need for the following parameters
- resource: specification of the protected resource to be accessed 
(type: URI or opaque string)
- requested permissions:  permissions on this resource the client want 
to get authorized by the user (comma-separated list of opaque strings). 
The range of permissions is defined by the resource as part of its API 
design. This could be something like "upload", "download", "sent", or 
"establish connection". The set of available permissions might be 
advertised by way of a WWW-Authenticate parameter (status code 401), as 
part of a 403 response, or in a XRDS discovery process.
- requested duration: specification of the token duration the client 
asks for

regards,
Torsten.
> ...

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Apr 2010 21:29:17 +0200

> My preferred way of handling this is to have the Protected Resource throw a 403 Forbidden error, with an error message that specifies the scope needed - e.g., "oauth_scope_required=photo_read".

Here is a bit of Kerberos-lore: it is sometimes important to
protect your error messages too!

When you pass critical parameters ("you need this scope for
access"), the error message suddenly becomes something
you may have to protect.

	Cheers Leif

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Apr 2010 00:14:58 -0700

I agree that this is the right approach (separate parameters to well defined
scope attributes). However, so far the only well-defined attribute is a
protected segment name (aka realm).

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 06 Apr 2010 12:23:19 +0200

Hi Eran,

> protected segment name (aka realm).
how shall we proceed in order to come to more well-defined attributes? I 
already proposed some, can we discuss them?

regards,
Torsten.
> EHL
>
>
> On 4/3/10 1:25 AM, "Torsten Lodderstedt"<[email-masked]>  wrote:
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Apr 2010 14:30:39 -0700

Like anything else, we need proposed text to discuss. Discussing a list of attributes is rarely practical. Discussing a concrete proposal usually works...

EHL

On 4/6/10 3:23 AM, "Torsten Lodderstedt" <[email-masked]> wrote:

Hi Eran,

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 6 Apr 2010 16:06:40 -0700

On Mon, Apr 5, 2010 at 11:56 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Hey Marius,
>
> Detailed replies inline but I think most of these can be answered by the
> fact that we are still getting outside feedback that says OAuth is still
> complicated and has too many options / things left open to each
> implementation.
>
> My goal with any limitation added was to increase interop. If something
> doesn't increase inteop, I agree we should remove it.

I'm all for simplification. Do we have a clear definition for interop?
I think it is clear that 100% interop cannot be achieved in all areas.

> On 4/2/10 11:21 AM, "Marius Scurtescu" <[email-masked]> wrote:
>
> I'm trying to simplify configuration and reduce the need for complex
> discovery. I am not sure what the benefits of keeping them different are.
> Can you elaborate?

Sure.

Constraints for endpoints:
access token URL: HTTPS and POST only, no user
user authentication URL: HTTP or HTTPS, GET or POST, authenticated user

In many cases the above constraints can be enforced with configuration
that sits in front of the controllers implementing these endpoints.
For example, Apache config can enforce SSL and POST. Same can be done
in a Java filter. Also a Java filter can enforce that only
authenticated users hit the endpoint, it can redirect to a login page
if needed.

By keeping two different endpoints all of the above is much simpler.
Nothing prevents an authz server to collapse these two into one
endpoint.

> I don't like having both custom query and a state parameter. If servers have
> to accommodate custom queries, then we might as well drop the special state
> parameter since clients can just make up whatever they want. I opted to use
> the state parameter because it makes pre-registering URIs easier, and it
> doesn't cause parameter namepsace conflicts (which is still an open issue).

I think I got mixed up a bit. The authorization server endpoints
should be allowed to have query parameters. No state is passed through
these, and also no matching done against them.

Registered callback URLs for clients should also be allowed to have
query parameters. If strict matching is enforced, at least for the
query part, then no state that can be passed, so they have to use the
state parameter. Parameter namespace can be an issue, one more reason
to keep the prefix :-)

> I marked this as an open issue. We need to figure out signatures first to
> deal with this. If the signature flow will be simple enough, we can/should
> drop this limitation.

If we end up keeping this limitation, how do you see clients and authz
servers dealing with this requirement? Don't you think this will lead
to real interop issues?

I think it is much better to not rely on this limitation at all when
looking at signatures.

> First, to stay consistent across a redirection (3xx) and something else
> (such as a button press with a form).

Yes, dealing with redirects could be an issue. Not sure how well
supported are POSTs and redirects. But on the other hand, I think it
is OK to require authz servers to support POST.

> Second, we need to guarantee interop
> which means at a minimum we must require the server to accept GET. I don't
> think making this a server requirement instead of a client one that
> beneficial.

It think we should rather require servers to support POST, that seems
the more difficult case.

> Didn't get to it. Care to suggest text or point me where to copy it from?

See "6.3.  Rich App Profile" in attached draft-hardt-oauth-01.

Marius

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 8 Apr 2010 23:11:48 -0700

> state parameter. Parameter namespace can be an issue, one more reason

+1 on callback URLs and authorization server being allowed to have query
parameters.

Callback URLs might be a page on an existing web site, and we will be
limiting the usefulness of the Web & User-Agent profile if we disallow these
pages to have query parameters.

Authorization server is probably less necessary, but don't see any good
reason to restrict.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Apr 2010 00:32:41 -0700

> +1 on callback URLs and authorization server being allowed to have query

Nothing in the spec prevents the authorization endpoint from including
extensions. Right now the spec is silent on how extensions work which means
the server developer has to be careful in adding new parameters and should
probably prefix them with their company name or some other prefix to ensure
they will not conflict with the core parameters and standard extensions. I
also rather make it less appealing to extend the authorization endpoint
because each such custom extension (not published as a standard) reduces
interoperability.

Callback URIs support client state which accomplishes *exactly* the same
thing, but with full and trivial client support. So the feature is there,
now we are just arguing over style.

> Callback URLs might be a page on an existing web site, and we will be limiting
> the usefulness of the Web & User-Agent profile if we disallow these pages to
> have query parameters.

Its trivial to add an endpoint that takes a callback and redirects it
internally to the existing endpoint.

> Authorization server is probably less necessary, but don't see any good reason
> to restrict.

Its not.

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 9 Apr 2010 07:37:16 -0700

> limiting

Not trivial to do this. That callback adds latency and more importantly
requires all clients do the proper redirect URL enforcement. Proper redirect
enforcement is an essential security characteristic, and a small bug in URL
parsing means that you've created an open redirector (for example, checking
that the URL prefix is "http://www.mysite.com" would be a bug, because
attackers could use "http://www.mysite.com:[email-masked]/".

What is the benefit we get from the restriction on callback URL parameters?
It's not clear to me why we want this restriction in the first place.

> reason

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 9 Apr 2010 07:43:30 -0700

> attackers could use "http://www.mysite.com:[email-masked]/".

As a bonus, all of the redirect validation logic will need to be possible in
JavaScript for the User-Agent profile.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Apr 2010 10:43:40 -0700

I'm opposed to having both any parameters and a state parameter. Pick one. OAuth 1.0a allowed any client-specific parameter in the callback. The argument for adding a state parameter was to increase interop but that is only true if it comes instead of custom parameters.

EHL

On 4/9/10 7:37 AM, "Evan Gilbert" <[email-masked]> wrote:

On Fri, Apr 9, 2010 at 12:32 AM, Eran Hammer-Lahav <[email-masked]> wrote:

Not trivial to do this. That callback adds latency and more importantly requires all clients do the proper redirect URL enforcement. Proper redirect enforcement is an essential security characteristic, and a small bug in URL parsing means that you've created an open redirector (for example, checking that the URL prefix is "http://www.mysite.com" would be a bug, because attackers could use "http://www.mysite.com:[email-masked]/".

What is the benefit we get from the restriction on callback URL parameters? It's not clear to me why we want this restriction in the first place.

Its not.

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 9 Apr 2010 14:09:07 -0700

On Fri, Apr 9, 2010 at 10:43 AM, Eran Hammer-Lahav <[email-masked]>wrote:

>  I’m opposed to having both any parameters and a state parameter. Pick
> one. OAuth 1.0a allowed any client-specific parameter in the callback. The
> argument for adding a state parameter was to increase interop but that is
> only true if it comes instead of custom parameters.
>

We definitely need to support existing URL parameters - I don't see any
solution for the latency and security issues brought up in the previous
email.

I don't know the additional use cases for client state beyond the URL -
possibly this requirement can move.

Possibly some of the folks who initially proposed client state can give
context as to why this might be different than URL parameters.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 10 Apr 2010 09:07:38 +0200

(+1) pro any client-specific parameters

That's the way OAuth 1.0a and OpenId 2.0 handle it, why deviate?

Am 09.04.2010 19:43, schrieb Eran Hammer-Lahav:
> I'm opposed to having both any parameters and a state parameter. Pick 
> one. OAuth 1.0a allowed any client-specific parameter in the callback. 
> The argument for adding a state parameter was to increase interop but 
> that is only true if it comes instead of custom parameters.
>
> EHL
>
>
>     Not trivial to do this. That callback adds latency and more
>     importantly requires all clients do the proper redirect URL
>     enforcement. Proper redirect enforcement is an essential security
>     characteristic, and a small bug in URL parsing means that you've
>     created an open redirector (for example, checking that the URL
>     prefix is "http://www.mysite.com" would be a bug, because
>     What is the benefit we get from the restriction on callback URL
>     parameters? It's not clear to me why we want this restriction in
>     the first place.
>
>