Subject: [OAUTH-WG] Draft -07 (major rewrite)

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 11 Jun 2010 13:11:19 -0700

Draft -07 represents a major rearrangement of the document. I still have a lot of work to do but wanted to share my progress and get some general feedback. The draft includes a few normative language changes but the main focus is on the document structure and how the architecture is explained.

Changes include:

   o  Removed device profile.
   o  Added verification code support to user-agent flow.
   o  Removed multiple formats support, leaving JSON as the only format.
   o  Changed assertion "assertion_format" parameter to "assertion_type".
   o  Removed "type" parameter from token endpoint.

The spec is now 36 pages, 19 pages shorter than -05.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 11 Jun 2010 13:47:54 -0700

>   o  Removed "type" parameter from token endpoint.

It would be really useful if each request had a unique type, now we
are back to guessing what is requested, like in WRAP.

One small error that I noticed: section "5.1.4.  Refresh Token" is not
listing client_id and client_secret as optional parameters.

In general I found previous versions much easier to read and
understand, but maybe I just need more time...

Marius

---

From: Justin Richer <[email-masked]>
Date: Fri, 11 Jun 2010 17:05:01 -0400

I agree with Marius: I think we should keep the explicit flow name in
there (in the 'type' parameter or equivalent), as it (among other
things) opens the possibility for the rescope and revoke operations. It
makes it very clear how both client and server expect things to behave.

 -- Justin

On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Christian Scholz <[email-masked]>
Date: Fri, 11 Jun 2010 23:24:10 +0200

Hi!

> are back to guessing what is requested, like in WRAP.

I am just wondering why having a separate endpoint for this isn't
enough. I would rather map another library call to another endpoint
instead of relying on guessing on the contents. That's why we have
separate endpoints, I guess.

(I might be missing something though)

-- Christian

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge GmbH                              blog: http://mrtopf.de/blog
Hanbrucher Str. 33                                       Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail [email-masked]
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

