<HTML>
<HEAD>
<TITLE>Re: OAuth WRAP as next-gen OpenID? (WAS: Problem with nonces and HTTP GET)</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I’m not that familiar with Twitter’s API, however they turned Oauth into an Authentication protocol by just implementing an Oauth protected REST web service that just returns the identity of the user. After getting the Oauth Access Token, the client calls the verify_credentials API to figure out who the user is.<BR>
<BR>
<a href="http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0verify_credentials">http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0verify_credentials</a><BR>
<BR>
Conceptually, the Oauth Access Token is kind of like an Artifact. The actual data that’s returned by the verify_credentials API is equivalent to an Assertion.<BR>
<BR>
With regards to WRAP, I’d be interested in seeing an OpenID/WRAP Hybrid Extension. In fact, I think the existing OpenID/Oauth Hybrid is pretty close to WRAP. All we have to do is get rid of the Access Token secret and all the Oauth sigs, and we’d be done. I think this could be used to implement Artifact Binding.<BR>
<BR>
Allen<BR>
<BR>
<BR>
<BR>
On 1/28/10 6:29 AM, "Andrew Arnott" <<a href="andrewarnott@gmail.com">andrewarnott@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Forking thread...<BR>
<BR>
Hmm.... so my disclaimer here is that I haven't read Nat's spec on artifact binding, so perhaps what I'm suggesting is almost the same thing as you've already got...<BR>
<BR>
Allen had mentioned that artifact binding requires sharing state potentially across data centers, which is difficult. And some have mentioned on this and/or the general list (I forgot which) that Twitter's OAuth authentication is sort of next-gen OpenID (which I've never understood). But I wonder... if we're going with the artifact approach anyway, would using OAuth WRAP make sense here? Consider...<BR>
<BR>
The RP/consumer sends the user to the IdP/OP/SP to authorize an OAuth WRAP token, and the OP sends the user back to the RP with a small message. The RP then requests the authorized token (I forgot the exact terminology here in the WRAP spec) from the IdP, and uses that token to request authentication status for the authorizing user, along with any attributes the RP needs. So it's out of band, can result in a large response, or whatever. <BR>
<BR>
So far, I've not added any value to OpenID+artifact binding. <BR>
<BR>
Except that between the authorizing of the token and when the RP finally asks for attributes, the IdP hasn't had to store any artifact or state of the user, since the WRAP token is self-signed by the token issuer and contains the information the RP is allowed to request.<BR>
<BR>
The OAuth WRAP token MAY still be valid. Even if for a very short time, it would allow the RP to "replay" this token, possibly solving the problem of the RP's return_to page being re-fetched (although probably not by itself since the RP would still have to know not to re-authorize the token). But it would also allow the RP to auto-log-off the user if the IdP began reporting that the user was logged off.<BR>
<BR>
Just a thought. But it does seem that OpenID+artifact is a substantial change from 2.0, so it's interesting to consider equally large change alternatives that are already adopted just in case they make sense. There's obviously a lot here that I haven't discussed or even considered, so feel free to trash the idea. :)<BR>
<BR>
--<BR>
Andrew Arnott<BR>
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<BR>
<BR>
<BR>
On Thu, Jan 28, 2010 at 3:02 AM, Nat Sakimura <<a href="n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
(2010/01/28 16:21), Allen Tom wrote: <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> Hi all -<BR>
<BR>
Before I get started – I agree that in an ideal world, we’d have full end to end SSL, old browsers would be banned, and we’d POST data.<BR>
<BR>
However, requiring RPs to support SSL isn’t going to help adoption and is deal breaker for most applications that want to use OpenID today. Encouraging RPs to use SSL is a great idea – but it should not be required. <BR>
<BR>
Although most browsers can support URLs > 2KB, some proxy servers choke on URLs > 2KB. This is not fun to debug.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I add one more thing here: Many mobile browsers choke. <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
In practice, enforcing the nonce only gives the illusion of additional security. If there’s a MITM, instead of replaying (or pre-playing) the assertion, the attacker will just steal the browser cookies instead. Assertions should have a limited lifetime – but this can be enforced by checking the timestamp and allowing for a narrow replay window.<BR>
<BR>
POST is technically the ideal solution, but results in a degraded UX. The proprietary market leaders have set the bar very high and we need to offer an open alternative that is just as good, if not better. We really aren’t going to get anywhere with a clunky UX. POST adds additional latency, and can cause strange warnings and a blank interstitial (the self submitting form). <BR>
<BR>
I really would like to be able to return an assertion using AX with a lot of attributes, and Hybrid that can fit within the 2KB limit. This is needed just to reach parity with the proprietary stuff.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Artifact Binding :-) Our implementation is returning (for the experiment purpose) assertion that is well over 5MB with AX. <BR>
<BR>
=nat<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
Allen<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
specs mailing list<BR>
<a href="specs@lists.openid.net">specs@lists.openid.net</a><BR>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE>
</BODY>
</HTML>