Joseph,<br>
<br>
Any help you could provide to flesh out (or heavily modify) these specs would be most appreciated.<br>
<br>
Thanks,<br>
<br>
John Ehn<br><a href="http://extremeswank.com">extremeswank.com</a><br><br><div><span class="gmail_quote">On 10/22/07, <b class="gmail_sendername">Joseph Holsten</b> <<a href="mailto:joseph@josephholsten.com">joseph@josephholsten.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;">Wow, these are neat. Thanks for the links david, and especially the<br>
work john!<br><br>OK, so the Inline Auth use case seems like a straightforward case for<br>OAuth: resource url => identifier, user auth url => delegate.<br>Successfully accessing the resource after negotiation would imply
<br>that the user still trusts the RP. Seems like low hanging fruit.<br>Also, gets the benefit of single sign off!<br><br>I'm a little unsure about the best way for the Trusted Auth use case.<br>This seems quite good, but a diagram of an oauth solution to the
<br>problem was on the mailing list not long ago. Same as the official<br>diagram, but with a third column showing interactions between the<br>"Consumer Directs User to Service Provider" and "Service Provider
<br>Directs User to Consumer" steps. I looked for half an hour, found<br>nothing, but I'm not crazy really! Anyway, it would be nice to<br>compare perspectives first.<br><br>But if I remember correctly, the oauth proposal only allowed the
<br>"Service Provider"/"Destination Consumer" to revoke resource access,<br>while openid trusted auth gives that right to the OP. Greater<br>overhead versus greater user control.<br><br>So who's interested in fleshing out these recommendations into specs?
<br><br>http:/ joseph holsten .com<br><br><br>On 02007:10:22, at 3:54CDT, David Recordon wrote:<br><br>> Hey all,<br>> I know John did some work in September (<a href="http://extremeswank.com/">http://extremeswank.com/
</a><br>> openid_trusted_auth.html and <a href="http://extremeswank.com/">http://extremeswank.com/</a><br>> openid_inline_auth.html). Both solve extremely important use-cases<br>> and are becoming increasingly discussed especially with the advent of
<br>> OAuth. I'd really like to see how we can work to write an extension<br>> to OpenID Authentication where the OpenID Provider is also the one<br>> handling OAuth credentials. This would be useful in the inline
<br>> authentication use case as well as if we move to a deployment<br>> scenario where the OAuth Provider is checking with the user's OpenID<br>> Provider to verify OAuth signatures. Overtime I also think moving
<br>> OpenID to the OAuth signature mechanism would be beneficial, but I<br>> think that is a longer conversation.<br>><br>> --David<br>><br>> _______________________________________________<br>> specs mailing list
<br>> <a href="mailto:specs@openid.net">specs@openid.net</a><br>> <a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a><br><br>_______________________________________________
<br>specs mailing list<br><a href="mailto:specs@openid.net">specs@openid.net</a><br><a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a><br></blockquote></div><br>