<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">OK. That's better. Note that my comment
is against -14. <br>
<br>
Now we have Hybrid Flow and Implicit Flow as defined terms. Why
not define Code Flow and more notably OAuth 2.0 Flow as well? <br>
<br>
Code Flow<br>
OAuth 2.0 flow in which all tokens are returned from the Token
Endpoint.<br>
<br>
Implict Flow<br>
OAuth 2.0 flow in which all tokens are returned from the
Authorization Endpoint.<br>
<br>
Hybrid Flow<br>
OAuth 2.0 flow in which some tokens are returned from the
Authorization Endpoint<br>
and others are returned from the Token Endpoint.<br>
<br>
OAuth 2.0 Flow<br>
Sequence of request and response among the Client, Server, and the
User-Agent to obtain Tokens as the direct result of Authorization
Grant. <br>
<br>
The "direct result of Authorization Grant" bit is important since
otherwise all the Flows definition become inaccurate because you
could get further tokens from other endpoints e.g. UserInfo
endpoint in exchange to Access Token. <br>
<br>
<br>
<br>
(2013/10/30 21:23), Brian Campbell wrote:<br>
</div>
<blockquote
cite="mid:CA+k3eCSQXZmXTAaVztmervgUpp8J-hcNETc0JQjW3QSjm8VkOg@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">FWIW "Implicit Code Flow" has been changed to
""Implicit Flow" in -15 of core: <a moz-do-not-send="true"
href="http://hg.openid.net/connect/commits/c5fa47253977b44983fb5e29337144d1c87f69cb">http://hg.openid.net/connect/commits/c5fa47253977b44983fb5e29337144d1c87f69cb</a>
so it is defined in the Terminology section.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Oct 30, 2013 at 5:47 AM, Nat
Sakimura <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div dir="auto">
<div><br>
<br>
<br>
</div>
<div><br>
Oct 30, 2013 20:04、John Bradley <<a
moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com"
target="_blank">ve7jtb@ve7jtb.com</a>> のメッセージ:<br>
<br>
</div>
<div class="im">
<blockquote type="cite">
<div>I like the table idea. </div>
</blockquote>
<div><br>
</div>
</div>
<div>Let's go that way. </div>
<div class="im"><br>
<blockquote type="cite">
<div>Where do you see "<span>Implicit Code Flow"?</span></div>
</blockquote>
<div><br>
</div>
</div>
<div><span><a moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0-14.html#Terminology"
target="_blank">http://openid.net/specs/openid-connect-core-1_0-14.html#Terminology</a></span></div>
<div class="im">
<div><span><br>
</span></div>
<blockquote type="cite">
<div>
<div><span><br>
</span></div>
<div><span>RFC 6749 defines it. Essentially as any
flow not using a grant type at the token
endpoint, arguably more confusing
than referring to the response types.</span></div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>Yeah, actually, the paragraph 1 of 1.3.2 of RFC6749
starts as "The implicit grant is ... " then in the next
sentence it says "In the implicit flow ... " so it sort
of implicitly defines implicit flow but not as a defined
term . </div>
<div>
<div class="h5"><br>
<blockquote type="cite">
<div>
<div><span><br>
</span></div>
<div><span><br>
</span>
<div>
<div>On Oct 30, 2013, at 4:31 AM, n-sakimura
<<a moz-do-not-send="true"
href="mailto:n-sakimura@nri.co.jp"
target="_blank">n-sakimura@nri.co.jp</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div>
<div><span>"Implicit Code Flow" is
defined. Neither "Implicit Flow" nor
"Code Flow" is defined.<span> </span><br>
And that is a very secondary point in
my email.<span> </span><br>
What I pointed out was that perhaps a
table is better as a guidance.<span> </span><br>
<br>
See my other email for the proposed
text.<span> </span><br>
<br>
Nat<br>
</span><br>
<br>
(2013/10/30 15:42), Mike Jones wrote:<br>
</div>
<blockquote type="cite">
<div>"Implicit Flow" is defined in the
Terminology section.<br>
<br>
</div>
<hr><span>From:<span> </span></span><span>n-sakimura</span><br>
<span>Sent:<span> </span></span><span>10/29/2013
9:51 PM</span><br>
<span>To:<span> </span></span><span><a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.net</a></span><br>
<span>Subject:<span> </span></span><span>Re:
[Openid-specs-ab] Guidance on what the
different flows are for</span><br>
<br>
<div>
<div>(2013/10/30 10:22), Mike Jones
wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal">Several
reviewers have requested
guidance on when to use the
different flows. I believe that
we’d be doing a service to our
readers by providing it.</p>
<div> <br>
</div>
<p class="MsoNormal">Several
reviewers have objected to this
text in<span> </span><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0.html#Authentication"
target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#Authentication</a><span> </span>–
saying that sometimes the Code
flow is used even when the
client can’t maintain the
secrecy of the client_secret:</p>
<p class="MsoNormal"><span
lang="EN">The Authorization
Code Flow is suitable for
Clients that can securely
maintain a Client Secret
between themselves and the
Authorization Server whereas,
the Implicit Flow is suitable
for Clients that cannot.</span></p>
<div> <br>
</div>
<p class="MsoNormal">I believe
that that the statement would
still be true if we changed the
word “suitable” to “intended”.
And then, as discussed in the
F2F meeting, we could add the
sentence:</p>
<p class="MsoNormal">
“However, the Authorization Code
flow is sometimes also used by
Native applications in order to
be able to obtain a Refresh
Token, even when they cannot
ensure the secrecy of the
client_secret value.”</p>
</div>
</blockquote>
It does not have to be native
applications.<span> </span><br>
We do not have to constrain code grant
for anything.<span> </span><br>
<br>
Only the thing which may be worth
noting is that (1) enables client
authentication for confidential
clients, (2) allows clients to obtain
refresh token, (3) more secure than
implicit grant as the token is not
exposed in the front channel, (4)
requires extra roundtrip compaired to
the implicit, (5) Token endpoint has
to be directly reacheable from the
client.<span> </span><br>
<br>
In contrast, the implicit grant will
have (1) less roundtrip and thus
latency, (2) the client does not need
a direct reacheability to the server,
(3) client cannot be confidential, (4)
tokens are exposed in the frong
channel so inherently less secure, and
(5) you cannot get refresh token with
this grant.<span> </span><br>
<br>
Perhaps having tables like the
following is better as the guidance.<span> </span><br>
<br>
<table>
<tbody>
<tr>
<td width="329">
<p class="MsoNormal"><span
lang="EN-US">Conditions /
Requirement</span></p>
</td>
<td width="85">
<p class="MsoNormal"><span
lang="EN-US">code grant</span></p>
</td>
<td width="85">
<p class="MsoNormal"><span
lang="EN-US">implicit
grant</span></p>
</td>
<td width="82">
<p class="MsoNormal"><span
lang="EN-US">hybrid grant</span></p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal"><span
lang="EN-US">Server is not
directly reachable from
the client</span></p>
</td>
<td width="85"><span
lang="EN-US"> </span><br>
</td>
<td width="85">
<p class="MsoNormal">
<span lang="EN-US">x</span></p>
</td>
<td width="82"><span
lang="EN-US"> </span><br>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal"><span
lang="EN-US">Want less
round trip</span></p>
</td>
<td width="85"><span
lang="EN-US"> </span><br>
</td>
<td width="85">
<p class="MsoNormal"><span
lang="EN-US">x</span></p>
</td>
<td width="82">
<p class="MsoNormal"><span
lang="EN-US">x</span></p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal"><span
lang="EN-US">Do not want
to reveal tokens for
better security</span></p>
</td>
<td width="85">
<p class="MsoNormal"><span
lang="EN-US">x</span></p>
</td>
<td width="85"><span
lang="EN-US"> </span><br>
</td>
<td width="82">
<p class="MsoNormal"><span
lang="EN-US">(some)</span></p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal"><span
lang="EN-US">Want client
authentication</span></p>
</td>
<td width="85">
<p class="MsoNormal"><span
lang="EN-US">x</span></p>
</td>
<td width="85"><span
lang="EN-US"> </span><br>
</td>
<td width="82">
<p class="MsoNormal">
<span lang="EN-US">x</span></p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal"><span
lang="EN-US">Want refresh
token</span></p>
</td>
<td width="85">
<p class="MsoNormal"><span
lang="EN-US">x</span></p>
</td>
<td width="85">
<span lang="EN-US"> </span><br>
</td>
<td width="82">
<p class="MsoNormal"><span
lang="EN-US">x</span></p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal"><span
lang="EN-US">Slow front
channel, fast back channel</span></p>
</td>
<td width="85">
<p class="MsoNormal"><span
lang="EN-US">x</span></p>
</td>
<td width="85"><span
lang="EN-US"> </span><br>
</td>
<td width="82">
<p class="MsoNormal"><span
lang="EN-US">x</span></p>
</td>
</tr>
</tbody>
</table>
<br>
The same table is uploaded here:<span> </span><a
moz-do-not-send="true"
href="http://nat.sakimura.org/2013/10/30/guidance-on-which-grant-flow-to-use-for-openid-connect/"
target="_blank">http://nat.sakimura.org/2013/10/30/guidance-on-which-grant-flow-to-use-for-openid-connect/</a><br>
<br>
BTW, do we still want to use the term
"flow"? OAuth stopped using the term
and it uses "grant" instead.
Currently, "implicit flow" for example
is not defined.<span> </span><br>
<br>
Nat<br>
<br>
<br>
<blockquote type="cite">
<div>
<div> <br>
</div>
<p class="MsoNormal">Would that
combination work for people?</p>
<div> <br>
</div>
<p class="MsoNormal">Finally, I
propose that we add this
guidance about the Hybrid Flow:</p>
<p class="MsoNormal">“The Hybrid
flow enables Clients to obtain
an ID Token and/or Access Token
with only one round trip to the
Authorization Server, possibly
minimizing latency, while still
enabling Clients to later get
tokens from the Token Endpoint –
especially a Refresh Token.”</p>
<div> <br>
</div>
<p class="MsoNormal">Per the
decision at the F2F, all this
“guidance” text would move to
the introduction.</p>
<div> <br>
</div>
<p class="MsoNormal">Are people
good with the wording above, or
would you like to make
alternative suggestions?</p>
<div> <br>
</div>
<p class="MsoNormal"> <span> </span>--
Mike</p>
<div> <br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
Nat Sakimura (<a moz-do-not-send="true" href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd.
<a moz-do-not-send="true" href="tel:+81-3-6274-1412" target="_blank">Tel:+81-3-6274-1412</a> Fax:<a moz-do-not-send="true" href="tel:%2B81-3-6274-1547" value="+81362741547" target="_blank">+81-3-6274-1547</a>
本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござӓ
;
6;|
14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
</pre>
</div>
</blockquote>
<br>
<br>
<pre cols="72">--
Nat Sakimura (<a moz-do-not-send="true" href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd.
<a moz-do-not-send="true" href="tel:+81-3-6274-1412" target="_blank">Tel:+81-3-6274-1412</a> Fax:<a moz-do-not-send="true" href="tel:%2B81-3-6274-1547" value="+81362741547" target="_blank">+81-3-6274-1547</a>
本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござӓ
6;|
14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
</pre>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Openid-specs-ab mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank">Openid-specs-ab@lists.openid.net</a></span><br>
<span><a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Nat Sakimura (<a class="moz-txt-link-abbreviated" href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd.
<a class="moz-txt-link-freetext" href="Tel:+81-3-6274-1412">Tel:+81-3-6274-1412</a> Fax:+81-3-6274-1547
本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござӓ
6;|
14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
</pre>
</body>
</html>