[OpenID board] Implementer's Drafts posted with -ID1 version designations
Nat Sakimura
sakimura at gmail.com
Sat Mar 31 05:06:18 UTC 2012
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 <paulej at packetizer.com>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:Michael.Jones at microsoft.com]
> *Sent:* Friday, March 30, 2012 1:27 PM
> *To:* Paul E. Jones; specs at openid.net
>
> *Cc:* board at openid.net; gsalguei at cisco.com
> *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:paulej at packetizer.com]
> *Sent:* Friday, March 30, 2012 10:17 AM
> *To:* Mike Jones; specs at openid.net
> *Cc:* board at openid.net; gsalguei at cisco.com
> *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:* openid-specs-bounces at lists.openid.net
> [mailto:openid-specs-bounces at lists.openid.net] *On Behalf Of *Mike Jones
> *Sent:* Monday, February 27, 2012 8:36 PM
> *To:* specs at openid.net
> *Cc:* board at openid.net
> *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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-board/attachments/20120331/f8bbcc94/attachment-0001.html>
More information about the board
mailing list