Forking thread...<div><br><div>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...<div><br></div>
<div>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...</div>
<div><br></div><div>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. </div>
<div><br></div><div>So far, I've not added any value to OpenID+artifact binding. </div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. :)</div>
<div><br clear="all">--<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><div class="gmail_quote">On Thu, Jan 28, 2010 at 3:02 AM, Nat Sakimura <span dir="ltr"><<a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="im">
(2010/01/28 16:21), Allen Tom wrote:
<blockquote type="cite">
<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>
</span></font></blockquote></div>
I add one more thing here: Many mobile browsers choke. <br><div class="im">
<blockquote type="cite"><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>
</span></font></blockquote></div>
Artifact Binding :-) Our implementation is returning (for the
experiment purpose) assertion that is well over 5MB with AX. <br>
<br>
=nat<br>
<blockquote type="cite"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
Allen<br>
</span></font><div class="im">
<pre><fieldset></fieldset>
_______________________________________________
specs mailing list
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</div></blockquote><div class="im">
<br>
<br>
<pre cols="72">--
Nat Sakimura (<a href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547</pre>
</div></div>
<br>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br></blockquote></div><br></div></div></div>