<br><br><div class="gmail_quote">On Fri, Apr 3, 2009 at 5:05 PM, SitG Admin <span dir="ltr">&lt;<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.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;">
<div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If I were to read the spec on its own as an OP I would probably come to the conclusion that what I need is an interface that shows the RP has requested:<br>
1. A set of information that is purely optional and they will provide service even if the information is not provided.<br>
2. A set of information that the RP may restrict or deny service if I don&#39;t provide.<br>
</blockquote>
<br></div>
The point of overlap there is &quot;restrict&quot;. RP&#39;s could provide some service if their key requirements are met, but additional (optional) attributes would be required to &quot;unlock&quot; other services. Since the RP would not deny service entirely if those additional attributes were withheld, it is not &quot;required&quot;, but service will still be restricted if less than everything is available.<br>

<br>
For instance, a non-specialized Relying Party might provide E-mail alerts, SMS alerts, a dating service, a snail-mail proxy (mail is accepted for you at their address, then they redeliver it to your doorstep without exposing you to home invasion or snail spam), a $25 gift certificate useable at any of their allied stores but only as a birthday present - if you give them an E-mail address they will do #1, if you give them your phone number they will do #2, if you give them your full name they will do #3, if you give them your home address they will do #4, and if you give them your date of birth they will give you #5; there is no single attribute which MUST be present or the whole service is unavailable, but with none of that information they cannot give you anything.</blockquote>
<div><br>An alternative view to this is that front-loading the user account creation experience with requests to disclose a lot of information can lead to sending the user away. A better approach is for incremental disclosure, where requests for the user to disclose specific bits of information appear in the context of the stated need.<br>
<br>An example of this was Plaxo&#39;s decision to not ask for OAuth tokens for Picasa on Google account creation flow, and wait until the users show an interest in the photo-sharing feature to give them that option (along with Flick, etc.)<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>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I let the user select or deselect any of there available attributes and send back a positive response unless the user decides to cancel the login.<br>
This includes not sending back required attributes.<br>
</blockquote>
<br></div>
I strongly agree with this. OP&#39;s should not force an all-or-nothing response upon their users.<br>
<br>
-Shade<div><div></div><div class="h5"><br>
_______________________________________________<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>
</div></div></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>