<div>James,</div>
<div> </div>
<div>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?</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>Trusted Connection Request:</div>
<div>User Agent gives OpenID to Client Consumer</div>
<div>Client Consumer -> User Agent -> OpenID Provider </div>
<div> </div>
<div>Trusted Connection Response (with key):</div>
<div>Client Consumer <- User Agent <- OpenID Provider</div>
<div> </div>
<div>Trusted Logon:</div>
<div>Client Consumer gives OpenID Identity to Destination Consumer</div>
<div>Destination Consumer -> Client Consumer -> OpenID Provider</div>
<div>Destination Consumer <- Client Consumer <- OpenID Provider</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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:
</div>
<div> </div>
<div>* Inline Authentication - Provide support for legacy and real-time interactive systems that can't launch a web browser, and are protecting their own data (Telnet, etc). This will involve manually-typed verification keys.
</div>
<div>* Desktop Authentication - Provide for desktop applications authenticating with and accessing data behind third-party systems (RSS readers, chat, etc).</div>
<div> </div>
<div>I appreciate any feedback you can give 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 26/08/07, John Ehn <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:john@extremeswank.com" target="_blank">
john@extremeswank.com</a>> wrote:<br>> I have created a draft of a new specification that I think will help to fill <br>> a gap in OpenID functionality.<br>><br>> What appears to be a newer productivity feature of many websites is the
<br>> ability to import and utilize information from other sites. For instance,<br>> Basecamp provides an API that allows other systems to access user data. <br>> This is a great feature, but it currently cannot be done with OpenID, due to
<br>> the dependence on end-user interaction during the authentication process.<br>><br>> The Trusted Authentication Extension provides for the ability for an OpenID <br>> Consumer to log in to another OpenID Consumer without user interaction. The
<br>> end user will be able to create a trusted connection between two OpenID<br>> enabled sites, which will allow a client site to access a destination site <br>> using the end user's Identity.<br>><br>> Please provide your comments and feedback, as they are most appreciated.
<br>><br>> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://extremeswank.com/openid_trusted_auth.html" target="_blank">http://extremeswank.com/openid_trusted_auth.html </a><br><br>I think things would be a bit clearer if you made the data provider
<br>into a form of OpenID Provider.<br><br>I think it helps to first consider the case where the data provider is<br>not an OpenID Relying party but instead has its own user account <br>database.<br><br>If the site acted as an OpenID provider, it would be pretty simple to
<br>use an extension to negotiate an auth token to acess data for the<br>user. Simply start an OpenID authentication request, including some <br>field stating that you want access to data. The provider would then<br>include an authentication token in the response that could be used to
<br>access the web services.<br><br><br>Now lets consider the case where the data provider identifies users by <br>an OpenID. What would happen if the data provider continued to<br>implement an OP, and the data consumer started an OpenID
<br>authentication request with it using the user's data provider.<br><br>This would let us use the same sort of OpenID extension to negotiate <br>the auth token. The data provider could even turn around and perform<br>
its own authentication request to verify that the user is who they say<br>they are, since it received the identity URL from the data consumer.<br><br>So the full workflow might go like this:<br><br>DC: Data Consumer<br>DP: Data Provider
<br>OP: User's OpenID Provider<br><br>1. DC sends checkid_setup request to DP for user's identity URL, with<br>an extension asking to negotiate an auth token. <br>2. DP initiates OpenID authentication for user's identity URL
<br>3. OP verifies user's identity and sends idres reply to DP.<br>4. DP sends idres reply to DC, including the auth token as an<br>extension in the response. <br><br>This seems to give similar results to your protocol while introducing
<br>fewer new concepts. What do you think?<br><br>James.<br></blockquote></div><br>