[OpenID] About Facebook, MySpace and OpenID

Fri Apr 3 23:25:33 UTC 2009

It is certainly true of the Google team that we tried to optimize the UI for
non-OpenID-savvy users (which will be the vast majority in our case). It is
also true that we thought we were fully compliant with the AX spec. To put
it another way, RPs that 'break' as a result of our behavior would be in
violation of the AX spec as currently written.

On Fri, Apr 3, 2009 at 4:08 PM, John Bradley <john.bradley at wingaa.com>wrote:

> In fairness google is interpreting required as required.
>
> The issue is that they are treating optional as ignored to simplify the UX.
>
> Any number of OPs allow you to customize persona, for Sreg and AX.
>
> I have no problem with OPs targeting there services to different audiences.
>
> I suspect that PIP knows that there users are more sophisticated or
> at-least wanted an openID or they wouldn't have signed up.
>
> Google on the other hand has to support people who have never been exposed
> to openID and just clicked on a button at Plaxo or someplace.
>
> I am not saying that PIP and Google could or should have the same UX.
>
> Only that RP's need a consistent response across all OPs for AX requests
> otherwise they have no reason to adopt it.
>
> One of the areas where I don't currently have a AX test is for the behavior
> of an OP when it doesn't have a required attribute.
>
> If we look at the spec:
> ------
> openid.ax.required
> Value: an attribute alias, or a list of aliases corresponding to the URIs
> defined by "openid.ax.type.<alias>" parameters. Multiple attribute aliases
> are separated with a comma, ",".
>
> By requesting attributes using this field, a hint is sent to the OP about
> the RP's requirements for offering certain functionality and should be used
> by the OP to help the user decide what attributes to release. RP's
> requirements should not be enforced by the OP.
>
> The RP should offer, out of band of attribute exchange, an alternate method
> of collecting the attributes it needs, if they weren't obtained via
> attribute exchange.
>
> openid.ax.if_available
> Value: an attribute alias, or a list of aliases corresponding to the URIs
> defined by "openid.ax.type.<alias>" parameters. Multiple attribute aliases
> are separated with a comma, ",".
>
> Attributes requested using this field are deemed optional by the RP; the RP
> should be able to complete the interaction with the user even if values are
> not provided by the OP for the optional attributes.
>
> ---------
>
> It is clear that the RP can expect to get a response back and continue the
> transaction if the OP doesn't provide the value.
>
> On the other hand the language for required was written by a politician.  A
> hint that the RP may not provide certain functionality without the value.
>
> Is certain functionality declining the login or making the user manually
> input a email to verify?
>
> I can read Googles interpretation  into the above spec however that is
> clearly not how others interpret it.
>
> 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:
> 1. A set of information that is purely optional and they will provide
> service even if the information is not provided.
> 2. A set of information that the RP may restrict or deny service if I don't
> provide.
>
> 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.
> This includes not sending back required attributes.
>
> The RP is guaranteed to get a response and needs to figure out what to do
> with the user as a result of that.
>
> I don't think anyone is exactly following my reading mostly because they
> are looking at the name openid.ax.required and not the normative text.
>
> Until there is a  consensus around the user level flow for AX it is hard
> for me to crate more detailed tests or even determine success of failure of
> anything above the protocol layer.
>
> Regards
> John Bradley
>
> On 3-Apr-09, at 3:01 PM, Deron Meranda wrote:
>
>  On Fri, Apr 3, 2009 at 3:50 PM, John Bradley <john.bradley at wingaa.com>
>> wrote:
>>
>>> I will grant you that the choice google has made to deny returning
>>> optional
>>> claims to the RP without a user dialog makes the UI simpler.
>>> The problem for RPs is that they may still be willing to accept the login
>>> without the email and collect or verify the email in some other manner.
>>>
>>
>> Yes, this is exactly the "problem" I have with Google's way of
>> interpreting
>> optional to mean required.  It's not optional for the user, it's optional
>> for Google.
>>
>>
>> Another slight annoyance, perhaps specific to Google, is that even if I
>> have
>> it return an email address, I don't get to pick it.
>>
>> Basically, any Google account can have a lot of different email addresses.
>> First, you can just add or remove periods (dots) where-ever
>>  http://mail.google.com/support/bin/answer.py?hl=en&answer=10313#
>> or you can also make up address aliases
>>  http://mail.google.com/support/bin/answer.py?answer=12096&topic=13271
>>
>> I may want to give out my primary address for my bank's blog,
>> but a different one for my neighbor's.
>>
>>
>>  From a RP point of view OP's dealing with AX requests in a consistent way
>>> is
>>> a requirement.
>>>
>>
>> Agree.
>>
>> Some OPs like Verisign PIP let me customize my attribute return
>> values (albeit SREG rather than AX) almost to the extreme opposite of
>> Google: per-RP answers, multiple AX profiles for default answers, etc.
>>
>> --
>> Deron Meranda
>>
>
>

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090403/36ff478b/attachment-0002.htm>