[OpenID] About Facebook, MySpace and OpenID

Andrew Arnott andrewarnott at gmail.com
Sun Apr 5 02:11:16 UTC 2009

How can the value of the email address attribute change for a Google  

Sent from my iPhone

On Apr 4, 2009, at 6:37 PM, Breno de Medeiros <breno at google.com> wrote:

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

More information about the general mailing list