Podcasts:
Der OpenWeb-Podcast (http://openwebpodcast.de)
Data Without Borders (http://datawithoutborders.net)
Politisches: http://politfunk.de/
Technical: http://comlounge.tv/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 11 Jun 2010 14:25:30 -0700

It doesn't really. It is completely clear what kind of authorization grant the client is providing simply by looking at the parameter. It might make the code a few lines longer (a few if-else instead of a switch-case) but because these are all post parameters, you access them the same way (i.e. this is not a case where header information is moved to post body, etc.).

As for the rescope and revoke operations, we still need to figure out how to accomplish that. For example, revoking can be done using an HTTP DELETE operation which is more consistent with HTTP, and rescoping (which is still tricky because scope can only be decreased) is more a function of a refresh operation (asking for a new access token using a refresh token and simply providing a new, lesser scope).

EHL

On 6/11/10 2:05 PM, "Justin Richer" <[email-masked]> wrote:

 -- Justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 11 Jun 2010 14:32:41 -0700

On 6/11/10 1:47 PM, "Marius Scurtescu" <[email-masked]> wrote:

>> Draft -07 represents a major rearrangement of the document. I still have a
>> lot of work to do but wanted to share my progress and get some general
>> feedback. The draft includes a few normative language changes but the main
>> focus is on the document structure and how the architecture is explained.
>> 
>> Changes include:
>> 

You are always requesting an access token. What you probably mean is what
kind of authorization grant the client is presenting, which I think is
pretty obvious from, well, what the client is presenting...

> listing client_id and client_secret as optional parameters.

This is because client authentication is now handled in a separate section.
This is required (I still have a lot of work in this one) to separate the
client credentials from the flows which was a much requested change during
the meeting. Previous drafts made it very hard to specify client credentials
other than basic (i.e. Username and password like).

I plan to actually name the client identifier and password 'basic client
credentials' (which I think I already did in one spot), and say that if the
client was issued such basic credentials, this is how to use them (basic
auth or client_id/client_password parameters). Otherwise, this can be
extended to other credential types such as client identifier with PKI.

> understand, but maybe I just need more time...

This new structure requires much more clarity in the introduction and in the
client flows section. But it I think it makes implementation easier because
it gives all the technical details of the two endpoints in one place,
listing all the parameters and error codes.

Also, there is something to be said about dropping 20 pages.

What would be really useful is to get specific feedback about which new
sections are confusing, based on information not yet explained, etc.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 11 Jun 2010 14:33:45 -0700

The comment was about the token endpoint which used to include a 'type' parameter (indicating the flow being used). All the flows share the same token endpoint.

EHL

On 6/11/10 2:24 PM, "Christian Scholz" <[email-masked]> wrote:

Hi!

-- Christian

Podcasts:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 13 Jun 2010 14:03:25 +0200

some comments on the new draft from my side.

In my opinion, the raised abstraction level makes the spec harder to 
read but more elegant :-) Rearranging conceptual statements and 
endpoint/request descriptions would probably further improve 
readability. For example, the end-user authorization endpoint is one of 
the two interfaces exposed by the OAuth authz server. Thus it's 
specification is very important for AS and client implementors. Why not 
making 4.1.1 a first level section or a second level section underneath 
an "endpoints" section? The same holds for §5.1.

You decoupled flows (==use cases) from request types, a change a welcome 
very much. But why do you stick to flow types in 4.1.1? From my point of 
view, the parameter "type" is only used to control the way the authz 
server responds to the authorization request. There are currently two 
options: (1) verification code as URI query parameter and (2) access 
token as URI fragment. Why not rename "type" to "response_type" and use 
values like "code" and "fragment"? This would also allow to add other 
response types for web server clients, like "token as encrypted URI 
parameter".

Minor notes:
1 . Introduction

I would propose to extend the sentence

Instead, she authenticates directly with
    the photo sharing service (authorization server) which issues the
    printing service delegation-specific credentials (token).

to also mention the option of a dedicated authorization server, e.g.

Instead, she authenticates directly with the photo sharing service, or an OAuth authorization server the photo sharing service trusts for that purpose, ...

section 5.1.6.

Status code 400 is not appropriate from my point of view for all error 
situations. I would propose to use 401 and 403 for unauthenticated and 
unauthorized requests, respectively.

regards,
Torsten.

---

From: Andrew Arnott <[email-masked]>
Date: Sun, 13 Jun 2010 09:57:45 -0700

Eran,

While the flows in the spec today may have unique sets of required
parameters, other flows may exist with overlapping initial parameters (why?
perhaps the flows have different rules that don't come into effect until
later in the flow).  Keeping the type parameter in there would help
differentiate those.  Yes, the new flows could include a type parameter
while the originals did not, but then a token endpoint not prepared for the
unexpected flow would mistake the new flow for the old one.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Fri, Jun 11, 2010 at 2:25 PM, Eran Hammer-Lahav <[email-masked]>wrote:

>  It doesn’t really. It is completely clear what kind of authorization
> grant the client is providing simply by looking at the parameter. It might
> make the code a few lines longer (a few if-else instead of a switch-case)
> but because these are all post parameters, you access them the same way
> (i.e. this is not a case where header information is moved to post body,
> etc.).
>
> As for the rescope and revoke operations, we still need to figure out how
> to accomplish that. For example, revoking can be done using an HTTP DELETE
> operation which is more consistent with HTTP, and rescoping (which is still
> tricky because scope can only be decreased) is more a function of a refresh
> operation (asking for a new access token using a refresh token and simply
> providing a new, lesser scope).
>
> EHL
>
>
>
> > > Draft -07 represents a major rearrangement of the document. I still
> have a lot of work to do but wanted to share my progress and get some
> general feedback. The draft includes a few normative language changes but
> the main focus is on the document structure and how the architecture is
> explained.
> > >
> > > Changes include:
> > >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 13 Jun 2010 17:52:36 -0700

I would argue that if a new flow doesn't fit into the existing framework, it should define a new endpoint. For example, the device flow doesn't fit with the 2 endpoints model since the first call is really an half-authorization with a custom URI returned. The second flow uses a verification code.

The problem with the type parameter is that is break the clean abstraction because it allows turning the endpoint into anything really. I rather make it less appealing. Note that the new model unifies the refresh token flow with other types of authorization grants. I think that shows how well this abstraction works.

A type parameter is nothing but a duplication of the information sent.

EHL

From: Andrew Arnott [mailto:[email-masked]]
Sent: Sunday, June 13, 2010 9:58 AM
To: Eran Hammer-Lahav
Cc: Justin Richer; Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)

