On 30/08/2007, John Ehn <[EMAIL PROTECTED]> wrote:
> James,
> Sorry, but I'm having problems following the flow.  It seems like an
> interesting idea, though.  Can you provide with a little more information on
> how these components would interact?

Okay.  The basic idea was that instead of creating a special protocol
for two OpenID relying parties to communicate with each other was for
the web services data provider to act as an OpenID provider.

So, lets assume that the data consumer wants an auth token for the
user identified by http://user.identifier.url.  With normal OpenID
authentication, you'd perform discovery to find the user's OpenID
provider.  To request an auth token though we need to talk to the data
provider, so instead we skip discovery and perform an authentication
request to the data provider's endpoint.  The parameters might look
something like this:

 * openid.mode = checkid_setup
 * openid.claimed_id = http://user.identifier.url
 * openid.identity = http://user.identifier.url
 * openid.return_to = http://data.consumer/...
 * openid.ns.auth = ...
 * (additional parameters related to the auth token request)

The data provider would then decide whether to grant the auth token
(possibly by performing OpenID authentication against
http://user.identifier.url, and/or asking the user), then send a
response back like:

 * openid.mode = id_res
 * openid.claimed_id = http://user.identifier.url
 * openid.identity = http://user.identifier.url
 * openid.return_to = http://data.consumer/...
 * openid.ns.auth = ...
 * openid.auth.token = ...
 * openid.auth.secret = ...

The data consumer knows that the request came from the data provider
due to the signature on the OpenID response.  The data provider knows
which user to create the token for because it was present in the
OpenID request.  The data provider can verify that the web browser
user is that user because control gets transferred to the data
provider during the authentication process.

This all assumes that the data consumer has already authenticated the
user, so knows which identity URL to request a token for from the data

> I was really trying to keep everything dumb and simple.  The concept I was
> going for was "piggy-back on OpenID, but include a way to programmatically
> log on to the OpenID Provider".  The problem I saw with OpenID was that
> there are about a million different ways to authenticate with an OpenID
> Provider, from HTML forms to digital certificates.  Most require the User
> Agent to be a web browser.  However, there is no standard way to just pass a
> credential that can prove that you are who you say you are.

Well, OpenID authentication requests are designed to let the OP
perform whatever checking they want before sending a response.  So by
making the data provider act as an OP, it has the same freedom
(including the freedom to issue its own OpenID authentication request
to the user's actual OP).

> I was trying to solve the problem by coming up with an automatable (if
> that's a word) way to authenticate with an OpenID Provider.  If we have
> that, there's no need to pass around a special token, because we can just
> use standard OpenID authentication if we want to log on to another system.
> So, I proposed just having the Consumer get a key from the OpenID Provider
> that it can use to automatically authenticate with the Provider in the
> future.  The key is passed through the user when it's granted, because you
> need the user to approve the whole thing anyway.

I think that this makes things more complicated than need be.  If you
want an auth token from the data provider it seems better to ask the
data provider for the key directly, giving it the chance to
authenticate the user before responding.

This also has the benefit that it does not require any special
features from the user's OP -- the extension is purely concerned with
the interaction between data consumer and provider.

> I don't expect this extension to fix all problems.  It's only intended to
> solve a specific use case (website to website info sharing).  I am working
> on two additional extensions which will solve the other problems I see:

Sure.  I doubt my suggested workflow would help with those use cases
either (at least without some additional components).

specs mailing list

Reply via email to