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 provider. > 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). James. _______________________________________________ specs mailing list email@example.com http://openid.net/mailman/listinfo/specs