[Openid-specs-ab] FW: [OAUTH-WG] Registration: grant_types and response_types

[Mike Jones]

See the updated response_types and grant_types language at http://openid.bitbucket.org/openid-connect-registration-1_0.html#client-metadata.  This adds the table discussed on the call today and makes it clear that the Client is declaring that it is restricting the response_type and grant_type values that it will use.

                                                            -- Mike

From: Mike Jones
Sent: Wednesday, February 27, 2013 5:35 PM
To: Mike Jones; openid-specs-ab at lists.openid.net
Subject: RE: [Openid-specs-ab] FW: [OAUTH-WG] Registration: grant_types and response_types

To make this possibility concrete, I added the "grant_types" parameter in http://openid.bitbucket.org/openid-connect-registration-1_0.html#client-metadata for discussion purposes.  We should probably either keep it or delete the "response_types" parameter, which is right next to it.

Let's talk about this on the call tomorrow.

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Mike Jones
Sent: Wednesday, February 27, 2013 2:54 PM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: [Openid-specs-ab] FW: [OAUTH-WG] Registration: grant_types and response_types

I would propose that we drop the current Connect Registration parameter "response_types" and replace it with the "grant_types" registration parameter, including the table below (other than "none", which we don't use) so that it's clear to implementers what grant types to register for which response_types.

                                                            -- Mike

From: Mike Jones
Sent: Wednesday, February 27, 2013 2:52 PM
To: 'Justin Richer'; oauth at ietf.org<mailto:oauth at ietf.org>
Subject: RE: [OAUTH-WG] Registration: grant_types and response_types

John Bradley and I just talked about this during a side meeting at RSA.  We think that this is the mapping of grant types and defined response types.  (The additional response_type values are registered with IANA and defined in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html.)

response_type value

grant_types

code

authorization_code

token

implicit

id_token

implicit

token id_token

implicit

code token

authorization_code implicit

code id_token

authorization_code implicit

code token id_token

authorization_code implicit

none

none


If people agree that this is the mapping, and that it conveys sufficient information, then conceivably OpenID Connect could drop the response_types registration parameter and instead just use the OAuth Registration "grant_types" parameter.

What do others think?

                                                            -- Mike

P.S.  There's a typo in the OAuth Registration spec section quoted below.  The name "grant_type" should have been "grant_types", since the value is a list.  We should correct that in the next version of the spec.

From: oauth-bounces at ietf.org<mailto:oauth-bounces at ietf.org> [mailto:oauth-bounces at ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, February 27, 2013 8:00 AM
To: oauth at ietf.org<mailto:oauth at ietf.org>
Subject: [OAUTH-WG] Registration: grant_types and response_types

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<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.1>.



      *  "implicit": The Implicit Grant described in OAuth2 Section 4.2<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.2>.



      *  "password": The Resource Owner Password Credentials Grant

         described in OAuth2 Section 4.3<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.3>



      *  "client_credentials": The Client Credentials Grant described in

         OAuth2 Section 4.4<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.4>



      *  "refresh_token": The Refresh Token Grant described in OAuth2

         Section 6<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#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<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130301/4eaaa1dd/attachment.html>