Ahhh, I see what you're going for. It's a very interesting idea.
On 8/30/07, James Henstridge <[EMAIL PROTECTED]> wrote: > > 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 firstname.lastname@example.org http://openid.net/mailman/listinfo/specs