<p>It is not true that you need to request all your attributes for the Google OP or else you will be locked out. If you add a request for a new attribute we will prompt the user to authorize and then send it.  That also happens if the value of the attribute changed since the user approved (re-prompt and send). </p>

<p><blockquote>On Apr 3, 2009 9:35 PM, &quot;Deron Meranda&quot; &lt;<a href="mailto:deron.meranda@gmail.com">deron.meranda@gmail.com</a>&gt; wrote:<br><br>On Fri, Apr 3, 2009 at 11:08 PM, Andrew Arnott &lt;<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>&gt; wrote:<br>

&gt; ... All the RPs are upgrading their email requests to required<br>
<p><font color="#500050">&gt; so that they work with Google.  Apparently they really wanted email and they
&gt; were getting it unt...</font></p>Maybe its useful to think about attributes other than email to see<br>
where &quot;optional&quot; perhaps makes more sense.<br>
Consider a possible Time Zone attribute (yes SReg has this).  This is a case<br>
where it is easier to see what an RP might mean by &quot;optional&quot; -- that if the<br>
OP can provide it it wants it; but if not, the RP still wants the authentication<br>
to proceed and not to fail, because it can deal easily enough with not<br>
getting the time zone.<br>
It could also be argued that the OP *should* ask the user which optional<br>
attributes it wants to give.  You might not think time zone is important<br>
enough to ask the user for permission; unless perhaps your time zone<br>
happened to be America/Havana for example and you didn&#39;t want this<br>
RP to know you&#39;re in Cuba.<br>
I can see Google&#39;s perspective on this; and it is a combination of<br>
trying to make a simple UI for non-technical users (which we all<br>
agree is something OpenID desperately needs), as well as the<br>
spec being somewhat silent on what its expectations are for the<br>
OP and RP.<br>
However, at this point, with Google&#39;s current interpretation, there is<br>
effectively no utility in having optional attributes.  The distinction is<br>
made meaningless.  And since we don&#39;t want RP&#39;s to special-case per<br>
OP; then effectively, in practice today anyway, it is pointless for<br>
OpenID AX to pretend there is an optional/required dimension.<br>
Now one can argue that Google is right and the spec was trying to<br>
make two categories when only one made sense; or that Google is<br>
wrong and OPs should definitely treat optional attributes differently<br>
than required ones.  I&#39;m not sure which is correct; but I do think<br>
that the spec should be made very clear one way or the other.<br>
Because if the behavior is left up to the OP, as Google has done, then<br>
the spec is made pointless in practice and its all just unnecessary<br>
noise words.<br>
I would say, another thing that Google does that may play into all<br>
this is that they don&#39;t always send AX attributes back at all.  If the<br>
RP and OP have communicated before concerning a certain<br>
identity; then the RP may actually get no attributes whatsoever<br>
on subsequent interactions (Google assumes that the RP will<br>
remember these attributes the first time, which means that in<br>
practice the RP will be forced to remember these attributes).<br>
This also coerces the RP to try to request ALL the attributes it thinks<br>
it might ever need the very first time it interacts with Google.  And since<br>
it also using is directed identity (where the RP doesn&#39;t know the identity<br>
before hand), this effectively means that the RP is going to have to<br>
request all the possible AX attributes it might ever desire for any user,<br>
effectively as a *requred* attribute, on every single request!  Because if<br>
it guesses wrong and decides not to ask for a particular attribute even<br>
once, it may then be locked out of ever getting that attribute in the future.<br>
This makes it very hard to implement an RP.  Either it asks for too<br>
many attributes, and the authentication fails because the user doesn&#39;&#39;t<br>
want to return ALL of them (or Google doesn&#39;t support a hypothetical<br>
Time Zone AX attribute and treats optional as-if required so it fails).<br>
--  Or on the other hand the RP doesn&#39;t ask for enough attributes; but<br>
then has to live with never being able to ask for them in the future when<br>
it later decides it does want to know them.<br>
And the directed identity on top of this means the RP has to make this<br>
difficult choice just once per OP, rather than a finer grained per identity.<br>
I think this existing behavior, although defensible from Google&#39;s<br>
perspective; pretty much renders a good portion of the AX spec<br>
completely useless.<br>
Either an RP is never going to use AX at all because it doesn&#39;t want<br>
to risk causing an authentication to fail; or an RP is always going to<br>
request as many attributes as possible all as required (even if it<br>
doesn&#39;t need them right now), because it doesn&#39;t want to miss out on<br>
it&#39;s one chance to get that information the first time.<br>
<font color="#888888">Deron Meranda<br>