Eran,

While the flows in the spec today may have unique sets of required parameters, other flows may exist with overlapping initial parameters (why? perhaps the flows have different rules that don't come into effect until later in the flow).  Keeping the type parameter in there would help differentiate those.  Yes, the new flows could include a type parameter while the originals did not, but then a token endpoint not prepared for the unexpected flow would mistake the new flow for the old one.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Fri, Jun 11, 2010 at 2:25 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
It doesn't really. It is completely clear what kind of authorization grant the client is providing simply by looking at the parameter. It might make the code a few lines longer (a few if-else instead of a switch-case) but because these are all post parameters, you access them the same way (i.e. this is not a case where header information is moved to post body, etc.).

EHL

On 6/11/10 2:05 PM, "Justin Richer" <[email-masked]<http://[email-masked]>> wrote:

 -- Justin

On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <[email-masked]<http://[email-masked]>> wrote:
> [email-masked]<http://[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 14 Jun 2010 10:20:08 -0400

I disagree. I don't think it's redundant, I think it's a clarifying
piece of information that makes it completely unambiguous what the
client is expecting to happen. On the server side, a single switch is a
much simpler and less error-prone dispatch structure than a set of "if
this-and-that parameter else if this-other parameter else if
that-other-and-something-else parameter" statements. If one of our goals
of OAuth2 is easing the implementation for developers, dropping the
"type" field is a big lose. 

Also, as has already been pointed out, if a new flow comes in that wants
to use existing parameters in a different way, then it won't fit into
this framework or an extension. Decreasing ambiguity for a small price
(a few extra required characters for the auth flow) is a good thing. 

Incidentally, I agree that the refresh flow should fit in with all of
the other flows, but with "type=refresh". Maybe "type" is the wrong word
for this parameter? Because I was envisioning the rescope and revoke
operations to be similar to the refresh operation. Using HTTP DELETE is
a bad idea since it would require each token to have a URL associated
with it, and you can no longer manipulate the OAuth API with just query
parameters. A "type=revoke" call with the refresh token as
authentication and the token-to-be-revoked as parameter makes a whole
lot more sense to me.  It keeps these three operations parallel to the
other authorization flows -- part of the whole "how to get a token" side
of OAuth. 

 -- Justin

On Fri, 2010-06-11 at 17:25 -0400, Eran Hammer-Lahav wrote:
> grant the client is providing simply by looking at the parameter. It
> might make the code a few lines longer (a few if-else instead of a
> switch-case) but because these are all post parameters, you access
> them the same way (i.e. this is not a case where header information is
> moved to post body, etc.).
> 
> As for the rescope and revoke operations, we still need to figure out
> how to accomplish that. For example, revoking can be done using an
> HTTP DELETE operation which is more consistent with HTTP, and
> rescoping (which is still tricky because scope can only be decreased)
> is more a function of a refresh operation (asking for a new access
> token using a refresh token and simply providing a new, lesser scope).
> 
> EHL
> 
> 
>         > > Draft -07 represents a major rearrangement of the
>         document. I still have a lot of work to do but wanted to share
>         my progress and get some general feedback. The draft includes
>         a few normative language changes but the main focus is on the
>         document structure and how the architecture is explained.
>         > >
>         > > Changes include:
>         > >

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 14 Jun 2010 07:54:28 -0700

+1 for the type parameter.   

Our internal server and client developers would both prefer it.   

-cmort
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Justin Richer [[email-masked]]
Sent: Monday, June 14, 2010 7:20 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)

 -- Justin

---

From: Andrew Arnott <[email-masked]>
Date: Mon, 14 Jun 2010 08:23:57 -0700

I find the combination of the web server and user agent flows for end user
authorization unnatural -- particularly poignant in the success response,
which has 4 parameters -- but one flow MUST have no more than 2, and the
other must have 3.  And apparently now the user-agent flow can receive a
verification code as well as an access token?  It's unclear what that's for
or how that's used.

