Mike,
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. Even after reading that document, though, I feel no less easy about OpenID Connect. It's not that there is a specific change I can propose, though. 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. 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.) 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 appear 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. 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. :-/ Paul From: Mike Jones [mailto:[email protected]] Sent: Friday, March 30, 2012 1:27 PM To: Paul E. Jones; [email protected] Cc: [email protected]; [email protected] Subject: RE: Implementer's Drafts posted with -ID1 version designations 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 http://nat.sakimura.org/2012/01/20/openid-connect-nutshell/, 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. If you still disagree, then we'd be interested in hearing what specific changes you'd suggest that we make. -- Mike From: Paul E. Jones [mailto:[email protected]] Sent: Friday, March 30, 2012 10:17 AM To: Mike Jones; [email protected] Cc: [email protected]; [email protected] Subject: RE: Implementer's Drafts posted with -ID1 version designations 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. 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). 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?!?! 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. 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. Paul From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Monday, February 27, 2012 8:36 PM To: [email protected] Cc: [email protected] Subject: Implementer's Drafts posted with -ID1 version designations The approved Implementer's Drafts are now also posted at these locations: . http://openid.net/specs/openid-connect-basic-1_0-ID1.html . http://openid.net/specs/openid-connect-discovery-1_0-ID1.html . http://openid.net/specs/openid-connect-registration-1_0-ID1.html . http://openid.net/specs/openid-connect-messages-1_0-ID1.html . http://openid.net/specs/openid-connect-standard-1_0-ID1.html . http://openid.net/specs/oauth-v2-multiple-response-types-1_0-ID1.html The original versions with numeric version designations remain in place. -- Mike
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
