Account recovery

Breno de Medeiros breno at google.com
Fri Jan 23 05:35:21 UTC 2009


The operation of the Google Accounts OP may not appear very intuitive
at first for RP developers, but it is a compromise between two
desirable behaviors:

1. Users prefer to have the choice to enable auto-approval.
2. Users like being able to review requests to disclose
privacy-sensitive attributes about themselves, such as email.

Knowing that these desirable constraints were somewhat in conflict, I
actually asked this question to several developers in the OAuth Summit
at Yahoo in 2008 and I believe it was actually Joseph Smarr (Plaxo)
who suggested that we send the email only the first time.

The current behavior is an approximation of this which I personally
think makes developers lives easier by being more easily testable,
while still satisfying (1) + (2). For instance, a developer can see
what happens by accepting auto-approval and then making the Google
Accounts OP revert to the behavior of sending the email by visiting
https://www.google.com/accounts/ManageAccount, then selecting "Change
authorized websites" and revoking their test site from the list.

On Thu, Jan 22, 2009 at 8:10 PM,  <chris.messina at gmail.com> wrote:
> Ah, good to know. So should be the common pattern?
>
> Chris
>
> On 1/22/09, Breno de Medeiros <breno at google.com> wrote:
>> On Thu, Jan 22, 2009 at 7:35 PM,  <chris.messina at gmail.com> wrote:
>>> My understanding is that Google only returns the Gmail address the
>>> first time it's requested, rather than every time.
>>
>>
>> That is not accurate. The Google OP returns the email address
>> _whenever_ it prompts the user for permission to do so. This could be
>> everytime, if the user never opts for "auto approval" of requests.
>>
>>
>>>
>>> Some devs on the Google login mailing lists have expressed frustration
>>> over this, so I'm curious if there's a rationale/ best practice around
>>> this.
>>>
>>> Chris
>>>
>>> On 1/22/09, Breno de Medeiros <breno at google.com> wrote:
>>>> For the record, the Google OP only returns validated email addresses.
>>>> It is possible to create Google Accounts for some Google properties
>>>> without validating the email address but the Google OP will not assert
>>>> these emails, since otherwise RPs would not be able to accept any
>>>> non-Gmail address from Google without independent validation.
>>>>
>>>> It is quite possible that some RPs would be happy to get any email
>>>> address from Google users, and I hope AX 2.0 will also allow for RPs
>>>> to communicate that they do not require validation, and OPs to give an
>>>> answer + convey the information whether they were validated or not.
>>>> This way the RPs will always be able to provide users with optimal
>>>> experience.
>>>>
>>>> On Thu, Jan 22, 2009 at 6:09 PM, Martin Atkins <mart at degeneration.co.uk>
>>>> wrote:
>>>>> Allen Tom wrote:
>>>>>>
>>>>>> In Yahoo's case (and as I believe Google's case), the only email
>>>>>> address
>>>>>> that we return is the @yahoo.com address that is bound to the user's
>>>>>> account. It is more than just a verified email address, the OP is
>>>>>> actually
>>>>>> the authority for email address.
>>>>>
>>>>> My Google account uses a non-gmail email address, and Google returns
>>>>> this
>>>>> in
>>>>> AX responses.
>>>>>
>>>>> I believe Plaxo currently just takes anything from Google's OP as
>>>>> verified,
>>>>> which seems sane to me.
>>>>>
>>>>>> It would be great if there was a way for an RP to discover if the
>>>>>> user's
>>>>>> OP is authoritative for the user's email address.
>>>>>>
>>>>>
>>>>> I still think that using the email address *as* the OpenID identifier is
>>>>> the
>>>>> best way to achieve this. A prerequisite of that is to somehow support
>>>>> discovery on the email address which allows you to determine which
>>>>> OpenID
>>>>> provider is authoritative for it.
>>>>>
>>>>> In Yahoo's case where directed identity is used I would expect this to
>>>>> manifest as a directed identity response with the identity set to
>>>>> mailto:username at yahoo.com, at which point the RP would do discovery on
>>>>> that
>>>>> email address (using a mechanism still to be determined) and find that
>>>>> the
>>>>> OP is indeed allowed to make assertions for that email address, just as
>>>>> we
>>>>> do for HTTP URLs today.
>>>>>
>>>>> _______________________________________________
>>>>> user-experience mailing list
>>>>> user-experience at openid.net
>>>>> http://openid.net/mailman/listinfo/user-experience
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --Breno
>>>>
>>>> +1 (650) 214-1007 desk
>>>> +1 (408) 212-0135 (Grand Central)
>>>> MTV-41-3 : 383-A
>>>> PST (GMT-8) / PDT(GMT-7)
>>>> _______________________________________________
>>>> user-experience mailing list
>>>> user-experience at openid.net
>>>> http://openid.net/mailman/listinfo/user-experience
>>>>
>>>
>>>
>>> --
>>> Chris Messina
>>> Citizen-Participant &
>>>  Open Web Advocate-at-Large
>>>
>>> factoryjoe.com # diso-project.org
>>> citizenagency.com # vidoop.com
>>> This email is:   [ ] bloggable    [X] ask first   [ ] private
>>> _______________________________________________
>>> user-experience mailing list
>>> user-experience at openid.net
>>> http://openid.net/mailman/listinfo/user-experience
>>>
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>> _______________________________________________
>> user-experience mailing list
>> user-experience at openid.net
>> http://openid.net/mailman/listinfo/user-experience
>>
>
>
> --
> Chris Messina
> Citizen-Participant &
>  Open Web Advocate-at-Large
>
> factoryjoe.com # diso-project.org
> citizenagency.com # vidoop.com
> This email is:   [ ] bloggable    [X] ask first   [ ] private
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)



More information about the user-experience mailing list