I suggest the spec break the two flows back up to make it easier to parse
what message shapes exist.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 09:18:15 -0700

Adding a verification code to the user-agent flow was suggested on this list and received nothing but support. It was suggested as a solution to a Twitter use case. Once that is added in, the two flows only differ in how the response is delivered and the presence of an access token in the response (which currently is a MUST NOT for web-server but I don't know if this restriction is need).

If we break them up, it is for editorial reasons only, which also means, every change needs to be made twice, as well as every extension needs to spell out which flavor it is for.

EHL

From: Andrew Arnott [mailto:[email-masked]]
Sent: Monday, June 14, 2010 8:24 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)

I find the combination of the web server and user agent flows for end user authorization unnatural -- particularly poignant in the success response, which has 4 parameters -- but one flow MUST have no more than 2, and the other must have 3.  And apparently now the user-agent flow can receive a verification code as well as an access token?  It's unclear what that's for or how that's used.

I suggest the spec break the two flows back up to make it easier to parse what message shapes exist.

On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Draft -07 represents a major rearrangement of the document. I still have a lot of work to do but wanted to share my progress and get some general feedback. The draft includes a few normative language changes but the main focus is on the document structure and how the architecture is explained.

Changes include:

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 09:23:29 -0700

Why client developers? How does it make their life easier?

An approach I'm more comfortable with is to redefine 'type' as the type of authorization grant provided: refresh_token, user_basic, verification_code, assertion. And if we use the name 'type', I would change the 'type' parameter on the end-user authorization endpoint to something else such as the proposed 'response_type'. Otherwise change it to 'grant_type' or something like that.

EHL

> -----Original Message-----
> From: Chuck Mortimore [mailto:[email-masked]]
> Sent: Monday, June 14, 2010 7:54 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] Draft -07 (major rewrite)
> 
> I disagree. I don't think it's redundant, I think it's a clarifying piece of
> information that makes it completely unambiguous what the client is
> expecting to happen. On the server side, a single switch is a much simpler
> and less error-prone dispatch structure than a set of "if this-and-that
> parameter else if this-other parameter else if that-other-and-something-else
> parameter" statements. If one of our goals of OAuth2 is easing the
> implementation for developers, dropping the "type" field is a big lose.
> 
> Also, as has already been pointed out, if a new flow comes in that wants to
> use existing parameters in a different way, then it won't fit into this
> framework or an extension. Decreasing ambiguity for a small price (a few
> extra required characters for the auth flow) is a good thing.
> 
> Incidentally, I agree that the refresh flow should fit in with all of the other
> flows, but with "type=refresh". Maybe "type" is the wrong word for this
> parameter? Because I was envisioning the rescope and revoke operations to
> be similar to the refresh operation. Using HTTP DELETE is a bad idea since it
> would require each token to have a URL associated with it, and you can no
> longer manipulate the OAuth API with just query parameters. A
> "type=revoke" call with the refresh token as authentication and the token-
> to-be-revoked as parameter makes a whole lot more sense to me.  It keeps
> these three operations parallel to the other authorization flows -- part of the
> whole "how to get a token" side of OAuth.
> 
>  -- Justin
> 
> > It doesn't really. It is completely clear what kind of authorization

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 09:49:39 -0700

> From: Justin Richer [mailto:[email-masked]]
> Cc: Marius Scurtescu; OAuth WG

The goal is to make client developers life easier. I never heard making it easier for server developers is a goal. In fact, with all the new flows and refresh token, OAuth 2.0 adds a lot more complexity to sever developers.

> extra required characters for the auth flow) is a good thing.

Creating a clear framework with a well-defined model wins over the ability to extend anything you feel like by defining a new parameter value. The original 'type' parameter talked about the kind of *flow* being used. It basically used the OpenID 'mode' architecture of a single endpoint overloaded with unrelated activities.

