[OpenID] [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Combining Google & Yahoo user experience research

Nat sakimura at gmail.com
Mon Oct 27 12:44:40 UTC 2008


Perhaps you can construct a PAPE policy that signifies the verified  
email and send the email by SREG.

=nat at TOKYO via iPhone

On 2008/10/27, at 21:21, George Fletcher <gffletch at aol.com> wrote:

> In the discussions I've had, there was one other use case. That is a
> site that isn't ready yet to support the full OpenID cross-domain SSO
> concept, yet wants to streamline their registration process such that
> they don't have to use the out-of-band email verification  
> mechanism.  In
> this case, a small extension to the OpenID protocol (similar in  
> concept
> to AX) could be constructed that would allow a user to verify their
> ownership over the email address using a "synchronous" process vs the
> current async one.  So, if the RP's only concern is to verify that the
> user "owns" the email address they've specified, then the RP doesn't
> want the email address mapped to an OpenID, they want to know that the
> email address is valid and the user knows the password to it.
>
> This use case isn't really related to OpenID other than it's  
> possible to
> use the current flow and protocol (with a small extension) to  
> implement
> it. If AX is about exchanging attributes, this would be an extension  
> to
> "verify" attributes:)
>
> Thanks,
> George
>
> Chris Messina wrote:
>> On Sat, Oct 25, 2008 at 3:03 AM, George Fletcher <gffletch at aol.com>  
>> wrote:
>>
>>> I think there are at least two use cases involving email addresses  
>>> that
>>> can be easily confused...
>>>
>>> 1. Use the email address as an indicator or pointer to a valid  
>>> OpenID as
>>> the email address is an identifier that the user currently  
>>> remembers.
>>>  - this is the use case that EAUT is targeting and, if I understood
>>> correctly, what Chris is discussing as well
>>>
>>
>> Yes. The point is, until MySpace users become familiar with using
>> their "MySpace OpenID" or "OpenID" (depending on how we recommend
>> MySpace market this behavior), we have ample reason to make it
>> possible for people to use identifiers with which they're already
>> familiar and use in common practice to sign in to web services:
>> namely, email addresses.
>>
>> It also would provide a means to "upgrade" legacy accounts keyed to
>> email addresses to use remote authentication via OpenID... reducing
>> the need to remember discreet passwords (or sharing a unique password
>> between sites).
>>
>> Although there will be increasing numbers of URL-formatted/based
>> identifiers out there for people to use for OpenID authentication, it
>> seems that a great way to simplify OpenID's offering and to make it
>> more palatable to those who argue that they identify themselves by an
>> email address is indeed to figure out the best way to enable that
>> possibility, and to disarm that argument.
>>
>>
>>> 2. Verify an email address for those RP's that want/need/require a
>>> "verified email address"
>>>  - this is more about the RP getting a verified identity attribute
>>>  - the expectation is that an OpenID based flow would allow a user  
>>> who
>>> has to verify their email address to do it in "real time" rather  
>>> than
>>> the async email method used today
>>>
>>
>> A common complaint that I hear from people using OpenID to sign up  
>> for
>> new services comes down to an "OpenID tax": once they've successfully
>> authenticated with OpenID (which definitely isn't quite as fool proof
>> as I would hope), they're immediately asked to provide an email
>> address and then to validate it, receiving an out-of-band token. The
>> feedback I hear is that most people would rather just sign up with
>> their email address in the first place than have to deal with this
>> silly process.
>>
>> This will continue to be a valid criticism unless or until we are  
>> able
>> to make URL-based verified identifiers more useful than email
>> addresses to RPs.
>>
>>
>>
>>> I believe we need to keep these two use cases separate because the
>>> intentions/outcome is really quite different.
>>>
>>
>> For clarify of conversation, +1.
>>
>> Though solving both issues with one protocol/approach would be  
>> ultimately ideal.
>>
>> Chris
>>
>>
>>> SitG Admin wrote:
>>>
>>>>> I'd guess that a contributing factor here is that most OPs don't  
>>>>> support
>>>>> passing the email address via SREG.
>>>>>
>>>>>
>>>> Since the discussion here seems to be about not only verifying E- 
>>>> mail
>>>> addresses, but using them in place of a URI, does it matter  
>>>> whether a
>>>> RP supports *receiving* an E-mail address via SREG?
>>>>
>>>> I don't want users' E-mail. I don't *need* users' E-mail. I don't
>>>> care. Is the requirement (that a user be able to receive E-mail at
>>>> their address) going to require me to be able to send them E-mail  
>>>> so
>>>> I can confirm their OpenID?
>>>>
>>>> -Shade
>>>> _______________________________________________
>>>> general mailing list
>>>> general at openid.net
>>>> http://openid.net/mailman/listinfo/general
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>
>>
>>
>>
>
> -- 
> Chief Architect                   AIM:  gffletch
> Identity Services                 Work: george.fletcher at corp.aol.com
> AOL LLC                           Home: gffletch at aol.com
> Mobile: +1-703-462-3494
> Office: +1-703-265-2544           Blog: http:// 
> practicalid.blogspot.com
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general



More information about the general mailing list