<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: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";}
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";}
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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{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-family:"Calibri","sans-serif";}
@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:775907191;
mso-list-type:hybrid;
mso-list-template-ids:-413762714 -1725811948 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:1870;
mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
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'>Nat,<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'>Once again, thanks for taking time to write up the procedures so it’s easier to digest. This definitely gives me a better level of comfort with respect to the overall complexity.<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'>The “discovery” part is specified as otional on openid.net/connect. Section 2 of the discovery spec seems to suggest it is conditionally mandatory (“if a Relying Party knows the OP information through an out-of-band mechanism, they can skip this step”). Is there a statement anywhere that says that RPs must implement discovery if they do not have a relationship with the OP? To ensure any new mechanism will work on the Internet at large, I really would want discovery to be mandatory. Quite frankly, I’m growing tired of visiting web sites that only allow me to log in using a few select web sitess. I do not trust Facebook, for example, any more than I could throw the 500 pound gorilla. (That’s not intended to be so strong against FB, per se, but I want to emphasize how important trust is and social networking sites, search engines, web directories, etc. are not in the business of security one’s identity. We need to ensure there is a viable business opportunity for companies that I could place trust in, if not my own servers.)<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'>There are still a number of specs that make up OpenID Connect. Of course, if I read through them all, my questions would be addressed, but I think it might be useful to document why and how each of those referenced specs are used. For example, JWS… why? If OpenID Connect mandates TLS, why is a signature required? I’m even more bewildered over the requirement for anything labeled “encryption” (JWE) given communication is over an encrypted channel. In OpenID 2.0 one hashes values and signs responses, etc. because TLS was an option (I assume).<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'>Another issue that I’m struggling with, which actually was brought my attention to the fact that the OpenID Connect specs was published, is the use of SWD. Several years ago, I asked the question on one of the OpenID lists why we did not use email IDs. (I never was a big fan of the OpenID IDs, but I appreciated their value. I still agree with proponents there that they have value. Not everyone has an email address, nor does everyone want to use an email address when logging into places.) It was far too late to move away from URI identifiers, but I asked about mapping to them using an email address. I believe dung was hurled in my face. :-) Sometime later, I asked again and the group was much more receptive to the idea, apparently having had discussions along these lines so many times and starting to see to the benefit for adoption purposes. The second time, I was told “go look at WebFinger.” I did. I was thrilled to sww RFC 6415 published, as it would allow the mapping of email IDs to OpenID identifiers. For OpenID Connect, WebFinger can be used in the discovery process just as SWD is being proposed to do.<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'>So, if one issued this request:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'>GET /.well-known/host-meta.json?resource=acct:paulej%40packetizer.com&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'>HOST packetizer.com</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'>One would get back the following (if I had an OpenID Connect entry):<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:9.0pt;font-family:"Courier New";color:#1F497D'>{<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'> "subject" : "acct:paulej@packetizer.com",<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'> "links" :<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'> [<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'> {<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'> "rel" : "http://openid.net/specs/connect/1.0/issuer",<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'> "href" : "https://server.example.com"<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'> }<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";color:#1F497D'> ]<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New";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'>The “resource” parameter is relatively new (not in RFC 6415) as is the acct URI scheme, but both have been proposed for a while. They are both in the current WebFinger draft. The “rel” parameter is also new and still under discussion (not yet published). It effectively filters the reply so that only link relations in the “rel” parameter are returned. Since it’s merely a filter, there is still the question of usefulness. It’s simply enough to walk through the list of returned link relations, as it’s just an array. Also, there is always the possibility that an account might have multiple OpenID OPs associated with it or multiple values for any given link relation (e.g., I might have multiple blogs or multiple picture sharing sites or multiple you-name-it). So, requesting entities must always enumerate the list, anyway.<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'>Everything else, though, is already documented in RFC 6415, including production of both XML and JSON for those wanting to perform discovery. So, it concerns me to see that we have a second largely (if not entirely) redundant discovery mechanism proposed.<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'>As a note on use of the email address for discovery, one could query an email address (as shown in your examples) and we had a lot of debate over that. It was generally decided that in order to serve as a generic discovery mechanism for anything owned by the domain, a scheme is needed. My own WebFinger server will actually respond to “paulej@packetizer.com” (since Blaine Cook seemed to have that preference at one time – not sure of his opinion now), but a URI scheme should be used to ensure that the correct resource is referenced. The “acct” scheme was proposed to take address the need to ensure all entities are identified properly and to address the fact that some users would not be using an email address, per se, though the form of acct URIs look like email addresses and might very well be the same character string. That is done for the benefit of humans.<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'>So, was SWD introduced out of concern over WebFinger complexity? Or was it unknown? SWD looks simple enough, but definitely no less simple than WebFinger, from what I can tell, except perhaps the “SWD_service_redirect” construct. I’m not sure why that would be used over 3xx. Otherwise, they appear to be comparable in function and complexity, so I would recommend using what’s already in RFC 6415. If making two queries (following LRDD) is a concern, then help to push the current WebFinger draft through so we can address that issue with the resource parameter. OpenID Connect could require support of the “resource” (and perhaps “rel”) parameter.<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'>Paul<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 style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><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"'> Nat Sakimura [mailto:sakimura@gmail.com] <br><b>Sent:</b> Saturday, March 31, 2012 1:06 AM<br><b>To:</b> Paul E. Jones<br><b>Cc:</b> Mike Jones; specs@openid.net; board@openid.net; gsalguei@cisco.com<br><b>Subject:</b> Re: Implementer's Drafts posted with -ID1 version designations<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Paul, <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>For a simple "Authentication" only case for a Web server (RP, client), then you really do not need most of them. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I wrote a blog post for such a case. <o:p></o:p></p></div><div><p class=MsoNormal>It should not take more than 10 minutes to write a basic RP authentication. <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/2012/03/31/openid-connect-stripped-down-to-just-authentication/">http://nat.sakimura.org/2012/03/31/openid-connect-stripped-down-to-just-authentication/</a> <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Cheers, <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Nat<o:p></o:p></p><div><p class=MsoNormal>On Sat, Mar 31, 2012 at 5:34 AM, Paul E. Jones <<a href="mailto:paulej@packetizer.com">paulej@packetizer.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='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='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>I appreciate the pointer. As one who has written tons of specs, the language of a spec does not bother me, though I nonetheless appreciate any document that explains things in narrative form, of course.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Even after reading that document, though, I feel no less easy about OpenID Connect. It’s not that there is a <i>specific</i> change I can propose, though.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>I would start go to the core of the spec and start there. Why build it on top of OAuth? I like OAuth and it has a useful purpose. It was intended to allow Party A to get access to resources at Party B, with the user being in a position to grant such access. OpenID has a different purpose. When I log into a web site using OpenID, the visited web site only wants to verify that I am who I claim to be. The scope of OpenID is narrow and simple. As I said, there were some pain points that we could address, but fundamentally, it’s simple.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>OpenID Connect goes far beyond the original purpose of OpenID. Perhaps a reason for using OAuth is to grant access to get additional information related to the user (e.g., name, picture, address, etc.)? However, that is mixing different problems. My ability to log into a web site and that web site being able to access information about me that I store elsewhere are different problems that should not be merged into one. (That said, I have no objection to allowing certain information to be conveyed as a part of any OpenID exchange, much as there is in OpenID 2.0. The user can control and limit that information, but even then we should be careful to not go too far in mixing discovery of information about a user with the function of authenticating a user so they can log into a site.)</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Next, is the size of the set of specs. In addition to the pile of specs you have listed below, there are also other specs that <i>appear</i> to be required, including JWT, JWS, JWE, JWA, JWK, and SWD. All of that is an impressive body of work, but it is also a hell of a lot of stuff to build in order to implement something that should be a simple login mechanism. How long would it take to read all of this stuff and implement it? By comparison, I implemented an OpenID 2.0 OP server in less than a day, adding 1.1 support too. I picked up the OpenID 2.0 spec, read it, and implemented what it said.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>So, I’m left with no specific recommended changes. I just think the work has gone in the wrong direction. It appears overly complex for the problem at hand, with a scope that stretches far beyond what OpenID intended to do. I’m very supportive of OpenID and would be thrilled to see OpenID as a single login mechanism across the web, but I really think we have to have something simpler. The push back on OpenID 2.0 was over complexity, largely for the RP code. Why not just work to make it simpler? Of course, I might be wrong in thinking this is going to turn a lot of people off, but I don’t think so. I don’t want to go implement all of this stuff. :-/</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Paul</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><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"'> Mike Jones [mailto:<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>] <br><b>Sent:</b> Friday, March 30, 2012 1:27 PM<br><b>To:</b> Paul E. Jones; <a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a></span><o:p></o:p></p><div><div><p class=MsoNormal><br><b>Cc:</b> <a href="mailto:board@openid.net" target="_blank">board@openid.net</a>; <a href="mailto:gsalguei@cisco.com" target="_blank">gsalguei@cisco.com</a><br><b>Subject:</b> RE: Implementer's Drafts posted with -ID1 version designations<o:p></o:p></p></div></div></div></div><div><div><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'><span style='color:#1F497D'>The specs are written in normative spec language, but they still describe a process that’s very simple at it’s core. Have a look at <a href="http://nat.sakimura.org/2012/01/20/openid-connect-nutshell/" target="_blank">http://nat.sakimura.org/2012/01/20/openid-connect-nutshell/</a>, which is written as a primer, rather than in spec language. After that, I think you’ll agree that what’s there is actually quite simple to use.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>If you still disagree, then we’d be interested in hearing what specific changes you’d suggest that we make.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='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='color:#1F497D'> </span><o:p></o:p></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><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"'> Paul E. Jones <a href="mailto:[mailto:paulej@packetizer.com]" target="_blank">[mailto:paulej@packetizer.com]</a> <br><b>Sent:</b> Friday, March 30, 2012 10:17 AM<br><b>To:</b> Mike Jones; <a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a><br><b>Cc:</b> <a href="mailto:board@openid.net" target="_blank">board@openid.net</a>; <a href="mailto:gsalguei@cisco.com" target="_blank">gsalguei@cisco.com</a><br><b>Subject:</b> RE: Implementer's Drafts posted with -ID1 version designations</span><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><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Gee, guys… I think something has gone terribly wrong here. I was really excited about OpenID, believing it was a very important technology. Further, OpenID was fairly simple. One part was complex: the client code for the RP had to deal with querying the user’s ID, looking for a Yadis file, and possibly digging through an HTML document – all in an effort to find the URI for the user’s OP. The OP code, on the other hand, is fairly trivial.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>OpenID 2.0 could have been simplified easily be removing the requirement for processing a Yadis file and HTML document and replacing that with a simple Link header in HTTP. One could also use RFC 6415 (Host-Meta) to make it simple to advertise one’s OpenID ID (a “challenge” for the average person to use) and even the OP URI (though perhaps not so beneficial).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>I wanted to get engaged in the work, but getting Cisco to sign agreements, especially when this was not my core job function, was a bit of a challenge. So, the work proceeded without me. It’s unfortunate, because my initial reaction to what I’ve seen is ... what happened?!?!</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>OpenID Connect was supposed to be simple. That was one of the claim made when it was introduced. Looking at these drafts, I’d argue that “simple” has been thrown out the window, in spite of the claim “simple” in the abstract of these documents. Perhaps it’s just a false first impression, but these documents certainly appear to introduce a lot of procedure and make reference to number of required specifications that are not listed in the list below.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Do you really want to go down this path? I would still be open to a simplification of OpenID 2.0 to remove the pain points.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Paul</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><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-specs-bounces@lists.openid.net" target="_blank">openid-specs-bounces@lists.openid.net</a> <a href="mailto:[mailto:openid-specs-bounces@lists.openid.net]" target="_blank">[mailto:openid-specs-bounces@lists.openid.net]</a> <b>On Behalf Of </b>Mike Jones<br><b>Sent:</b> Monday, February 27, 2012 8:36 PM<br><b>To:</b> <a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a><br><b>Cc:</b> <a href="mailto:board@openid.net" target="_blank">board@openid.net</a><br><b>Subject:</b> Implementer’s Drafts posted with -ID1 version designations</span><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><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The approved Implementer’s Drafts are now also posted at these locations:<o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><a href="http://openid.net/specs/openid-connect-basic-1_0-ID1.html" target="_blank">http://openid.net/specs/openid-connect-basic-1_0-ID1.html</a><o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><a href="http://openid.net/specs/openid-connect-discovery-1_0-ID1.html" target="_blank">http://openid.net/specs/openid-connect-discovery-1_0-ID1.html</a><o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><a href="http://openid.net/specs/openid-connect-registration-1_0-ID1.html" target="_blank">http://openid.net/specs/openid-connect-registration-1_0-ID1.html</a><o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><a href="http://openid.net/specs/openid-connect-messages-1_0-ID1.html" target="_blank">http://openid.net/specs/openid-connect-messages-1_0-ID1.html</a><o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><a href="http://openid.net/specs/openid-connect-standard-1_0-ID1.html" target="_blank">http://openid.net/specs/openid-connect-standard-1_0-ID1.html</a><o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><a href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0-ID1.html" target="_blank">http://openid.net/specs/oauth-v2-multiple-response-types-1_0-ID1.html</a><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'>The original versions with numeric version designations remain in place.<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></div></div></div></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>specs mailing list<br><a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><o:p></o:p></p></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <br>Nat Sakimura (=nat)<o:p></o:p></p><div><p class=MsoNormal>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><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>