Subject: [OAUTH-WG] Comments on core draft -11

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 13 Dec 2010 20:00:32 +0100

section 5.1.5 Assertion
I expected the assertion flow to be replaced by a general extension 
model for new grant types (as described in section 7.4)?

But the the current text in section 5.1.5. requires every new grant type 
to use the "assertion" parameter. Thus it supports additional assertion 
formats, only. What is the benefit of that restriction? Moreover, how 
should one define new grant types that are not assertion based or need 
no or more than one parameter? For example in the context of 
telecommunication, I see the need to support GBA, HOTP, and plain IP 
address-based user authentication. For the later, only a grant type w/o 
any further parameters is required.

I would suggest dropping the required parameter “assertion”. Instead, 
deployments could define new grant types along with their accompanying 
parameters. For assertion-based new grant type this could be the 
assertion parameter though.

w/ respect to section 7.4 I would suggest to change
“Applications that wish to define additional access grant types can do 
so by utilizing a new or existing assertion type and format.” into
“Applications that wish to define additional access grant types can do 
so by utilizing a new or existing grant type name.”

section 5.1.5
The description mixes up user authentication via assertion and client 
authentication via assertion. Shouldn’t clients be authenticated via 
client_assertion parameter?

section 5.2
“The authorization server SHOULD NOT issue a refresh token when the 
access grant type is an assertion or a set of client credentials.”

How shall the server determine whether to issue refresh tokens in case 
of grant type “Resource Owner Password Credentials”? In contrast to 
authorization code, the user is not directly involved in the interaction 
with the authorization server.

I would suggest adding an optional request parameter “refresh_token” of 
type boolean to explicitly ask the server for a refresh token.

section 5.1.3
Error code “unauthorized_client” in my opinion calls for status code 403

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 13 Dec 2010 13:27:02 -0800

On Mon, Dec 13, 2010 at 11:00 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> section 5.2
> “The authorization server SHOULD NOT issue a refresh token when the access
> grant type is an assertion or a set of client credentials.”
>
> How shall the server determine whether to issue refresh tokens in case of
> grant type “Resource Owner Password Credentials”? In contrast to

Not directly, but the user did provide the credentials. In this case
the only long term credentials the client has are the end user
credentials, the server better issue a refresh token so the client is
not forced to store the user credentials, right?

> I would suggest adding an optional request parameter “refresh_token” of type
> boolean to explicitly ask the server for a refresh token.

I agree that something like this parameter would be useful. Maybe
something a bit more generic to allow clients to request access and/or
refresh tokens. I will send an extension proposal in this regard.

But I don't think this mechanism should be used to decide if the
assertion profile issues a refresh token.

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 13 Dec 2010 23:09:12 +0100

> not forced to store the user credentials, right?

Agreed, it's better to store a refresh token than username/password. But 
that's not my point.

The user gave the client his credentials, which is a user consent 
somehow. But the user does not necessarily want to stay logged in (i.e. 
he didn't disabled the respective checkbox). That's why I think we need 
a way to signal this distinction to the authorization server. So the 
server does not need to create a refresh token, which is useless. If you 
have a more generic proposal, that's fine with me.

regards,
Torsten.