[OpenID] About Facebook, MySpace and OpenID

Andrew Arnott andrewarnott at gmail.com
Sun Apr 5 03:40:16 UTC 2009

The scenario you ask about doesn't exist.  With Google, the user can't
opt-out of sending the email address.  Either Google totally ignores the
email request because it's in if_available, or the RP puts it in 'required',
and then Google won't complete auth at all without the user's consent to
include the email.

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire

On Sat, Apr 4, 2009 at 8:29 PM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  If I’m an RP taking authenticated comments from a google subscriber for
> the first time and the user denies the release of the optional email
> attribute, is there any way for the user to release it the next time s/he
> attempts to post a comment?
> i.e. depending on the nature of the  comment or the thread, the user may
> wish  to release or not release the email identifier (to signal that
> followup email dialog is available, or to receive events that the comments
> received followup). Lets assume that the site processing the comments does
> not maintain an account for the commenting user.
> *From:* general-bounces at openid.net [mailto:general-bounces at openid.net] *On
> Behalf Of *Breno de Medeiros
> *Sent:* Saturday, April 04, 2009 6:38 PM
> *To:* Deron Meranda
> *Cc:* general; John Bradley
> *Subject:* Re: [OpenID] About Facebook, MySpace and OpenID
> 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
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090404/5f9368f8/attachment-0002.htm>

More information about the general mailing list