It turns out that we actually created a clean model where you request a token using one of 4 authorization grant constructs. If you ignore the device request for verification code (which doesn't feet the "Token Endpoint" definition anyway), the model is completely consistent. Using this endpoint now to delete a token would break this.

A much cleaner approach is to define a new endpoint, either a fixed one or as a return value with the token (as previously suggested by James).
 
> be similar to the refresh operation.

Refreshing a token is nothing more than asking for a new token using an authorization grant of type refresh token. It is exactly the same as using a verification code or end-user credentials.

> Using HTTP DELETE is a bad idea since it
> would require each token to have a URL associated with it

You should still be able to put the access token in a parameter using a DELETE operation. I'm not aware of any limitation on using query parameters with a DELETE operation. Can you point me to where this restriction is defined?

> and you can no longer manipulate the OAuth API with just query parameters.

Well, we don't actually use query parameters, we use form-encoded body parameters.

> A "type=revoke" call with the refresh token as authentication and the token-

As stated earlier, I'm ok with a parameter indicating the kind of authorization grant being used. But that will not solve your use case.

Using the refresh token as authentication will not work for the many cases where no such token is issued. Sending just the access token is enough - if an access token alone is secure enough to access protected resources, it is clearly secure enough to revoke it.

In general, I am still not clear on the token modification requirements (delete, re-scope). It would be useful to discuss how it would be used in practice (what kind of clients, for what purpose, etc.), and what existing experience we have to use as reference. For now, adding token revocation and re-scoping seems better suited to an extension than the core specification.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Mon, 14 Jun 2010 11:23:26 -0700

On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> Adding a verification code to the user-agent flow was suggested on this list
> and received nothing but support. It was suggested as a solution to a
> Twitter use case. Once that is added in, the two flows only differ in how
> the response is delivered and the presence of an access token in the
> response (which currently is a MUST NOT for web-server but I don’t know if
> this restriction is need).

Yeah, this matters.  If you return an access token on the web-server
flow, several things break:
- you can no longer rely on the client secret to authenticate the callback URL.
- you lose all hope of getting to LOA 2 with this protocol, because
the access token is visible to the client.
- you lose the clarity of how the web server flow is supposed to work.

Bike-shed painting:

The use-cases for web server and user-agent flow are also different.
I'd prefer to have the spec call out different profiles for different
use-cases, because it makes it much easier to figure out what a given
application should be doing.

During the WRAP work I argued that we didn't need a type parameter,
and after looking at WRAP implementations I've changed my mind.
Please leave it in.

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Mon, 14 Jun 2010 11:27:57 -0700

On Mon, Jun 14, 2010 at 8:23 AM, Andrew Arnott <[email-masked]> wrote:
> And apparently now the user-agent flow can receive a

Here's the thread where Brian Ellin proposed the verification code on
the user-agent flow.

http://www.ietf.org/mail-archive/web/oauth/current/msg02657.html

Summary of why it's a good idea:
- makes it easier to recover from compromise of refresh tokens
- makes refresh token compromise less likely, because it is never
passed via the browser
- clear upgrade path from embeddable widgets to "server-side integrations

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 11:38:49 -0700

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Monday, June 14, 2010 11:23 AM
> To: Eran Hammer-Lahav
> Cc: Andrew Arnott; OAuth WG ([email-masked])
> > Adding a verification code to the user-agent flow was suggested on
> > this list and received nothing but support. It was suggested as a
> > solution to a Twitter use case. Once that is added in, the two flows
> > only differ in how the response is delivered and the presence of an
> > access token in the response (which currently is a MUST NOT for
> > web-server but I don't know if this restriction is need).
> 
> Yeah, this matters.  If you return an access token on the web-server flow,
> several things break:
> - you lose all hope of getting to LOA 2 with this protocol, because the access
> token is visible to the client.

Ok. No change needed.
 
> I'd prefer to have the spec call out different profiles for different use-cases,
> because it makes it much easier to figure out what a given application should
> be doing.
> 
> During the WRAP work I argued that we didn't need a type parameter, and
> after looking at WRAP implementations I've changed my mind.
> Please leave it in.

Which one? The type on the end-user authorization endpoint (user_agent and web_server) or the type on the token endpoint?

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 15 Jun 2010 16:18:44 -0700

On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> Twitter use case.

I think it would be good to see a detailed use case where this is
really needed and the previous Web Server and/or User-Agent flows
could not do.

A Java-Script client can use the Web Server flow to grab a
verification code and then either swap it or pass it down to the
client server.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 15 Jun 2010 17:05:27 -0700

It gives you a hybrid solution. The user-agent client doesn't not need to keep the client secret, but can still move the authorization code to its server component to obtain a longer lasting refresh token. It also allows the server to manage the two tokens using different policies (the one obtained using the user-agent flow directly and the one obtained using an authenticated client call on the server).

EHL

-----Original Message-----
From: Marius Scurtescu [mailto:[email-masked]] 
Sent: Tuesday, June 15, 2010 4:19 PM
To: Eran Hammer-Lahav
Cc: Andrew Arnott; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)

On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> solution to a Twitter use case.

I think it would be good to see a detailed use case where this is really needed and the previous Web Server and/or User-Agent flows could not do.

A Java-Script client can use the Web Server flow to grab a verification code and then either swap it or pass it down to the client server.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 15 Jun 2010 17:23:49 -0700

> It gives you a hybrid solution. The user-agent client doesn't not need to keep the client secret, but can still move the authorization code to its server component to obtain a longer lasting refres…

OK, but why cannot this be done with the Web Server profile? The
JavaScript client can start the Web Server profile and at the end it
gets an authorization code (as a query parameter as opposed to
fragment) which it can pass to the its server...

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 15 Jun 2010 17:34:36 -0700

Because that defeats the point of having two different access tokens, one issued with a client secret and the other without. It also requires the JS client to interact a lot more with the server part and wait for responses (no needed when it just sends over the authorization code).

EHL

-----Original Message-----
From: Marius Scurtescu [mailto:[email-masked]] 
Sent: Tuesday, June 15, 2010 5:24 PM
To: Eran Hammer-Lahav
Cc: Andrew Arnott; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)

