+1 Also, having the sunset / expiry of the SREG 1.1 might be a good idea. <br><br>When we are doing spec work, it would be a good idea to consider implementing an incentive for convergence, I suppose. <br><br>=nat<br><br><div class="gmail_quote">
On Wed, Jan 28, 2009 at 6:26 PM, Dick Hardt <span dir="ltr"><<a href="mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
+1 to a separate WG to fix SREG. Adding language to SREG 1.1 recommending AX for new development would clarify for the community the direction. (I'm presuming there is consensus on one spec long term and that the extensibility of AX is preferred)<br>
<font color="#888888">
<br>
-- Dick</font><div><div></div><div class="Wj3C7c"><br>
<br>
On 27-Jan-09, at 6:30 PM, Allen Tom wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I agree with Martin. I believe that AX is the correct solution in the long run, but given that there appears to be more SREG implementations currently in the wild, we should update it to make it useful for sites that want to use it.<br>
<br>
The other factor is that our lawyers feel very strongly that the user should have the opportunity to read the RP's privacy policy before authorizing any data exchange, and only SREG has the ability to do this automatically. The alternative would be to use OAuth, and require RPs to pre-register with Yahoo and provide their privacy policy and/or agree to a ToS before using our OP.<br>
<br>
Allen<br>
<br>
Martin Atkins wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I agree that having both is not ideal, but I also feel strongly that we need to have a good SREG 1.1 spec because in practice today there are lots of SREG implementations and it is important to be able to interoperate with them even if in the long term we'd like to move to AX.<br>
<br>
This is, incidentally, why I was previously proposing forming an SREG group whose task is *only* to fix the spec to reflect current practice. This should encourage SREG interop in the short term while new developments to AX will encourage a move to AX in the longer term.<br>
<br>
</blockquote>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
</blockquote>
<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>