<br><br><div class="gmail_quote">On Fri, Apr 3, 2009 at 11:31 AM, Breno de Medeiros <span dir="ltr">&lt;<a href="mailto:breno@google.com">breno@google.com</a>&gt;</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;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Fri, Apr 3, 2009 at 11:12 AM, John Bradley <span dir="ltr">&lt;<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>&gt;</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;">
Believe me almost nothing is stranger than me defending MySpace.<br>
<br>
However I think they have done a reasonable job with there OP.<br>
<br>
They are compliant with openID 2.0,  true some older RP libs may have a problem if they are not compliant.<br>
<br>
If a openID 2.0 RP can&#39;t do a authentication at the MySpace OP it is broken!<br>
<br>
The exception to that would be MS health Vault or other sites that by policy don&#39;t allow non SSL connections or require PAPE multi factor etc.   Those are policy decisions by the RP, and are not the OPs responsibility.<br>


<br>
OpenID 2.0 authentications can be performed without associations, Associations are a performance optimization not a security feature.<br>
<br>
If I were MySpace I would have made a SSL OP URI available rather than the http one.<br>
<br>
That would have broken a larger but different set of RPs that don&#39;t support SSL.<br>
<br>
The choice from an OP point of view is, use SSL and exclude all non SSL RPs or have a non SSL URI and prevent RPs that don&#39;t support DH from associating, but they can still authenticate in dumb/stateless mode.<br>
<br>
You can have two endpoints and the RP gets to select the SSL version if it supports SSL.<br>
That seems like a good idea,  but the RP&#39;s who have a discovery lib that can recognize URI priority in the XRDS and fail over properly are not the ones who have the problem.    This is the technically correct solution but probably breaks more RPs than it helps.<br>


<br>
To have SSL be useful it needs to protect the meta-data discovery step.  If I can replace your XRDS/or HTML tags at the RP, I own you!   Securing the rest of the transaction with SSL is as useful as locking your windows and leaving the front door open.<br>


<br>
So if I am MySpace or any other large provider the cost of making all of my user profile pages SSL could run into the millions of dollars.   I would probably think twice about it myself if I were them.<br>
<br>
The choice MySpace made is reasonable.<br>
<br>
No this is not hopeless.  The XRI-TC which now includes representation from Google, Yahoo and others is working on a trust model for signing XRD/S documents.   This will be part of the upcoming XRD 1.0 spec and may find its way into an openID &gt;= 2.1 near you at some point in the future.<br>


<br>
Yes MySpace could include Sreg or better yet AX.   Given that to my knowledge we have one OP that hands out an validated email address in AX (that is still beta, and bends the AX spec),  so I wouldn&#39;t say MySpace is holding things up.<br>


<br>
We have a way to ask for an email address as an optional claim in AX,  a RP needs a white list of OP&#39;s it trusts have verified it, or round trip the email if the OP is not on the validated e-mail white list, and they care.<br>


<br>
What OPs need to do:<br>
Vidoop:  Nothing works now<br>
MyOpenID:  Get with the program and support the standard claim URI., otherwise it would work now.<br>
Google:  Stop ignoring AX requests that are not marked required.   The word doesn&#39;t revolve around you.</blockquote></div></div><div><br>Well, should the world revolve around the users? They keep telling anyone who would listen that they don&#39;t like checkboxes.  Checkboxes are also terrible for accessibility.<br>

<br>Suggestions appreciated.</div></div></blockquote><div><br>I would also note that any OP who implements checkboxes where required fields are checked by default and non-required fields aren&#39;t will return the same answers that the Google OP provides more than 95% of the time. However, their users will be 95% unhappier.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
MySpace: Support AX please<br>
AOL:  Support openID 2.0 + AX<br>
Yahoo:  Support AX<br>
<br>
OP&#39;s have had the specs and tools to do this for a long time now.  It is not like we need to invent something new.<br>
<br>
Lets get what we have working well,  please.<br>
<br>
Regards<br><font color="#888888">
John Bradley<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font><br></div><div class="im">_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></div></blockquote></div><font color="#888888"><br><br clear="all"><br>-- <br>--Breno<br><br>+1 (650) 214-1007 desk<br>+1 (408) 212-0135 (Grand Central)<br>MTV-41-3 : 383-A <br>PST (GMT-8) / PDT(GMT-7)<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>--Breno<br><br>+1 (650) 214-1007 desk<br>+1 (408) 212-0135 (Grand Central)<br>MTV-41-3 : 383-A <br>PST (GMT-8) / PDT(GMT-7)<br>