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:pau...@packetizer.com]
Sent: Friday, March 30, 2012 10:17 AM
To: Mike Jones; sp...@openid.net
Cc: bo...@openid.net; gsalg...@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-boun...@lists.openid.net<mailto:openid-specs-boun...@lists.openid.net>
[mailto:openid-specs-boun...@lists.openid.net]<mailto:[mailto:openid-specs-boun...@lists.openid.net]>
On Behalf Of Mike Jones
Sent: Monday, February 27, 2012 8:36 PM
To: sp...@openid.net<mailto:sp...@openid.net>
Cc: bo...@openid.net<mailto:bo...@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
_______________________________________________
board mailing list
bo...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-board
