[OpenID] About Facebook, MySpace and OpenID

Breno de Medeiros breno at google.com
Sat Apr 4 00:07:00 UTC 2009


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

> Don't get me started on OPs that are not returning AX attributes in the
> signed part of the response:)
>
> Or using deprecated AX URI.
>
> You did get the wire level correct.
>
> It is the higher level User/RP/OP interaction around the notions of
> required and if_available where we see divergence between OP's and
> corresponding issues with RPs not being certain of what will happen if they
> as for required attributes at any given OP.


Not being a mind-reader, I don't know what the writers of the AX spec had in
mind, but I believe that: for the most value to be made of AX by RPs the OPs
should try to succeed whenever possible, i.e., the only possible failure
reason should be that the user hits 'cancel'.

E.g.:

Behavior implemented by Google.

1. RP asks for email and movie preferences as 'required", but I don't know
the user's movie preferences.
2. OP silently drops the movie preferences from the request, presents the
user with the option to enter his email address and responds accordingly.

Alternative no 1: Ask the user at the OP.

1. RP asks for email and movie preferences as 'required", but I don't know
the user's movie preferences.
2. OP prompts the user to enter his movie preferences. However, the OP does
not have a legitimate business need to collect the users movie preferences.
May have to develop entirely different privacy policies around this issue.
BAD for UX, costly for OPs to implement.

Alternative no 2: Fail
1. RP asks for email and movie preferences as 'required", but I don't know
the user's movie preferences.
2. OP cancels the request on the basis that he does not know the user's
movie preferences.
BAD for interoperability, BAD for value of the extension.



>
> John Bradley
>
> On 3-Apr-09, at 4:25 PM, Breno de Medeiros wrote:
>
>  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.
>>
>>
>>
>


-- 
--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/1d5d2afe/attachment-0002.htm>


More information about the general mailing list