I've been reading more on oauth and found some of my own mistakes about it :)<br><br>Your issues with my proposal are also valid. I hope to become active with oauth and hopefully their list can address my remaining concerns :)
<br><br><div><span class="gmail_quote">On 8/1/07, <b class="gmail_sendername">Brendan Taylor</b> <<a href="mailto:whateley@gmail.com">whateley@gmail.com</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 Mon, Jul 30, 2007 at 06:54:07PM -0400, Stephen Paul Weber wrote:<br>> Hello lists!<br>> I have been reading the specs on API auth systems such as OpenAuth, WSSE,<br>> Facebook API, Google AuthSub, and others. Based on this reading and my
<br>> experiences implementing different auth systems, I have created a draft for<br>> a generic third-party API auth system that will work fine with OpenID,<br>> username/password, or anything else <<br>>
<a href="http://webos.singpolyma.net/Authentication/TEP">http://webos.singpolyma.net/Authentication/TEP</a>>.<br><br>I've been using OpenAuth (John Panzer's proposal[1], which is only<br>loosely related to AOL's token-based system) to authenticate Atom
<br>Publishing Protocol requests using OpenID. It works very well (and I<br>intend to get around to writing it up...), I'd just like to correct<br>a couple of things you said about it on that page:<br><br>- it doesn't require an API key
<br>- it doesn't use XML or JSON, all data is passed around in URL<br> parameters<br><br>I can see how being able to request sessions of a particular length<br>would be useful, though and obviously an unstealable token is a good
<br>idea.<br><br>As for your proposal:<br><br>- how exactly are the client and server performing the Diffie-Hellman<br> exchange?<br><br>- unless i'm misunderstanding something, if the session key is being<br> passed back to the client in cleartext, it's still stealable.
<br><br>- why does the client need to verify the session key? surely it's the<br> service that needs to authenticate the client, rather than the other<br> way around?<br><br>1: <<a href="http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/05/04/aol-openauth-and-atom-publishing-protocol/1440">
http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/05/04/aol-openauth-and-atom-publishing-protocol/1440</a>><br></blockquote></div><br><br clear="all"><br>-- <br>- Stephen Paul Weber, Amateur Writer<br><
<a href="http://www.awriterz.org">http://www.awriterz.org</a>><br><br>MSN/GTalk/Jabber: <a href="mailto:singpolyma@gmail.com">singpolyma@gmail.com</a><br>ICQ/AIM: 103332966<br>BLOG: <a href="http://singpolyma.net/">http://singpolyma.net/
</a>