Paul, For a simple "Authentication" only case for a Web server (RP, client), then you really do not need most of them.
I wrote a blog post for such a case. It should not take more than 10 minutes to write a basic RP authentication. http://nat.sakimura.org/2012/03/31/openid-connect-stripped-down-to-just-authentication/ Cheers, Nat On Sat, Mar 31, 2012 at 5:34 AM, Paul E. Jones <[email protected]>wrote: > 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 > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
