<br><br><div class="gmail_quote">On Fri, Apr 3, 2009 at 5:05 PM, SitG Admin <span dir="ltr"><<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.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;">
<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't provide.<br>
</blockquote>
<br></div>
The point of overlap there is "restrict". RP's could provide some service if their key requirements are met, but additional (optional) attributes would be required to "unlock" other services. Since the RP would not deny service entirely if those additional attributes were withheld, it is not "required", 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'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'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>