I forgot to acknowledge in my previous message that the work that let to the
proposal was supported by NSF grant IIP-1013594.
--- On Thu, 9/23/10, Francisco Corella <fcore...@pomcor.com> wrote:
From: Francisco Corella <fcore...@pomcor.com>
Subject: Not requiring client registration
To: oauth@ietf.org
Date: Thursday, September 23, 2010, 3:31 AM
Hello,
I'm new to the list. I've signed up to propose a simple improvement that would
avoid the need for the OAuth client to register with the resource server.
Registration may seem necessary because it provides information that the
resource server can use to tell the user what client is requesting a resource.
But there are alternatives: in the solution I describe below, the resource
server describes the client to the user using information contained in an
ordinary TLS server certificate presented by the OAuth client during an
ordinary TLS handshake.
Eliminating the need for registration would have many benefits. Consider the
photo sharing/printing example of the Internet draft, and assume that there is
a standard Web API that printing services can use to access photo sharing
services. (Is there such a thing? If
not there will no doubt be one in the future.) A new photo sharing service
would benefit because its users could use any printing service, and because it
would not have to implement and maintain a registration service. A photo
printing service would benefit because it could print photos from any photo
sharing service implementing the standard API, without having to register or
even be aware of the existence of the photo sharing service. (The user would
provide the url of the sharing service.) And a user would benefit by being
less constrained in her choice of photo-sharing-and-printing solutions.
Here is the proposal. I assume that the OAuth client runs in a web server
("web server profile"). The user asks the OAuth client to access a resource on
its behalf. The OAuth client redirects the user-agent to the resource server,
but instead of including a client identifier in the redirection url, it
includes a
url pointing to a web server owned by the OAuth client, from which the
resource server downloads a self-signed TLS client certificate that the OAuth
client will later use for authentication in a TLS handshake. This url is an
https url, and the resource server obtains the OAuth client's server
certificate during the TLS handshake.
(Note: the OAuth client has two certificates, a TLS client certificate and a
TLS server certificate. A single dual-purpose certificate could play both
roles, but I don't see an advantage to this.)
The resource server asks permission from the user to provide the resource to
the OAuth client, describing the Oauth client to the user based on the
information included the server certificate, and perhaps telling the user what
CA backs the server certificate. Assume the user grants permission.
The resource server stores the OAuth client's self-signed client certificate,
pairing it with an
authorization code, and places the authorization code in a redirection url
that redirects the user-agent back to the OAuth client. The OAuth client uses
the authorization code to request the resource over a TLS connection, in which
it authenticates itself using the self-signed client certificate. The resource
server verifies the self-signed client certificate by checking that it had
earlier stored it, paired with the authorization code.
Does this make sense?
Francisco
---
Francisco Corella
CEO, Pomcor
fcorella at pomcor dot com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
