Implementer's Drafts posted with -ID1 version designations
Paul E. Jones
paulej at packetizer.com
Mon Apr 2 17:54:36 UTC 2012
Nat,
Once again, thanks for taking time to write up the procedures so it's
easier to digest. This definitely gives me a better level of comfort with
respect to the overall complexity.
The "discovery" part is specified as otional on openid.net/connect. Section
2 of the discovery spec seems to suggest it is conditionally mandatory ("if
a Relying Party knows the OP information through an out-of-band mechanism,
they can skip this step"). Is there a statement anywhere that says that RPs
must implement discovery if they do not have a relationship with the OP? To
ensure any new mechanism will work on the Internet at large, I really would
want discovery to be mandatory. Quite frankly, I'm growing tired of
visiting web sites that only allow me to log in using a few select web
sitess. I do not trust Facebook, for example, any more than I could throw
the 500 pound gorilla. (That's not intended to be so strong against FB, per
se, but I want to emphasize how important trust is and social networking
sites, search engines, web directories, etc. are not in the business of
security one's identity. We need to ensure there is a viable business
opportunity for companies that I could place trust in, if not my own
servers.)
There are still a number of specs that make up OpenID Connect. Of course,
if I read through them all, my questions would be addressed, but I think it
might be useful to document why and how each of those referenced specs are
used. For example, JWS. why? If OpenID Connect mandates TLS, why is a
signature required? I'm even more bewildered over the requirement for
anything labeled "encryption" (JWE) given communication is over an encrypted
channel. In OpenID 2.0 one hashes values and signs responses, etc. because
TLS was an option (I assume).
Another issue that I'm struggling with, which actually was brought my
attention to the fact that the OpenID Connect specs was published, is the
use of SWD. Several years ago, I asked the question on one of the OpenID
lists why we did not use email IDs. (I never was a big fan of the OpenID
IDs, but I appreciated their value. I still agree with proponents there
that they have value. Not everyone has an email address, nor does everyone
want to use an email address when logging into places.) It was far too late
to move away from URI identifiers, but I asked about mapping to them using
an email address. I believe dung was hurled in my face. :-) Sometime
later, I asked again and the group was much more receptive to the idea,
apparently having had discussions along these lines so many times and
starting to see to the benefit for adoption purposes. The second time, I
was told "go look at WebFinger." I did. I was thrilled to sww RFC 6415
published, as it would allow the mapping of email IDs to OpenID identifiers.
For OpenID Connect, WebFinger can be used in the discovery process just as
SWD is being proposed to do.
So, if one issued this request:
GET
/.well-known/host-meta.json?resource=acct:paulej%40packetizer.com&rel=http%3
A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
HOST packetizer.com
One would get back the following (if I had an OpenID Connect entry):
{
"subject" : "acct:paulej at packetizer.com",
"links" :
[
{
"rel" : "http://openid.net/specs/connect/1.0/issuer",
"href" : "https://server.example.com"
}
]
}
The "resource" parameter is relatively new (not in RFC 6415) as is the acct
URI scheme, but both have been proposed for a while. They are both in the
current WebFinger draft. The "rel" parameter is also new and still under
discussion (not yet published). It effectively filters the reply so that
only link relations in the "rel" parameter are returned. Since it's merely
a filter, there is still the question of usefulness. It's simply enough to
walk through the list of returned link relations, as it's just an array.
Also, there is always the possibility that an account might have multiple
OpenID OPs associated with it or multiple values for any given link relation
(e.g., I might have multiple blogs or multiple picture sharing sites or
multiple you-name-it). So, requesting entities must always enumerate the
list, anyway.
Everything else, though, is already documented in RFC 6415, including
production of both XML and JSON for those wanting to perform discovery. So,
it concerns me to see that we have a second largely (if not entirely)
redundant discovery mechanism proposed.
As a note on use of the email address for discovery, one could query an
email address (as shown in your examples) and we had a lot of debate over
that. It was generally decided that in order to serve as a generic
discovery mechanism for anything owned by the domain, a scheme is needed.
My own WebFinger server will actually respond to "paulej at packetizer.com"
(since Blaine Cook seemed to have that preference at one time - not sure of
his opinion now), but a URI scheme should be used to ensure that the correct
resource is referenced. The "acct" scheme was proposed to take address the
need to ensure all entities are identified properly and to address the fact
that some users would not be using an email address, per se, though the form
of acct URIs look like email addresses and might very well be the same
character string. That is done for the benefit of humans.
So, was SWD introduced out of concern over WebFinger complexity? Or was it
unknown? SWD looks simple enough, but definitely no less simple than
WebFinger, from what I can tell, except perhaps the "SWD_service_redirect"
construct. I'm not sure why that would be used over 3xx. Otherwise, they
appear to be comparable in function and complexity, so I would recommend
using what's already in RFC 6415. If making two queries (following LRDD) is
a concern, then help to push the current WebFinger draft through so we can
address that issue with the resource parameter. OpenID Connect could
require support of the "resource" (and perhaps "rel") parameter.
Paul
From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Saturday, March 31, 2012 1:06 AM
To: Paul E. Jones
Cc: Mike Jones; specs at openid.net; board at openid.net; gsalguei at cisco.com
Subject: Re: Implementer's Drafts posted with -ID1 version designations
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-auth
entication/
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-specs/attachments/20120402/ff2166c1/attachment.html>
More information about the specs
mailing list