<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Ah, OK. Then a stand alone "Code Flow"
in -d15 2.2.2.1 para 2 must be a bug. <br>
<br>
There is "Hybrid Code Flow" left in 2.3.3.9 para 1 as well. <br>
<br>
What about the main point around "OAuth 2.0 flow"? <br>
Some tokens may be returned from other endpoints, e.g., userinfo
endpoint in the case of the distributed claims model. <br>
<br>
<br>
(2013/10/31 12:29), Mike Jones wrote:<br>
</div>
<blockquote
cite="mid:4E1F6AAD24975D4BA5B168042967394377E30C04@TK5EX14MBXC288.redmond.corp.microsoft.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<div class="WordSection1">
<p class="MsoNormal"><span>We use the term “Authorization Code
Flow” instead of “Code Flow” to match the OAuth 2.0
terminology.</span></p>
<p class="MsoNormal"><span> </span></p>
<div>
<div>
<p class="MsoNormal"><b><span>From:</span></b><span>
<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>n-sakimura<br>
<b>Sent:</b> Wednesday, October 30, 2013 8:19 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] Guidance on what
the different flows are for</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">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:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Wed, Oct 30, 2013 at 5:47 AM, Nat
Sakimura <<a moz-do-not-send="true"
href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
</p>
</div>
<div>
<p class="MsoNormal"><br>
Oct 30, 2013 20:04<span>、</span>John Bradley <<a
moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>>
<span>のメッセージ</span>:</p>
</div>
<div>
<blockquote>
<div>
<p class="MsoNormal">I like the table idea. </p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<p class="MsoNormal">Let's go that way. </p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
</p>
<div>
<p class="MsoNormal">Where do you see "Implicit Code
Flow"?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<p class="MsoNormal"><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></p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<p class="MsoNormal">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 . </p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
</p>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">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:</p>
</div>
<p class="MsoNormal"><br>
<br>
</p>
<div>
<div>
<p class="MsoNormal">"Implicit Code Flow"
is defined. Neither "Implicit Flow" nor
"Code Flow" is defined. <br>
And that is a very secondary point in my
email. <br>
What I pointed out was that perhaps a
table is better as a guidance. <br>
<br>
See my other email for the proposed
text. <br>
<br>
Nat<br>
<br>
<br>
(2013/10/30 15:42), Mike Jones wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">"Implicit Flow" is
defined in the Terminology section.</p>
</div>
<div class="MsoNormal">
<hr width="100%">
</div>
<p class="MsoNormal">From: n-sakimura<br>
Sent: 10/29/2013 9:51 PM<br>
To: <a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.net</a><br>
Subject: Re: [Openid-specs-ab] Guidance
on what the different flows are for</p>
<div>
<div>
<p class="MsoNormal">(2013/10/30
10:22), Mike Jones wrote:</p>
</div>
<blockquote>
<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>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">Several
reviewers have objected to this
text in <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> –
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>
<p class="MsoNormal"> </p>
</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>
<p class="MsoNormal">It does not have to
be native applications. <br>
We do not have to constrain code grant
for anything. <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. <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. <br>
<br>
Perhaps having tables like the
following is better as the guidance. </p>
<table class="MsoNormalTable">
<tbody>
<tr>
<td width="329">
<p class="MsoNormal">Conditions
/ Requirement</p>
</td>
<td width="85">
<p class="MsoNormal">code grant</p>
</td>
<td width="85">
<p class="MsoNormal">implicit
grant</p>
</td>
<td width="82">
<p class="MsoNormal">hybrid
grant</p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal">Server is
not directly reachable from
the client</p>
</td>
<td width="85">
<p class="MsoNormal"> </p>
</td>
<td width="85">
<p class="MsoNormal">x</p>
</td>
<td width="82">
<p class="MsoNormal"> </p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal">Want less
round trip</p>
</td>
<td width="85">
<p class="MsoNormal"> </p>
</td>
<td width="85">
<p class="MsoNormal">x</p>
</td>
<td width="82">
<p class="MsoNormal">x</p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal">Do not want
to reveal tokens for better
security</p>
</td>
<td width="85">
<p class="MsoNormal">x</p>
</td>
<td width="85">
<p class="MsoNormal"> </p>
</td>
<td width="82">
<p class="MsoNormal">(some)</p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal">Want client
authentication</p>
</td>
<td width="85">
<p class="MsoNormal">x</p>
</td>
<td width="85">
<p class="MsoNormal"> </p>
</td>
<td width="82">
<p class="MsoNormal">x</p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal">Want
refresh token</p>
</td>
<td width="85">
<p class="MsoNormal">x</p>
</td>
<td width="85">
<p class="MsoNormal"> </p>
</td>
<td width="82">
<p class="MsoNormal">x</p>
</td>
</tr>
<tr>
<td width="329">
<p class="MsoNormal">Slow front
channel, fast back channel</p>
</td>
<td width="85">
<p class="MsoNormal">x</p>
</td>
<td width="85">
<p class="MsoNormal"> </p>
</td>
<td width="82">
<p class="MsoNormal">x</p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><br>
The same table is uploaded here: <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. <br>
<br>
Nat<br>
<br>
<br>
<br>
</p>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">Would that
combination work for people?</p>
<div>
<p class="MsoNormal"> </p>
</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>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">Per the decision
at the F2F, all this “guidance” text
would move to the introduction.</p>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">Are people good
with the wording above, or would you
like to make alternative
suggestions?</p>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"> --
Mike</p>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<p class="MsoNormal"><br>
<br>
</p>
<pre>_______________________________________________</pre>
<pre>Openid-specs-ab mailing list</pre>
<pre><a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a></pre>
<pre><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>
<p class="MsoNormal"><br>
<br>
<br>
</p>
<pre>-- </pre>
<pre>Nat Sakimura (<a moz-do-not-send="true" href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>)</pre>
<pre>Nomura Research Institute, Ltd. </pre>
<pre><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" target="_blank">+81-3-6274-1547</a></pre>
<pre> </pre>
<pre><span>本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござ</span>ӓ</pre>
<pre> ;</pre>
<pre> 6;|</pre>
<pre>14;<span>せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。</span></pre>
<pre>PLEASE READ:</pre>
<pre>The information contained in this e-mail is confidential and intended for the named recipient(s) only.</pre>
<pre>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>
<p class="MsoNormal"><br>
<br>
<br>
</p>
<pre>-- </pre>
<pre>Nat Sakimura (<a moz-do-not-send="true" href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>)</pre>
<pre>Nomura Research Institute, Ltd. </pre>
<pre><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" target="_blank">+81-3-6274-1547</a></pre>
<pre> </pre>
<pre><span>本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござ</span>ӓ</pre>
<pre> 6;|</pre>
<pre>14;<span>せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。</span></pre>
<pre>PLEASE READ:</pre>
<pre>The information contained in this e-mail is confidential and intended for the named recipient(s) only.</pre>
<pre>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>
<p class="MsoNormal">_______________________________________________<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></p>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
<blockquote>
<div>
<p class="MsoNormal">_______________________________________________<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></p>
</div>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal"><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></p>
</div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"><br>
<br>
<br>
</p>
<pre>_______________________________________________</pre>
<pre>Openid-specs-ab mailing list</pre>
<pre><a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></pre>
<pre><a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<br>
</p>
<pre>-- </pre>
<pre>Nat Sakimura (<a moz-do-not-send="true" href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>)</pre>
<pre>Nomura Research Institute, Ltd. </pre>
<pre><a moz-do-not-send="true" href="Tel:+81-3-6274-1412">Tel:+81-3-6274-1412</a> Fax:+81-3-6274-1547</pre>
<pre> </pre>
<pre><span>本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござ</span>ӓ</pre>
<pre> 6;|</pre>
<pre>14;<span>せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。</span></pre>
<pre>PLEASE READ:</pre>
<pre>The information contained in this e-mail is confidential and intended for the named recipient(s) only.</pre>
<pre>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 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
本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
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>