Double-check OpenID/OAuth section?

Everyone (particularly David, Chris, Eran and others who we've talked
to aout this)

   I think these sections are very important, and want to make sure I
get the tech details right in the final report to the W3C - so if you
could double-check these ASAP, that would be great!  cheers,
    harry  (ignore bibliographic markers)

 ===OAuth====

OAuth (Open Authorization) [OAUTH!!] is an IETF standard lets users
share their private resources on a resource-hosting site with another
third-party site without having to give the third-party their
credentials for the site and so access to all their personal data on
the social site. This standard essentially defeats the dangerous
practice of many early social networking sites of accessing for the
username and password of an e-mail account in order to populate a list
of friends. Instead, OAuth allows an authorized handshake to happen
between an resource-hosting site and a third-party, which then lets
the third-party to redirect the user to authorize the transaction
explicitly on the original site. If the transaction is explicitly
authorized, then OAuth generates a duration-limited token for the
third party that grants access to the resource-hosting site for
specific resource. OAuth's tokens establish a unique ID and shared
secret for the client making the request, the authorization request,
and the access grant. To its huge advantage, this approach works
securely over ordinary HTTP requests, as client generates a signature
on every API call by encrypting a unique information using the token
secret, and the token secrets never leave the sites. However, a
session-fixation attack was discovered in the original specification
that allowed a malicious party to save the authorization request and
then convince a victim to authorize it, giving the malicious party
access to the victim's resources, but this was fixed by having the
third-party register with the resource-hosting site, as given in an
update of OAuth. Recently there has also been a timing attack (using
the difference of time in "bad" and correct digital signature
verification to figure out tokens), but this has been addressed by
having digital signature verification use a constant time.

While OAuth 1.0 is highly successful, the process of generating and
managing the various tokens was considered difficult by many
developers, so the IETF draft standard OAuth 2.0 simplifies the
process by relying on TLS. While OAuth 2.0 requires that the
resource-hosting site use HTTPS rather than HTTP (and is therefore
backwards incompatible), OAuth 2.0 requires SSL SSL is required for
generating the token, so signatures are no longer required for both
token generation and API calls. Decreasing complexity, OAuth 2.0 has
just a single security token and no signature is required. This has
led to wider adoption across social networking sites like Twitter.

==OpenID===

OpenID centralises the authentication step at an identity provider, so
that a user can identify themselves with one site (an OpenID identity
provider) and share their profile data with another site, the relying
party. A user need only remember one globally unique identity, which
in OpenID 1.0 was a URI. In the initial OpenID 1.0 specification
[OPENID-1!!], the identity provider was discovered by following links
of a HTML page accessed by the OpenID 1.0 URI, and OpenID 2.0 also
allowed the use of the XRD format. One of the primary findings of the
OpenID effort was that users were uanble to use URIs to identify
themselves, and so approaches like Webfinger [WEBFINGER!!] even just
an e-mail address, as enabled by the Webfinger were developed to allow
e-mail addresses to be used as identifiers, which has had more
success.

Once the OpenID provider is discovered, a shared secret is established
in between the provider and the relying party, allowing them to share
data. This is primarly done via an attribute exchange protocol
[OPENID-ATTR!!], that allows the user to specify what personal data
should be sent to the relying party. Note that this attribute exchange
protocol is constrained by the information that can be placed as
attribute-value pairs inside a URI, which is practically limited to a
maximum of 1024 characters [@@Check?]. OpenID is currently deployed by
AOL, Facebook, the Livejournal codebase, Microsoft, Myspace, Google
(including Blogger), WordPress and Yahoo! (including Flickr). However,
many larger sites deploy themelves as OpenID identity providers but do
not function as relying OpenID relying parties, i.e. do not allow
users to log-in to their site using user credentials from another
site.

As a server-side solution, OpenID and successor technologies have the
advantage of only relying on server-side HTTP redirects, and so in
general works independent of browsers. Very seriously, OpenID 2.0
Authentication does not require relying parties to validate, and so
has been described as phishing heaven, since it allows any
OpenID-enabled site to redirect a user to a fake OpenID provider, that
then steals the user's credentials. While OpenID does not specify the
credentials needed by the authentication mechanism, very few OpenIP
providers provide authentication based on certficates or other kinds
of credentials, but primarily rely on username-password
authentication. Also, the protocol seems complex to developers,
requiring 7 HTTPS in general. Its creators feel that users are not yet
using the functionality of OpenID on the scale they would like, and so
given the similarities between the workflow of OpenID and the success
of OAuth with developers, now it appears that that the next version of
OpenID, the work known as OpenID Connect [OPENID-CONNECT!!] starting
at the OpenID Foundation in 2010, will be built entirely on top of
OAuth.

Received on Thursday, 7 October 2010 12:50:19 UTC