[OpenID] is openid 2.0 a lightweight identity system?
cygnus at janrain.com
Fri Feb 9 17:30:35 UTC 2007
# 1. How XRDS helps OpenID grow beyond authentication.
I think this is explained below.
# 2. Why OpenID growing beyond authentication is a good idea - what
# kind of additional problems does that let us solve?
Early on, some people understood that sending an identifier in the
OpenID messages was a specific case of the more general signed message
case. With the identifier now optional, the OpenID protocol itself
can be used more generically. People come up with all sorts of
contrived use cases for this, but one example is a case where an RP
wants a signed assertion that the user is, say, at least 21 years of
age, and in that case no identifier or authentication is pertinent per
se. You get an assertion (and for the sake of argument, assume it's
signed by a trusted authority so you know it has value), but it might
not have anything to do with whether the RP needs to know the user's
# 3. Why can't those problems be solved as separate extensions to the
# OpenID spec? Is it really necessary for XRDS to be in core OpenID -
# does it act as a kind of plug-in mechanism without which extending
# OpenID would be significantly less likely to achieve consensus, for
The problems can be solved using separate extensions, but XRDS lets
identifier URLs advertise to RPs the extensions and/or services
supported by OPs. It's also true that XRDS isn't necessary to use
such extensions, but it does help provide some clarity to an RP when
constructing a request. (In the case of Simple Registration, people
usually just stuff the openid.sreg parameters in the request and see
if anything comes back, but the Right Way is to only bother sending
them if the sreg service type is found in the OP's corresponding
# I'll be completely honest here: I don't understand what "service
# type" or "service" actually means. The OpenID 2.0 spec doesn't help
# me here - as far as I can tell, a "service" is anything that fits in
# an <xrd:Service> element.
Empirically, an xrd:Service element needs to contain two things: a
service URI and a service type URI. Optionally, the element can
express the priority of the described service in the context of the
entire XRDS document. It may also contain other information specific
to the type URI in use, such as the OpenID OP-local ID.
The service URI's purpose is up to the service type authors and should
be specified accordingly.
A service is essentially whatever you want it to be. There has been a
lot of debate (or misunderstanding?) around what a service actually
*is* and what its properties ought to be (i.e., what a Service element
maps to in reality). Generally speaking, a service type is a URI used
to indicate the support of (or desired use of) a given service, whose
functionality is out of scope for OpenID. It's just a form of
Some examples are 1) list OpenID OP services to support fallback in
case one goes offline, 2) advertise a public key using a well-defined
service type URI, or 3) advertise a photo-sharing service compliant to
some photo-fetching protocol, say.
# I'm now three specs in and I still don't know what a service is! I'm
# obviously missing something critically important here.
Maybe my explanation helped. Johannes, Drummond, and others may have
more to offer.
Thanks for asking these questions.
irc.freenode.net: cygnus in #openid
More information about the general