Ahhh, I see what you're going for. It's a very interesting idea.<br><br><div><span class="gmail_quote">On 8/30/07, <b class="gmail_sendername">James Henstridge</b> <<a href="mailto:james@jamesh.id.au">james@jamesh.id.au
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 30/08/2007, John Ehn <<a href="mailto:john@extremeswank.com">john@extremeswank.com
</a>> wrote:<br>> James,<br>><br>> Sorry, but I'm having problems following the flow. It seems like an<br>> interesting idea, though. Can you provide with a little more information on<br>> how these components would interact?
<br><br>Okay. The basic idea was that instead of creating a special protocol<br>for two OpenID relying parties to communicate with each other was for<br>the web services data provider to act as an OpenID provider.<br><br>
So, lets assume that the data consumer wants an auth token for the<br>user identified by <a href="http://user.identifier.url">http://user.identifier.url</a>. With normal OpenID<br>authentication, you'd perform discovery to find the user's OpenID
<br>provider. To request an auth token though we need to talk to the data<br>provider, so instead we skip discovery and perform an authentication<br>request to the data provider's endpoint. The parameters might look
<br>something like this:<br><br> * openid.mode = checkid_setup<br> * openid.claimed_id = <a href="http://user.identifier.url">http://user.identifier.url</a><br> * openid.identity = <a href="http://user.identifier.url">http://user.identifier.url
</a><br> * openid.return_to = <a href="http://data.consumer/.">http://data.consumer/.</a>..<br> * openid.ns.auth = ...<br> * (additional parameters related to the auth token request)<br><br>The data provider would then decide whether to grant the auth token
<br>(possibly by performing OpenID authentication against<br><a href="http://user.identifier.url">http://user.identifier.url</a>, and/or asking the user), then send a<br>response back like:<br><br> * openid.mode = id_res<br>
* openid.claimed_id = <a href="http://user.identifier.url">http://user.identifier.url</a><br> * openid.identity = <a href="http://user.identifier.url">http://user.identifier.url</a><br> * openid.return_to = <a href="http://data.consumer/.">
http://data.consumer/.</a>..<br> * openid.ns.auth = ...<br> * openid.auth.token = ...<br> * openid.auth.secret = ...<br><br>The data consumer knows that the request came from the data provider<br>due to the signature on the OpenID response. The data provider knows
<br>which user to create the token for because it was present in the<br>OpenID request. The data provider can verify that the web browser<br>user is that user because control gets transferred to the data<br>provider during the authentication process.
<br><br>This all assumes that the data consumer has already authenticated the<br>user, so knows which identity URL to request a token for from the data<br>provider.<br><br>> I was really trying to keep everything dumb and simple. The concept I was
<br>> going for was "piggy-back on OpenID, but include a way to programmatically<br>> log on to the OpenID Provider". The problem I saw with OpenID was that<br>> there are about a million different ways to authenticate with an OpenID
<br>> Provider, from HTML forms to digital certificates. Most require the User<br>> Agent to be a web browser. However, there is no standard way to just pass a<br>> credential that can prove that you are who you say you are.
<br><br>Well, OpenID authentication requests are designed to let the OP<br>perform whatever checking they want before sending a response. So by<br>making the data provider act as an OP, it has the same freedom<br>(including the freedom to issue its own OpenID authentication request
<br>to the user's actual OP).<br><br>> I was trying to solve the problem by coming up with an automatable (if<br>> that's a word) way to authenticate with an OpenID Provider. If we have<br>> that, there's no need to pass around a special token, because we can just
<br>> use standard OpenID authentication if we want to log on to another system.<br>> So, I proposed just having the Consumer get a key from the OpenID Provider<br>> that it can use to automatically authenticate with the Provider in the
<br>> future. The key is passed through the user when it's granted, because you<br>> need the user to approve the whole thing anyway.<br><br>I think that this makes things more complicated than need be. If you
<br>want an auth token from the data provider it seems better to ask the<br>data provider for the key directly, giving it the chance to<br>authenticate the user before responding.<br><br>This also has the benefit that it does not require any special
<br>features from the user's OP -- the extension is purely concerned with<br>the interaction between data consumer and provider.<br><br><br>> I don't expect this extension to fix all problems. It's only intended to
<br>> solve a specific use case (website to website info sharing). I am working<br>> on two additional extensions which will solve the other problems I see:<br><br>Sure. I doubt my suggested workflow would help with those use cases
<br>either (at least without some additional components).<br><br>James.<br></blockquote></div><br>