[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