> It gives you a hybrid solution. The user-agent client doesn't not need to keep the client secret, but can still move the authorization code to its server component to obtain a longer lasting refres…

OK, but why cannot this be done with the Web Server profile? The JavaScript client can start the Web Server profile and at the end it gets an authorization code (as a query parameter as opposed to
fragment) which it can pass to the its server...

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 15 Jun 2010 18:04:32 -0700

On Tue, Jun 15, 2010 at 5:34 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Because that defeats the point of having two different access tokens, one issued with a client secret and the other without.

If the authorization code is passed by the JavaScript client to the
client server, then the client server can use its secret if it has
one. Access token with client secret can be issued.

If the authorization code is swapped directly by the JavaScript client
then it is clear that there is no secret (based on both client id and
the fact that no secret is sent), access token with no client secret
is issued.

Where does Web Server vs User-Agent make a difference?

> It also requires the JS client to interact a lot more with the server part and wait for responses (no needed when it just sends over the authorization code).

Maybe, but it would be good to see in detail such a case. When does
the JavaScript interact a lot more and why?

Marius

---

From: Dick Hardt <[email-masked]>
Date: Tue, 22 Jun 2010 13:22:34 -0700

One of the modifications I concluded to do to WRAP was to add in the type
parameter. I was happy to see if in David's draft.

Even though redundant in some ways, it make it very clear to both the client
and server what is intended.

+1 for putting it back in.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 22 Jun 2010 13:28:33 -0700

Per an earlier comment, "type" might not be the best name for the parameter.
Perhaps "method" might work and adds a clear extension point for other types
of calls?

On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt <[email-masked]> wrote:

> Even though redundant in some ways, it make it very clear to both the
> client and server what is intended.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Jun 2010 15:11:43 -0700

You are a bit behind. -08 added it back as grant_type which works better with the current explanation.

EHL

From: Dick Hardt [mailto:[email-masked]]
Sent: Tuesday, June 22, 2010 1:29 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)

Per an earlier comment, "type" might not be the best name for the parameter. Perhaps "method" might work and adds a clear extension point for other types of calls?
On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
One of the modifications I concluded to do to WRAP was to add in the type parameter. I was happy to see if in David's draft.

Even though redundant in some ways, it make it very clear to both the client and server what is intended.

On Mon, Jun 14, 2010 at 11:23 AM, Brian Eaton <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
> response (which currently is a MUST NOT for web-server but I don't know if

Bike-shed painting:

Cheers,
Brian