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

Mon Oct 27 18:34:21 UTC 2008

Right. Using PAPE "as is" probably is a stretch.
For the third party asserted attribute exchange, what openid.ee is doing may
be interesting.

Also, something that Tatsuki is working on: third party signed attributes is
another way of doing it, I guess.

=nat

On Tue, Oct 28, 2008 at 3:04 AM, Paul Madsen <paulmadsen at rogers.com> wrote:

>  George, seems to me that the PAPE model for expressing that an email
> address be/is 'verified' is very different (and preferred) to explicitly
> labeling the attribute name.
>
> Stick the string 'verified' in front of an attribute name, and the
> implication is that it is somehow qualitatively different than a
> 'non-verified' attribute. And of course it (unless supplemented with
> something equivalent to PAPE) hides the detail as to how the verification
> occurred.
>
> FWIW, I don't think PAPE is actually the place for this sort of attribute
> assurance information ... but the model could be reused.
>
> paul
>
>
> George Fletcher wrote:
>
> I think the difference here is that the process that the RP desires is
> something like...
>
> 1. have the user enter their email address
> 2. determine that the domain owner of the email address supports "email
> verification"
> 3. use a pop-up window to direct the user to the domain owner's "email
> verification" endpoint
> 4. have the user prove "ownership" of the entered email address
> 5. return verified state to the RP
>
> I would also like to see either a PAPE policy or an AX attribute that
> signifies "verified email" where if the RP trusts the OP the user
> doesn't have to do any additional authentications.
>
> Thanks,
> George
>
> Nat wrote:
>
>
>  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> <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> <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 listgeneral at openid.nethttp://openid.net/mailman/listinfo/general
>
>
>
>              _______________________________________________
> general mailing listgeneral at openid.nethttp://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 listgeneral at openid.nethttp://openid.net/mailman/listinfo/general
>
>
> --
> [image: ConnectID] <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081028/eb71df0d/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 11322 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081028/eb71df0d/attachment-0002.gif>