<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Thanks so much Mike!<br>
<br>
For comment 5-1: Text in the current spec is...<br>
</font>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<blockquote><font face="Helvetica, Arial, sans-serif">The OpenID
Connect Core 1.0 specification defines the core OpenID Connect
functionality: authentication built on top of OAuth 2.0 and the
use of Claims to communicate information about the End-User. It
also describes the security and privacy considerations for using
OpenID Connect.<br>
</font></blockquote>
<font face="Helvetica, Arial, sans-serif">I don't know that it
matters much, or if it's any better... but here is an alternate
option.<br>
</font>
<blockquote><font face="Helvetica, Arial, sans-serif">The OpenID
Connect Core 1.0 specification defines the core OpenID
Connection functionality which is to provide an authentication
layer built on top of OAuth2 with the additional capability to
communicate information about the End-User via the use of
Claims.<br>
</font></blockquote>
<font face="Helvetica, Arial, sans-serif">For 15-2 my main point was
that interaction_required is probably a better return error than
the other that are more specific and can leak information
(multiple authenticated sessions) about the user's current state.
To me, session_selection_required and consent_required are
sub-error codes of interaction_required. In some ways,
login_required also falls into this category. I can't think of why
we need the more specific errors but as long as our OP doesn't
need to use them, it's fine to leave them in the spec:)<br>
<br>
Thanks,<br>
George<br>
</font><br>
<br>
<div class="moz-cite-prefix">On 11/13/13 1:28 PM, Mike Jones wrote:<br>
</div>
<blockquote
cite="mid:4E1F6AAD24975D4BA5B168042967394377E7D906@TK5EX14MBXC287.redmond.corp.microsoft.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
/* 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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The
version of Core at
<a moz-do-not-send="true"
href="http://openid.bitbucket.org/">http://openid.bitbucket.org/</a>
now incorporates your review comments, George. Here’s a few
responses to questions you asked and notes on the
resolutions.<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">I
didn’t do 5-1 because you didn’t suggest alternative wording
and I didn’t think of anything better either.<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">6-1
was replaced by the wording in the thread “[Openid-specs-ab]
Definition of Authentication”.<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">7-1:
Yes, the whole issuer is case sensitive.<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">7-2
will be addressed by moving the ID Token definition to
earlier in 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>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">15-1:
Yes, I believe that you’d be conformant by returning
interaction_required.<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">15-2:
Do you want to propose alternative wording? It’s not clear
to me what’s unclear.
</span><span
style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">24-3:
Please review the new text at
<a moz-do-not-send="true"
href="http://openid.bitbucket.org/openid-connect-core-1_0.html#NonceNotes">http://openid.bitbucket.org/openid-connect-core-1_0.html#NonceNotes</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>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">25-1:
Yes<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">32-1:
Because “code token” doesn’t return an ID Token from the
Authorization Endpoint<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">34-1:
Because “code token” doesn’t return an ID Token from the
Authorization Endpoint<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">Thanks
again for the useful review, George!<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">
<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>George Fletcher<br>
<b>Sent:</b> Monday, October 21, 2013 9:45 AM<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> [Openid-specs-ab] Comments on core
through section 2.3<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span
style="font-family:"Helvetica","sans-serif"">I
did my review on the plane using my iPad and a PDF
annotation app called 'GoodReader'. I've attached a marked
up PDF as well as general text summary. I'd use the PDF as
it provides more context:) I can move to the other specs
Mike if you'd prefer.<br>
<br>
Thanks,<br>
George</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:10.0pt">See file attached to this
message<br>
<br>
File: OpenID Connect Core 1.0 - draft 14 -
flattened.pdf<br>
<br>
Annotation summary:<br>
<br>
--- Page 5 ---<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
authentication built on top of OAuth 2.0 and the use
of Claims to communicate information about the
End-User.<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
This wording doesn't flow well. I should suggest
something better. </span><b><span
style="font-size:10.0pt;color:red">If others agree,
I'll work on a suggestion.</span></b><span
style="font-size:10.0pt"><br>
<br>
<br>
<br>
--- Page 6 ---<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
what the entity knows, possesses, has as physical
features, or behaviors, or combinations of these
utilizing heuristics.<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Suggest: what the entity knows, possesses, behavior
patterns, has as physical features, or combinations of
these utilizing heuristics.<br>
<br>
<br>
--- Page 7 ---<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Is the intent that the whole Issuer Identifier is case
sensitive? Or just the path component as per normal
URLs?<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
case sensitive URL<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Maybe a forward reference to 2.1.3.6 would be helpful
here?<br>
<br>
<br>
--- Page 9 ---<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
subject identifier<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Subject identifier is not capitalized. Should it be?<br>
<br>
<br>
--- Page 10 ---<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
the<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
The -> a<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
When using this flow, the redirection URI MAY use the
http scheme, provided that the Client Type is
confidential, as defined in Section 2.1 of OAuth 2.0;<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
This special exception is confusing. I almost wonder
if it could be added to the security considerations
and then the text here is... MUST except for the case
x.x.x.x in Security Considerations. Another case where
the will not be http or https is a mobile client
implementing the code flow.<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Is this use of 'nonce' in addition to that described
in the validation steps for the hybrid flow? Or a
different method of doing the same thing?<br>
<br>
<br>
--- Page 12 ---<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
audience<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
This is the first use of 'audience' in conjunction
with the id_token. It might not make sense to someone
just reading the specs without any other context.
Maybe add a reference to the id_token processing rules
section?<br>
<br>
<br>
--- Page 13 ---<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
This is confusing. If I specify a id_token_hint and
ask for the 'sub' claim then the AS must not response
with a successful response if the user doesn't match
the id_token_hint. However, if I don't ask for a sub
claim then the AS can return an successful response
where the id_token doesn't match the id_token_hint?<br>
<br>
<br>
--- Page 15 ---<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
interaction_required<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
What case is this covering that isn't already covered
by the other *_required error codes? Is my OP
compliant if I only return I the interaction_required
error even if the case is a login_required?<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Not sure the reg error makes sense.<br>
<br>
<br>
--- Page 22 ---<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
Multiple audiences are not supported for MAC based
algorithms.<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Why not? Wouldn't the secret associated with the azp
work for the client to validate the id_token?<br>
<br>
If we want interoperability across the use of audience
and azp we are going to need to describe how it works
in an extension document. It is not clear from this
spec how it is to work and I was on most of the
calls:)<br>
<br>
<br>
--- Page 23 ---<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
the<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
The -> in the<br>
<br>
<br>
--- Page 24 ---<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
We say the same thing three different times. Once in
2.2.2 and twice in 2.2.2.1<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
When using this flow, the redirection URI MUST NOT use
the http scheme unless the Client is a native
application, in which case it MAY use the http: scheme
with localhost as the hostname.<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
I'm not sure we got these examples correct. Native
application can be both mobile or rich desktop. In the
mobile case it is most likely the scheme will not be
http related at all. I suppose in either case the
client could be running a local web server and use it
to load the JS to process the fragment. Maybe the real
question is wether local host should be allowed in the
code flow.<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
I'm not sure this suggestion makes sense for the
implicit flow. The client would need to write a cookie
value on the domain of the redirect_uri and the
attempt to read it on the return of the implicit flow.
Wondering if a local storage example would make more
sense.<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
One method to achieve this is to store a random value
as a signed session cookie, and pass the value in the
nonce parameter. In that case, the nonce in the
returned ID Token can be compared to the signed
session cookie to detect ID Token replay by third
parties.<br>
<br>
<br>
--- Page 25 ---<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Did we chose the negative constraint here to leave the
door open for other types? If not a positive
constraint is easier to understand. Something like
"this is only returned when the response_type is
'id_token token'"<br>
<br>
<br>
--- Page 29 ---<br>
<br>
Highlight (yellow), Oct 20, 2013, 5:27 PM, George
Fletcher:<br>
No Access Token is returned when the value is
id_token.<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
I don't think this is necessary as 'id_token' is not
one of the allowed response_type values. Or maybe it's
supposed to be 'code id_token'?<br>
<br>
<br>
--- Page 32 ---<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Why not also the 'code token' flow?<br>
<br>
<br>
--- Page 34 ---<br>
<br>
Note (yellow), Oct 20, 2013, 5:27 PM, George Fletcher:<br>
Why isn't the id_token returned in the 'code token'
case as the scope requires an 'openid' value which
ensures that the response from the token endpoint
includes an id_token.<br>
<br>
<br>
(report generated by GoodReader)<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://connect.me/gffletch" title="View full card on
Connect.Me"><img src="cid:part3.02020308.06010005@aol.com"
alt="George Fletcher" height="113" width="359"></a></div>
</body>
</html>