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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
