Implementer's Drafts posted with -ID1 version designations

Paul E. Jones paulej at packetizer.com
Fri Mar 30 20:34:58 UTC 2012


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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20120330/2869db15/attachment.html>


More information about the specs mailing list