<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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";}
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";}
span.EmailStyle19
{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";}
.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;}
/* List Definitions */
@list l0
{mso-list-id:676883200;
mso-list-template-ids:895250740;}
@list l0:level1
{mso-level-start-at:8;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:998071615;
mso-list-template-ids:346993572;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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 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 agree with John. “code id_token” is not implicit.<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">Pure Implicit flows don’t use the Token Endpoint. The hybrid flows do (returning content both from the authorization endpoint and the token 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">Compare the structure of 2.2 (Implicit) and 2.3 (Hybrid). They’re pretty different – exactly because the hybrid flows use both endpoints.<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 think we’d be doing a disservice to implementers to try to cram them together again. At that point, we might as well just have one “Messages” section, like
we had before.<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"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> John Bradley [mailto:ve7jtb@ve7jtb.com]
<br>
<b>Sent:</b> Monday, October 14, 2013 10:59 AM<br>
<b>To:</b> Nat Sakimura<br>
<b>Cc:</b> Mike Jones; openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] [OpenID board] OpenID Connect Specs Nearing Completion<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We have some terminology problems inherited from OAuth.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I don't think code+id_token is implicit. Implicit refers to a grant being implicit in the access token returned. It just happens to be that the example of that is fragment encoding in the spec, however using postmessage it would still
be implicit. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">code+id_token is by that definition not implicit while code+token is both implicit and explicit hybrid. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If you are making two categories then we have query parameter encoded response and everything else which is fragment encoded to prevent referrer_uri leaking information it should not.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">As a observation the code flow to a public client is also problematic as there is a possibility that a leaking referrer may reveal code to an attacker before the real client has a chance to use it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On 2013-10-14, at 2:39 PM, Nat Sakimura <<a href="mailto:nat@sakimura.org">nat@sakimura.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">2013/10/14 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Sorry – I’m just seeing this now, as the message got sorted into a folder other than my Inbox I was
working all day on issue resolutions and hadn’t checked it.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks for taking the time to start a detailed review Nat. That’s really important.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">At a meta level, I realize that not ever structuring decision in the draft that I produced is the
same as in the proof-of-concept versions you produced. We can talk about the differences and decide what changes we do and don’t want to make on the call tomorrow. For what it’s worth, often the differences are there to incorporate content that was present
in Messages or Standard that had been omitted from the draft that you produced, and to try to do so with a logical structure.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The terminology section is one such case. Your draft has only 12 term definitions.
</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That's so because I have cut down them for the code flow and did not re-incorporate other definitions while I concatenated the split version. For incorporating them, I thought it was important to group them by the chapters. So, the first
12 would have been under "code flow authentication", followed by the definitions for "implicit flow", and so on, so that if the implementer was only building the code flow authentication server, he needs to read only that section. I could have done it, but
I did not complete. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To make it less top heavy, we might want to move some of the terms to the specific sections. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The Core spec has 33 – all of them necessary. I didn’t adopt your convention of making giving every
term a section heading because with only 12 terms, the terminology already stretched across 3 pages, whereas all 33 definitions fit onto three pages in my draft. If we’re interested countering perceptions that the specs are too long, starting out with what
could be around 8 pages just for terminology seems like it would be self-defeating on our part. I’m not adamant about this, but given how long things already were when formatted as you did, I wanted to give the working group the choice first before changing
the terminology formatting and ordering.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Page length concern is legitimate, but your argument does not answer the ordering issues nor the separation of the definition and explanation text and the source indication. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Your draft had entirely left out the hybrid flows that are retained in Section 2.3.
</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In fact, it was subsumed in the implicit flow. The separation was whether the authorization endpoint response was returned in the query parameter or the fragment. For "code token" and "code id_token" and "code token id_token", just adding
the token endpoint to the implicit flow section and pointing it to the code flow is enough. I would drop the Hybrid flows section as an independent section. That would cut down about 4 pages. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Yes, Code, Implicit, and Hybrid could have been Sections 2, 3, and 4, rather than 2.1, 2.2, and 2.3,
but it makes more logical sense to have one section on Authentication with three subsections describing the alternative ways to do it, than opening the document with three different top-level sections – all about the same topic. Again, it doesn’t have to
stay this way, but I tried to have the document have as logical a structure as possible – even if it wasn’t exactly the same as what you proposed.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What was rather important was that we could just point out that if you want code flaw authentication, then you can just implement section 3. In my version, each top level section was separate specs in essence. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">IMHO, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="http://nat.sakimura.org/wp-content/uploads/2013/08/openid-connect-all-1_0.html#anchor7"><b><span style="font-family:"Verdana","sans-serif";color:#663333">3.</span></b></a><b><span style="font-family:"Verdana","sans-serif""> Authentication
- Code Flow<br>
</span></b><a href="http://nat.sakimura.org/wp-content/uploads/2013/08/openid-connect-all-1_0.html#anchor11"><b><span style="font-family:"Verdana","sans-serif";color:#663333">4.</span></b></a><b><span style="font-family:"Verdana","sans-serif""> Authentication
- Implicit Flows</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">is much more visually clear than<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-connect-core-1_0-13.html#Authentication"><b><span style="font-family:"Verdana","sans-serif";color:#663333">2.</span></b></a><b><span style="font-family:"Verdana","sans-serif""> Authentication<br>
</span></b><a href="http://openid.net/specs/openid-connect-core-1_0-13.html#CodeFlowAuth"><b><span style="font-family:"Verdana","sans-serif";color:#663333">2.1.</span></b></a><b><span style="font-family:"Verdana","sans-serif""> Authentication using the
Authorization Code Flow<br>
</span></b><a href="http://openid.net/specs/openid-connect-core-1_0-13.html#ImplicitFlowAuth"><b><span style="font-family:"Verdana","sans-serif";color:#663333">2.2.</span></b></a><b><span style="font-family:"Verdana","sans-serif""> Authentication using
the Implicit Flow<br>
</span></b><a href="http://openid.net/specs/openid-connect-core-1_0-13.html#HybridFlowAuth"><b><span style="font-family:"Verdana","sans-serif";color:#663333">2.3.</span></b></a><b><span style="font-family:"Verdana","sans-serif""> Authentication using the
Hybrid Flow</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Also, about section depth, to really understand your document structure, I had to rebuild it with
tocdepth=”4” (showing 4 levels of section structure in the table of contents), rather than 2. People can view the resulting docs here
<a href="http://self-issued.info/misc/openid-connect-all.html" target="_blank">http://self-issued.info/misc/openid-connect-all.html</a> and here
<a href="http://self-issued.info/misc/openid-connect-all.txt" target="_blank">http://self-issued.info/misc/openid-connect-all.txt</a>. For instance, your table of contents wasn’t showing any of the structure under Authorization Endpoint or Token Endpoint.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I was not talking about the toc depth but pointing out that request parameter list being the 5 levels deep is a bit excessive. I used 2 as the depth since that would give a better overall picture to the readers rather than going into the
details. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As to the toc itself is concerned, even with tocdepth="4", my version gives visually clearer structure to the users, IMHO. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While I am on the structure, one of the thing I did was to group the responses: i.e., create a section called xxxx Response and put "successful response" and "error response" as a pair. This is IMHO cleaner again than just talk about "response"
and then have "error response" as a subsection as it is more symmetric. <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">About the detail with “Authorization Request Parameters” being described in a subsection of the “Authorization
Request section”, that makes logical sense, but we could flatten it one level or drop the header if people are adamant about it. (Or we could simply build with tocdepth=”4” and not show it in the table of contents. All we’d be leaving out would be the “Authorization
Request Parameters” headings under “Authorization Request”, which wouldn’t confuse anybody.)</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Again, I am not talking about tocdepth. I would flatten it. The content of the Authorization Request section is nothing but the explanation leading to the parameters. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Also, I would put the examples after the parameters, as the examples are non-normative explanation about the parameters use. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I don’t care whether we make “scope” the first parameter described or “response_type”. Both are
important behavioral switches.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">IMHO, "scope" is the first switch in terms of the OpenID Connect. If the scope does not have "openid" in it, all the other processing stops. It is the first thing that the program checks. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I disagree with some of your proposed text for “scope”. The “openid” scope does a lot more than
just request an ID Token. It declares that the Authorization Request is an OpenID Connect Authentication Request, which brings in a lot more meaning than just requesting an ID Token. (That’s just a side effect.) We shouldn’t confuse people by letting them
think that that’s all the “openid” scope does. I’ll note that the sentence you introduced (starting “This scope value requests ID Token…”) was in neither Messages nor Standard.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">ID Token is not a side effect. This is the main effect in the authentication. Unfortunately, it has not been clear for the reader till now. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">At the very least, drop "<span style="font-family:"Verdana","sans-serif"">Space delimited, case sensitive list of ASCII OAuth 2.0 scope values." and "Other scope values MAY be present." since it is clear from the RFC6749. Also, I would
drop the reference for 4.1 etc. here, since we are to talk only about authentication here. Anything but the pure authentication related things has to be dropped. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">So, if you do not want to talk about ID Token etc., then it would become: </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">scope<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Verdana","sans-serif"">REQUIRED. The value MUST contain the </span><tt><span style="font-size:10.0pt;color:#003366">openid</span></tt><span style="font-family:"Verdana","sans-serif"">. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">instead of the current text: </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">scope<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Verdana","sans-serif"">REQUIRED. Space delimited, case sensitive list of ASCII OAuth 2.0 scope values. OpenID Connect requests MUST contain the </span><tt><span style="font-size:10.0pt;color:#003366">openid</span></tt><span style="font-family:"Verdana","sans-serif""> scope
value. Other scope values MAY be present. See Sections <a href="http://openid.net/specs/openid-connect-core-1_0-13.html#ScopeClaims"><b><span style="color:#663333;text-decoration:none">4.1</span></b></a> and <a href="http://openid.net/specs/openid-connect-core-1_0-13.html#OfflineAccess"><b><span style="color:#663333;text-decoration:none">10</span></b></a> for
additional scope values defined by this specification.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Verdana","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">Note: We are just talking about pure authentication here. Since it is a pure authentication, we do not talk about claims. Thus, only the scope defined in this spec here is </span><span style="font-family:"Courier New";color:#003366">openid</span><span style="font-family:"Verdana","sans-serif"">.
It's effect is to return ID Token. (Is there anything else here?) That's why my text came to be: </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">scope<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Verdana","sans-serif"">REQUIRED. The value MUST contain the </span><tt><span style="font-size:10.0pt;color:#003366">openid</span></tt><span style="font-family:"Verdana","sans-serif"">.
This scope value requests ID Token, which is a JWT that includes the Claims about the End-User Authentication event.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">I raised scope just as an example for wordiness. Other parameters like response_type follows the same pattern. For example compare between: </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">response_type<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Verdana","sans-serif"">REQUIRED. The value MUST be </span><tt><span style="font-size:10.0pt;color:#003366">code</span></tt><span style="font-family:"Verdana","sans-serif"">.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">and </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">response_type<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Verdana","sans-serif"">REQUIRED. OAuth 2.0 registered response type value that determines how the Authorization Response is returned to the Client. When using the Authorization Code Flow,
this value MUST be </span><tt><span style="font-size:10.0pt;color:#003366">code</span></tt><span style="font-family:"Verdana","sans-serif"">.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The section is just talking about the case where the value is "code". Most of the text here is superfluous, so we should adopt the former. <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’m fine deleting the “Space delimited, case sensitive list of ASCII OAuth 2.0 scope values.” from
the scope definition.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’m not following your point about 2.1.2.4, but I can easily believe that there’s still text that
we want to relocate. (For instance, the current draft -14, which you can view at
<a href="http://openid.bitbucket.org/openid-connect-core-1_0.html" target="_blank">
http://openid.bitbucket.org/openid-connect-core-1_0.html</a>, moved some vestigial Self-Issued text that used to be in Section 2.) What specific changes do you want to see made to 2.1.2.4?</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal">I am asking to remove anything but strictly authentication related things from the section. This section is talking about pure authentication. Current text is too broad. It talks about "authorization" in general, including that for the
claims.In addition, a lot of text is repeated from the earlier section. For example, text from the explanation of prompt parameters are repeated here as well as the text from 2.1.2.3. We should remove these. What would be left after removing the dupplicate
text and something that are not strictly authentication? My gut feeling is that we can completely drop 2.1.2.4. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I hate the word “framework” in your proposed title “Claims Framework” because it doesn’t really convey
the right meaning. A framework is something you use as a template or structure to build something more specific, which isn’t what we’re doing here.
</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">It does not have to. According to Webster: <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Verdana","sans-serif";background:#E8ECF5">the basic structure of something</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">and according to <a href="http://OxfordDictionaries.com">OxfordDictionaries.com</a>: <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Georgia","serif";color:#333333">a basic structure underlying a system, concept, or text</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A framework has to allow something to be built upon and extended, but it could be useful as is. What we have here is exactly this. <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’m open to other titles than just “Claims”, however. “Claims Mechanisms” is clunky, but would at
least be correct. I’m sure we can come up with something we all like on the call. (BTW, if you replace, “a framework” with “mechanisms” in your introductory sentences, I think they work.)</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The order of the Claims subjections are related to the likelihood of implementers actually using
them. So claims scopes, standard claims, and UserInfo come first. Then “claims_locales”. Then the “claims” request parameter. Then aggregated and distributed claims. Other orders are possible, but that was my rationale.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal">I would rather have a logical structure. Your described way of building the system is only one way of doing it. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It could be completely reverse that the implementer may build claims request parameter and build scopes as the alias to them. (e.g., expanding the scope values to the claims request parameters and process it: it seems like a more logical
and less duplicating way of coding.) <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">So, listing out the different ways of requesting claims and going into the details about claims seems to be more appropriate. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Anyway, thanks again for starting your review. I’m sure we’ll make progress on lots of these things
during the call. Talk to you then!</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal">Welcome. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I will try to call in but my internet connection here during my vacation in Taipei is not so good so I may have some difficulty there. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:openid-board-bounces@lists.openid.net" target="_blank">openid-board-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-board-bounces@lists.openid.net" target="_blank">openid-board-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Nat Sakimura</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<b>Sent:</b> Sunday, October 13, 2013 11:13 AM<br>
<b>To:</b> <a href="mailto:openid-connect-interop@googlegroups.com" target="_blank">
openid-connect-interop@googlegroups.com</a><br>
<b>Cc:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>;
<a href="mailto:board@openid.net" target="_blank">board@openid.net</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><b>Subject:</b> Re: [OpenID board] OpenID Connect Specs Nearing Completion<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thank you very much, Mike. <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">It is a great work. Having said that, <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I have some comments on it. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
The terminology section is not assuming the agreed upon structure as in <a href="http://nat.sakimura.org/wp-content/uploads/2013/08/openid-connect-all-1_0.html" target="_blank">http://nat.sakimura.org/wp-content/uploads/2013/08/openid-connect-all-1_0.html</a> [1].
Note that the order of the terms in [1] is not alphabetical but in the semantic order: i.e., the term that is used in the text appears before it. Also, it is separating out the definition text and the notes. That is adding to the readability of the text greatly.
It is also showing where it came from. <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
The agreed upon structure is much less deep. It was one of the main consideration in restructuring. It is adding to the ease for grasping the structure. For example, in your version, it is "<a href="http://openid.net/specs/openid-connect-core-1_0-13.html#ImplicitRequestParameters" target="_blank"><span style="font-family:"Verdana","sans-serif";color:#663333">2.2.2.1.1.</span></a><span style="font-family:"Verdana","sans-serif"">
Authorization Request Parameters" while in [1], it is "</span><span style="font-family:"Helvetica","sans-serif";color:#333333">3.1.1. Request Parameters". </span><o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
<span style="font-family:"Verdana","sans-serif"">As to the order of the request parameters are concerned, I have placed 'scope' at the top since it acts as the switch between OpenID call and pure OAuth call. This would definitely help the user when writing
the code. </span><o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
<span style="font-family:"Verdana","sans-serif"">For the definition of 'scope', I change the text as follows to make it clear that it is stating about the value. <br>
<br>
REQUIRED. The value MUST contain the </span><tt><span style="font-size:10.0pt;color:#003366">openid</span></tt><span style="font-family:"Verdana","sans-serif"">. This scope value requests ID Token, which is a JWT that includes the Claims about the End-User
Authentication event.<br>
<br>
Your text is: <br>
<br>
REQUIRED. Space delimited, case sensitive list of ASCII OAuth 2.0 scope values. OpenID Connect requests MUST contain the </span><tt><span style="font-size:10.0pt;color:#003366">openid</span></tt><span style="font-family:"Verdana","sans-serif""> scope value.
Other scope values MAY be present. See Sections </span><a href="http://openid.net/specs/openid-connect-core-1_0-13.html#ScopeClaims" target="_blank"><b><span style="font-family:"Verdana","sans-serif";color:#663333;text-decoration:none">4.1</span></b></a><span style="font-family:"Verdana","sans-serif""> and </span><a href="http://openid.net/specs/openid-connect-core-1_0-13.html#OfflineAccess" target="_blank"><b><span style="font-family:"Verdana","sans-serif";color:#663333;text-decoration:none">10</span></b></a><span style="font-family:"Verdana","sans-serif""> for
additional scope values defined by this specification.<br>
</span><br>
Here, at least "Space delimited, case sensitive ... " is superfluous since it is already defined in RFC6749. The former also describes the effect of this scope, while the later does not. <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
This version still has claims authorization components in 2.1.2.4. <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
The "4. Claims" is not describing only about what is claims but also how the claims are to be requested and received. That's why [1] is using the chapter name "Claims Framework." I think this title is more appropriate, and has been agreed upon in the WG. <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Accordingly, the description about this chapter should also be strengthend. Your version states:
<br>
<br>
<span style="font-family:"Verdana","sans-serif""> This section specifies how the Client can obtain Claims about the End-User and defines a
<br>
standard set of basic profile Claims.<br>
<br>
while [1] states:</span><o:p></o:p></li></ol>
<p style="mso-margin-top-alt:5.0pt;margin-right:24.0pt;margin-bottom:5.0pt;margin-left:60.0pt">
<span style="font-family:"Verdana","sans-serif"">This section defines a framework in which the client may obtain the claims about the End User. It can be done through the pre-defined scopes values or through more granular claims parameter. The claims can come
from a single source or distributed sources as well.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:.5in">
<a name="141b636937632813_anchor15"></a><span style="font-family:"Verdana","sans-serif"">The later, IMHO, is clearer. </span><o:p></o:p></p>
<ol start="8" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
Again, "4. Claims" is not assuming the order of the agreed upon structure. 4.5 should be moved before 4.2. <o:p></o:p></li></ol>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Regards, <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Nat<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">2013/10/13 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I posted this note at
<a href="http://self-issued.info/?p=1137" target="_blank">http://self-issued.info/?p=1137</a> and on Twitter as @selfissued to raise awareness that the time to do a final review of the OpenID Connect specs is now.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> -- Mike<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>OpenID Connect Specs Nearing Completion</b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Based on feedback from developers, the
<a href="http://openid.net/connect/" target="_blank">OpenID Connect</a> working group decided to replace the
<a href="http://openid.net/specs/openid-connect-messages-1_0-20.html" target="_blank">
OpenID Connect Messages</a> and <a href="http://openid.net/specs/openid-connect-standard-1_0-21.html" target="_blank">
OpenID Connect Standard</a> specifications with a new <a href="http://openid.net/specs/openid-connect-core-1_0-13.html" target="_blank">
OpenID Connect Core</a> specification that combines the contents from both of them before finishing OpenID Connect. The content has also been restructured to separate Authentication from other features such as Claims and to have separate Authentication sections
for the different OAuth 2.0 flows. No changes to the protocol were made. The publication of this new spec is another major step towards finishing OpenID Connect.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>Please review this and the other OpenID Connect specifications in the coming week.</b> While a few local changes will still be made this week to address
<a href="https://bitbucket.org/openid/connect/issues?status=new&status=open&sort=-id" target="_blank">
issues that have been identified</a> since <a href="http://self-issued.info/?p=1095" target="_blank">
the approval of the Implementer’s Drafts</a>, I fully expect that the working group will decide at the
<a href="http://openid-wg-oct-2013.eventbrite.com/" target="_blank">in-person working group meeting</a> just over a week from now that it’s time to publish proposed final specifications.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks to Nat Sakimura for producing a<a href="http://nat.sakimura.org/2013/08/27/refactoring-openid-connect-drafts/" target="_blank"> proof-of-concept document restructuring</a>
that the structure of the current <a href="http://openid.net/specs/openid-connect-core-1_0-13.html" target="_blank">
OpenID Connect Core</a> spec is based upon. And thanks to Torsten Lodderstedt for convincing us that the specs will be clearer by better separating the descriptions of logically distinct features while combining previously separate descriptions of highly interrelated
functionality.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#888888"> </span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#888888">--
<br>
You received this message because you are subscribed to the Google Groups "OpenID Connect Interop" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to
<a href="mailto:openid-connect-interop%2Bunsubscribe@googlegroups.com" target="_blank">
openid-connect-interop+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank">
https://groups.google.com/groups/opt_out</a>.</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--
<br>
Nat Sakimura (=nat)<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>