OpenID using HTTP WWW-Authenticate/Authorization

[Thomas Broyer]

[Resent, as it seems it didn't make its way through the approval
processes. I'm now subscribed to all three lists Cc'd here but please
follow-up on the Yadis list as it's also the official list for OpenID
discussions]

Hi there,

A few days ago, James M Snell [1] suggested a new HTTP Authentication
Scheme (which he was asked to removed, but that's another story) for a
user-agent to "claim" an digitally verifiable identity, giving several
examples among which one using OpenID.

I started thinking a bit and wrote to James about it:
> I've been thinking a bit about how a browser extension could handle
> Claim authentication, particularly using OpenID.
>
> It seems to me that it would lead to separating the protocol in two
> parts –because their couldn't be redirects–, and always use the 'dumb'
> mode (e.g. without the "associate" step):
>  1. the "consumer" server sends a 401 with scheme=openid and giving an
> openid.return_to URL and optionally an openid.trust_root
>  2. the browser asks the user for his identity URL and issues the
> OpenID "checkid_immediate" request to the "identity server" (HTTP-GET
> the provided URL and find the <link rel="openid.server"/> and optional
> <link rel="openid.delegate"/>, then HTTP-GET the "openid.server" URL
> with additional query string parameters)
>  3. if the response contains an openid.user_setup_url, the browser
> tells the user the identification failed and give him the option to go
> to that URL to authorize the "consumer site"; the user also has the
> option to retry the authentication (needed after coming back from the
> openid.user_setup_url)
>  4. if the response does not contain an openid.user_setup_url and
> contains the "positive assertion" query string arguments, the browser
> "parses" them and send them in the "Authorization: Claim" header.
>  5. when the "consumer" server receives the "Authorization: Claim"
> header, it issues the OpenID "check_authentication" request to verify
> the claimed identity
>
> However, while thinking about it, I wonder whether you didn't go a bit
> too far: HTTP-Auth is extensible, and you're trying to build an
> extensible auth-scheme on top of that. Your 6 examples could also be
> implemented each within its own HTTP-Auth scheme, like this:
> Authorization: OpenID identity="http://www.snellspace.com/",
> assoc_handle=xxx, signed="mode,identity", sig="xxx" [other params,
> such as snonce, cnonce, created, etc.]

But, initially, James proposed this new auth-scheme in the context of
the Trackback Protocol [2] (mailing list Cc'd here), so I came to
thinking (even) more about it and it seems there's a need for
delegation, because you shouldn't have to have a preexisting
relationship with ping'd sites (I think you shouldn't even have to
really create a relationship, where you'd authorized the ping'd site)
and you shouldn't have to "manually" authorize each ping'd site to
verify your OpenID.

Here's the scenario:
 1. Beth identifies to her blog's web-based admin panel at beth.bloghost.com
 2. she posts a new entry, and the blog service now have to perform
the "trackback thing"
 3. for each URL that needs to be ping'd, the blog service asks Beth's
Identity Server a single-use token, identifying itself using its own
Identity URL (see below; it also means Beth has previously authorized
her blog service to ask for such tokens, but the blog service could
send Beth to her user_setup_url in case of error)
 4. the blog system now pings the trackback URLs, identiying itself
using Beth Identity URL (here's the new delegation need) and providing
the single-use token it previously retrieved as the assoc_handle
 5. the ping'd trackback service verifies the claimed identity
sendding a mode=check_authentication request to Beth's Identity Server

Notes:
As Beth don't want to have to authorize each and every service she
trackbacks, the assoc_handle has to be "use once exactly".
OpenID has to be extended to allow Beth's blog service to ask for an
assoc_handle in the name of Beth, for use (verification) by another
Relying Party.
Beth's blog service has to have an Identity URL so that it can
identifies itself to Beth's Identity Server, using an Authorization
HTTP header as described above.


All this thinking is based on OpenID, but I've read that LID could
allow it without the need to be extended. If that's the case, please
tell me how: I started reading lid.netmesh.org but I must say that
it's really hard to follow (I saw many profiles but I didn't understand
how really they all work together).


As there have been discussions recently on the DIX [3] list about
non-browser based needs, I'm also Cc'ing the DIX mailing list.


[1] http://www.snellspace.com
[2] http://www.lifewiki.net/trackback/
[3] http://www.dixs.org
--
Thomas Broyer