<html><body bgcolor="#FFFFFF"><div>How can the value of the email address attribute change for a Google account?<br><br>Sent from my iPhone</div><div><br>On Apr 4, 2009, at 6:37 PM, Breno de Medeiros &lt;<a href="mailto:breno@google.com">breno@google.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><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.&nbsp; That also happens if the value of the attribute changed since the user approved (re-prompt and send). </p>

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

> ...&nbsp;All the RPs are upgrading their email requests to required<br>
<p><font color="#500050">> so that they work with Google. &nbsp;Apparently they really wanted email and they
> were getting it unt...</font></p>Maybe its useful to think about attributes other than email to see<br>
where "optional" perhaps makes more sense.<br>
<br>
Consider a possible Time Zone attribute (yes SReg has this). &nbsp;This is a case<br>
where it is easier to see what an RP might mean by "optional" -- 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>
<br>
It could also be argued that the OP *should* ask the user which optional<br>
attributes it wants to give. &nbsp;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't want this<br>
RP to know you're in Cuba.<br>
<br>
I can see Google'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>
<br>
<br>
However, at this point, with Google's current interpretation, there is<br>
effectively no utility in having optional attributes. &nbsp;The distinction is<br>
made meaningless. &nbsp;And since we don't want RP'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>
<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. &nbsp;I'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>
<br>
<br>
I would say, another thing that Google does that may play into all<br>
this is that they don't always send AX attributes back at all. &nbsp;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>
<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. &nbsp;And since<br>
it also using is directed identity (where the RP doesn'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! &nbsp;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>
<br>
This makes it very hard to implement an RP. &nbsp;Either it asks for too<br>
many attributes, and the authentication fails because the user doesn''t<br>
want to return ALL of them (or Google doesn't support a hypothetical<br>
Time Zone AX attribute and treats optional as-if required so it fails).<br>
-- &nbsp;Or on the other hand the RP doesn'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>
<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's<br>
perspective; pretty much renders a good portion of the AX spec<br>
completely useless.<br>
<br>
Either an RP is never going to use AX at all because it doesn'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't need them right now), because it doesn't want to miss out on<br>
it's one chance to get that information the first time.<br>
--<br>
<font color="#888888">Deron Meranda<br>
</font></blockquote><p></p>
</div></blockquote></body></html>