<div>Well, I've slept on it. I think we have a difference in philosophy.</div>
<div> </div>
<div>The other Extesions - AX, Simple Registration, etc. - follow the same data flow methodology:</div>
<div> </div>
<div>RP -> UA -> OP</div>
<div>RP <- UA <- OP</div>
<div> </div>
<div>I believe I'm sticking to the same principles in my spec. We are doing the very same thing when we collect the authentication key (see above). We are even doing the very same thing when we have the sites authenticate with each other. It's just we have a non-human operating the User Agent. In this case, the RP is the "destination" site, the UA is the "client" site:
</div>
<div> </div>
<div>RP -> UA -> OP</div>
<div>RP <- UA <- OP</div>
<div> </div>
<div>I think this fits well with what people expect. I also have no problem with having OPs incrementally improve their systems to make them compatible with new extensions. Since there will (eventually) be far more RPs out there than OPs, I think it's reasonable for them to support the bulk of the extension implementation.
</div>
<div> </div>
<div>In this case, however, there really isn't all that much to implement. The following code changes will need to happen at the site that wants access to information at another site (the CC):</div>
<div> </div>
<div>* The form where the user submits their OpenID to grant permission to another site</div>
<div>* Logic that builds a simple OpenID login request with the Trusted Authentication data included, and a redirect to the OP</div>
<div>* A branch to the "id_res" checker that parses the OP response and stores the shared secret</div>
<div>* An automated script that performs OpenID authentication to the DC and retreives data</div>
<div> </div>
<div>The OP needs to implement the following:</div>
<div> </div>
<div>* When receiving a check_id request with Trusted Authentication arguments, send an X-OPENID-TrustedAuthentication HTTP header in the response, and be able to accept a SHA-256 hash as a response - This is not a big deal, and isn't any form of deviation, because this is the "gray area" in the spec where the UA is supposed to be verified that it's already logged in, or is prompted for credentials
</div>
<div>* Add a logic branch that generates a shared secret when requested, stores it, and sends it in the authentication response</div>
<div>* Some form of user interface to manage the stored secrets - very easy</div>
<div> </div>
<div>All but one of these steps would be needed to implement ANY OpenID extension out there. And the only change that is "out of spec" is accepting an SHA-256 hash as an authentication key - which is trivial to implement at an OP.
</div>
<div> </div>
<div>Conservatively, (with distractions) I think an OP can implement the data passing in less than a couple of hours, and the user interface in a couple of days.</div>
<div> </div>
<div>Although your implementation is sound, and I like a lot of the ideas, they shift a lot of the responsibility to the party receiving the authentication request. I'm not sure I like the idea of having the burden of implementing both an API and a special pseudo-OP. This also removes the power of having a single Identity management interface at the OP, meaning the user will have to log on to the destination site to invalidate the token. What if the user has 50 of these API connections set up? That's 50 sites to visit in order to manage these tokens.
</div>
<div> </div>
<div>Like I said, nothing technically wrong with the idea (it's novel), but it just doesn't fit with me.</div>
<div> </div>
<div>Thank you!</div>
<div> </div>
<div>John Ehn </div>
<div> </div>
<div><span class="gmail_quote">On 8/30/07, <b class="gmail_sendername">James Henstridge</b> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:james@jamesh.id.au" target="_blank">james@jamesh.id.au
</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On 30/08/2007, John Ehn <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:john@extremeswank.com" target="_blank">
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 onclick="return top.js.OpenExtLink(window,event,this)" href="http://user.identifier.url/" target="_blank">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 onclick="return top.js.OpenExtLink(window,event,this)" href="http://user.identifier.url/" target="_blank">
http://user.identifier.url</a><br>* openid.identity = <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://user.identifier.url/" target="_blank">http://user.identifier.url </a><br>* openid.return_to = <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://data.consumer/" target="_blank">
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 onclick="return top.js.OpenExtLink(window,event,this)" href="http://user.identifier.url/" target="_blank">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 onclick="return top.js.OpenExtLink(window,event,this)" href="http://user.identifier.url/" target="_blank">http://user.identifier.url</a><br>* openid.identity = <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://user.identifier.url/" target="_blank">
http://user.identifier.url</a><br>* openid.return_to = <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://data.consumer/" target="_blank">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>