<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Mike Jones
<br>
<b>Sent:</b> Wednesday, February 27, 2013 2:52 PM<br>
<b>To:</b> 'Justin Richer'; oauth@ietf.org<br>
<b>Subject:</b> RE: [OAUTH-WG] Registration: grant_types and response_types<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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 <a href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html">
http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html</a>.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">response_type value<o:p></o:p></span></b></p>
</td>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;border-left:none;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">grant_types<o:p></o:p></span></b></p>
</td>
</tr>
<tr>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">code<o:p></o:p></span></p>
</td>
<td width="399" valign="top" style="width:239.4pt;border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">authorization_code<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">token<o:p></o:p></span></p>
</td>
<td width="399" valign="top" style="width:239.4pt;border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">implicit<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">id_token<o:p></o:p></span></p>
</td>
<td width="399" valign="top" style="width:239.4pt;border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">implicit<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">token id_token<o:p></o:p></span></p>
</td>
<td width="399" valign="top" style="width:239.4pt;border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">implicit<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">code token<o:p></o:p></span></p>
</td>
<td width="399" valign="top" style="width:239.4pt;border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">authorization_code implicit<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">code id_token<o:p></o:p></span></p>
</td>
<td width="399" valign="top" style="width:239.4pt;border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">authorization_code implicit<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">code token id_token<o:p></o:p></span></p>
</td>
<td width="399" valign="top" style="width:239.4pt;border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">authorization_code implicit<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="399" valign="top" style="width:239.4pt;border:solid windowtext 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">none<o:p></o:p></span></p>
</td>
<td width="399" valign="top" style="width:239.4pt;border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">none<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">What do others think?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
<a href="mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org</a> [<a href="mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a>]
<b>On Behalf Of </b>Justin Richer<br>
<b>Sent:</b> Wednesday, February 27, 2013 8:00 AM<br>
<b>To:</b> <a href="mailto:oauth@ietf.org">oauth@ietf.org</a><br>
<b>Subject:</b> [OAUTH-WG] Registration: grant_types and response_types<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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.
<br>
<br>
The dynamic registration document currently handles this using the grant_type parameter (introduced in draft -03), which is defined in section 2 as follows:<o:p></o:p></p>
<pre> grant_type<o:p></o:p></pre>
<pre> OPTIONAL. Array of grant types that a client may use. These<o:p></o:p></pre>
<pre> grant types are defined as follows:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> * "authorization_code": The Authorization Code Grant described in<o:p></o:p></pre>
<pre> OAuth2 <a href="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.1">Section 4.1</a>.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> * "implicit": The Implicit Grant described in OAuth2 <a href="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.2">Section 4.2</a>.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> * "password": The Resource Owner Password Credentials Grant<o:p></o:p></pre>
<pre> described in OAuth2 <a href="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.3">Section 4.3</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> * "client_credentials": The Client Credentials Grant described in<o:p></o:p></pre>
<pre> OAuth2 <a href="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.4">Section 4.4</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> * "refresh_token": The Refresh Token Grant described in OAuth2<o:p></o:p></pre>
<pre> <a href="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-6">Section 6</a>.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> Authorization Servers MAY allow for other values as defined in<o:p></o:p></pre>
<pre> grant type extensions to OAuth2. The extension process is<o:p></o:p></pre>
<pre> described in OAuth2 <a href="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-2.5">Section 2.5</a>, and the value of this parameter<o:p></o:p></pre>
<pre> MUST be the same as the value of the "grant_type" parameter<o:p></o:p></pre>
<pre> defined in the extension.<o:p></o:p></pre>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
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.
<br>
<br>
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:<o:p></o:p></p>
<p class="MsoNormal"><tt><span style="font-size:10.0pt">response_types</span></tt><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><tt><span style="font-size:10.0pt">OPTIONAL. JSON array containing a list of the OAuth 2.0 response_type
</span></tt><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><tt><span style="font-size:10.0pt">values that this Client uses. If omitted, the default is that the Client
</span></tt><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><tt><span style="font-size:10.0pt">uses only the code response type.
</span></tt><o:p></o:p></p>
<p><br>
OIDC makes use of response_types beyond just "code" and "token", defining several new ones including combinations like "code idtoken".
<o:p></o:p></p>
<p class="MsoNormal">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.<br>
<br>
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.<br>
<br>
-- Justin<o:p></o:p></p>
</div>
</body>
</html>