For grant_type you have to make up implicit as a grant_type. They are sort of separate things and are both extendable in the case of assertions for the token endpoint, and new response types like "code id_token" or "token code" for response type.
Both could be used to not allow implicit but also have other value. I would like to combine them, but that may be more confusing than directly mapping them to the OAuth functionality. It may be sufficient to have response_type and grant_type in discovery but only grant_type in registration. We need to agree on what grant_type/s are required for a response_type of "code id_token" that is returned in a fragment but uses the token endpoint. John B. Sent from my iPhone On 2013-02-27, at 7:59 AM, Justin Richer <[email protected]> wrote: > There has been some press lately about clients being able to use an implicit > flow to get tokens when they really ought to only use a code flow, since the > security considerations and protections for both are very different. With > this in mind, it makes sense that a dynamically registered client should be > limited to use only certain flows, if at all possible. > > The dynamic registration document currently handles this using the grant_type > parameter (introduced in draft -03), which is defined in section 2 as follows: > > grant_type > OPTIONAL. Array of grant types that a client may use. These > grant types are defined as follows: > > * "authorization_code": The Authorization Code Grant described in > OAuth2 Section 4.1. > > * "implicit": The Implicit Grant described in OAuth2 Section 4.2. > > * "password": The Resource Owner Password Credentials Grant > described in OAuth2 Section 4.3 > > * "client_credentials": The Client Credentials Grant described in > OAuth2 Section 4.4 > > * "refresh_token": The Refresh Token Grant described in OAuth2 > Section 6. > > Authorization Servers MAY allow for other values as defined in > grant type extensions to OAuth2. The extension process is > described in OAuth2 Section 2.5, and the value of this parameter > MUST be the same as the value of the "grant_type" parameter > defined in the extension. > > This allows the client to specify which flows it wants to be able to use > (including any extensions), and allows the server to to tell the client in > the client configuration response what flows it can expect to work. > > OpenID Connect's registration has recently introduced the use of a different > parameter, response_type, for a similar but slightly different purpose. The > parameter is defined in the latest draft in source control as: > > response_types > OPTIONAL. JSON array containing a list of the OAuth 2.0 response_type > values that this Client uses. If omitted, the default is that the Client > uses only the code response type. > > OIDC makes use of response_types beyond just "code" and "token", defining > several new ones including combinations like "code idtoken". > So my question to the group is this: Should we incorporate the OIDC > response_types parameter? Do we need both parameters specified in the > registration or is one sufficient? They're defined separately in the OAuth2 > protocol (one is on the Auth endpoint and one is on the Token endpoint), but > can only be used legally in particular combinations so there would have to be > normative text around particular values. > > In my opinion, I don't think we can get rid of grant_type, since that's the > only way to specify things like client_credentials flows and most extensions. > There might be value in also specifying response_type, but I don't want to > add extra fields unless there's a clearly defined need for it. > > -- Justin > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
