Re: [OAUTH-WG] Not requiring client registration

[Francisco Corella <[e-mail]>]

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 <[e-mail]> wrote:

From: Francisco Corella <[e-mail]>
Subject: Not requiring client registration
To: [e-mail]
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