OpenID Auth for agents and "bots"

Thomas Broyer t.broyer at
Tue Aug 8 21:00:19 UTC 2006

2006/8/8, Kevin Turner:
> On Sun, 2006-08-06 at 15:27 +0100, Martin Atkins wrote:
> >      <>
> there's one bit where you say
> > It makes for less to-ing and fro-ing in the (assumed) common case
> > where the client is acting as its own identity provider.
> How does this "common" case work?  The RP still needs to do discovery on
> the identifier and check_authentication with the IdP.  The client can't
> exactly act as its own IdP in that case.

(Fictional) example:
I post an entry to my blog and this one has to "pingback" other blogs.
When doing so, it generates an assoc_handle and gives its own URI as
identity (or any URI that will resolve in the blog being the IdP). The
other blogs, when ping'd (i.e. acting as RPs), can contact my blog
(acting as an IdP) to validate the assoc_handle.

This is exactly equivalent to my blog doing the checkid_immediate
internally, a) without the need for the RP to ask for it, b) without
the need for the user to authenticate (it probably already is in this
example, but there might even be no user at all) and eventually
"validate" the RP (hey, I want to pingback/trackback the URIs, so of
course I allow them to verify my identity!).
The last part of the checkid_immediate (from the Idp to the RP
–generally through the UA in the OpenID browser-based common case–)
corresponds to the Authorization request header. Because the "first"
request is made at the time the Authorization request header is sent,
there's no need for the first request to the RP as in the OpenID 1.1
spec (no "state variable" need to be passed through the whole
identification process to restore the appropriate state when the user
is identified).

In the case of "OpenID Auth", OpenID can only be used for
"identification", not "authentication", as the "user" and IdP are the
same (the "user" here *is* the IdP, there's no "human" user).

Thomas Broyer

More information about the yadis mailing list