<div>Here's my two cents on AX if_available vs. required:</div><div><br></div><div>As has already been said, Google is the only OP I've heard of that totally ignores "if_available". Granted, it makes the user experience look simpler while the user is at Google, but then the user goes to the RP and has to enter it anyway. Of course, if the RP was to demand the email address of the user at that point, then perhaps they really should have used 'required' anyway. </div>
<div><br></div><div>'required' suggests that if it isn't there, then authentication fails. But some OPs don't support a given attribute type URI, and this would break authentication... that's bad. So if we admit the OP might ignore the required attribute, then we can expect the RP will demand the attribute of the user when auth completes.</div>
<div><br></div><div>'if_available' suggests if the OP happens to know it, then the RP wants it. This isn't a 'if_user_opts_in' parameter. Which makes it basically the same as 'required', except the OP can feel less badly about not supplying it. </div>
<div><br></div><div>Personally, I'd like checkboxes on each attribute during login. InfoCard is one model that considered required to be absolutely required. A Card cannot be used to login unless it has all the required attributes. In addition, the optional attributes can collectively be turned on or off. Personally, I miss the flexibility of saying, "well yes, I want to supply this optional attribute, but not this one". But I'll submit on this one since most people here feel that most users don't want that flexibility.</div>
<div><br></div><div>I agree that RPs and OPs need a better contract of the semantics of required vs if_available. All the RPs are upgrading their email requests to required so that they work with Google. Apparently they really wanted email and they were getting it until now. Is 'required' the right one to use in the first place? Perhaps. But we should decide this by spec rather than by one company's implementation. If AX 2.0 eliminates "if_available" because it really doesn't make sense to have two levels of demand, I won't care. But let's not let that happen accidentally.</div>
<div><br></div><div>--<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." - Voltaire<br>
<br><br><div class="gmail_quote">On Fri, Apr 3, 2009 at 12:50 PM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">Hi Breno,<div><br></div><div>I will grant you that the choice google has made to deny returning optional claims to the RP without a user dialog makes the UI simpler.</div><div><br></div>
<div>
The problem for RPs is that they may still be willing to accept the login without the email and collect or verify the email in some other manner.</div><div>As other AX claims start getting used this becomes more of an issue. </div>
<div><br></div><div>From a RP point of view OP's dealing with AX requests in a consistent way is a requirement.</div><div><br></div><div>They now have no way of asking for optional claims for form filling during account creation etc if OPs take your approach.</div>
<div><br></div><div>If the issue is a reluctance to give the user fine grained control over the AX attributes returned, I could live with a compromise. </div><div><br></div><div>The "This site is requesting access to additional information listed below" is missing some urgency in my opinion.</div>
<div><br></div><div>It needs to be clear that the information will be returned to the RP.</div><div><br></div><div>At the moment you have two options "Continue Signin" and "Cancel". </div><div><br></div>
<div>Changing that to "Signin with all requested information" , "Signin with only required information" , and "Cancel"</div><div><br></div><div>The optional and required elements above need to be differentiated in some way. </div>
<div><br></div><div>This would reduce the number of check boxes and maintain the spirit of AX optional vs required claims.</div><div><br></div><div>The oAuth + openID solution you are working on is good but perhaps overkill for smaller RPs.</div>
<div><br></div><div>I would like to find a way that AX can work with a consistent claim set in a predictable way.</div><div><br></div><div>By the way we don't have the Google OP listed as a OSIS participant, we have Blogger but not the new OP.</div>
<div><br></div><div>Let me know if you want to participate in I5 this year.</div><div><br></div><div>I am happy to work on AX issues with you, though UX is not my area of expertise as you know:)</div><div><br></div><div>
Regards</div>
<div>John Bradley</div><div><br></div><div><br><div><div>On 3-Apr-09, at 11:31 AM, Breno de Medeiros wrote:</div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<br></blockquote></div></blockquote><div><Snip></div><br><blockquote type="cite"><div class="im"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<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't revolve around you.</blockquote>
<div><br>Well, should the world revolve around the users? They keep telling anyone who would listen that they don't like checkboxes. Checkboxes are also terrible for accessibility.<br> <br>Suggestions appreciated.<br>
</div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><br> MySpace: Support AX please<br> AOL: Support openID 2.0 + AX<br> Yahoo: Support AX<br>
<br> OP'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></font></blockquote></div></div>T-8) / PDT(GMT-7)<br></blockquote></div><br></div></div><br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></blockquote></div><br></div>