<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>The only way to really switch between the code flow and the implicit flow is the response_type parameter -- using any other parameter to hint for this is dangerous and prone to error. All other parameters MAY be used in either flow. For example, you can
have "nonce" in any profile, and the server *needs* to accept it, but it's *required* for an implicit client to send it for security reasons (I'll let others fill in the details on the exact reasoning behind that?).</div>
<div><br>
</div>
<div>This all grows out of the OAuth2 core spec, which actually defines four different flows (auth code, implicit, client credentials, and password) with an extension mechanism (that has been used for things like assertion flows).</div>
<div><br>
</div>
<div> -- Justin</div>
<div><br>
<div>
<div>On Jun 6, 2012, at 5:08 PM, Magnus Andersson wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>Hi everyone</div>
<div><br>
</div>
<div>First a short introduction: My name is Magnus, I'm currently implementing an OpenID Connect server as per the draft specifications. I have a concern about the recent update to the drafts where nonce is removed from basic profile authorization request. </div>
<div><br>
</div>
<div>As I read it after the last update, I can not longer determine which request parameters are allowed/should to be present for the authorize endpoint until after I have read the content of response_type and thus determined if the flow is the 'implicit flow'
or 'code flow'. The spec <i>openid-connect-implicit</i> have nonce listed as OPTIONAL but the
<i>openid-connect-basic</i> does not expect it to be present at all.</div>
<div><br>
</div>
<div>
<div>Common validation libraries in web frameworks won't easily handle when the presence of one request parameter directly depends on another parameter's data. It also suggests too many responsibilities, in my opinion. This makes implementation unnecessarily
complex.</div>
<div><br>
</div>
</div>
<div>
<div>If I'm missing something obvious please tell. I'm very new to OpenID Connect so I recognize I might have missed something obvious.</div>
</div>
<div><br>
</div>
<div>If I am on to something I would suggest: </div>
<div><b><i>either</i></b> option to have two different endpoints in the Discovery service for authorization, one for each of the two different kinds of authorization flows </div>
<div><i><b>or</b></i> only one single set of required/optional parameters per endpoint regardless of how many flows it supports.</div>
<div><br>
</div>
<div>My preference is the first alternative as it would reflect how the specs are split up today and make flows more visible. To me it is non-obvious what stipulates code flow or implicit flow mode, I have had to read both documents and compare to figure out
what the difference is.</div>
<div><br>
</div>
<div>Kind regards</div>
<div>Magnus Andersson</div>
<div><br>
</div>
-- <br>
<div><font face="tahoma, sans-serif"><img src="https://dl.dropbox.com/u/1560817/solvies-email-sig2.png"><br>
</font></div>
<div><font face="tahoma, sans-serif"><br>
</font></div>
<div><font face="tahoma, sans-serif">Magnus Andersson<br>
</font></div>
<div><font face="tahoma, sans-serif"></font></div>
<div>
<div><font face="tahoma, sans-serif">Solvies AB</font></div>
<div><font face="tahoma, sans-serif">Telefon: +46-738-403885</font></div>
<div><font face="tahoma, sans-serif">E-post: <a href="mailto:magnus.andersson@solvies.se" target="_blank">magnus.andersson@solvies.se</a></font></div>
</div>
<div><font face="tahoma, sans-serif">Webplats: <a href="http://www.solvies.se/" target="_blank">http://www.solvies.se</a></font></div>
<div><br>
</div>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
http://lists.openid.net/mailman/listinfo/openid-specs-ab<br>
</blockquote>
</div>
<br>
</div>
</body>
</html>