<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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.<br>
<br>
FWIW, I don't think PAPE is actually the place for this sort of
attribute assurance information ... but the model could be reused.<br>
<br>
paul<br>
<br>
George Fletcher wrote:
<blockquote cite="mid:4905BA9D.8080705@aol.com" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">Perhaps you can construct a PAPE policy that signifies the verified
email and send the email by SREG.
=nat@TOKYO via iPhone
On 2008/10/27, at 21:21, George Fletcher <a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><gffletch@aol.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">On Sat, Oct 25, 2008 at 3:03 AM, George Fletcher <a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><gffletch@aol.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">I believe we need to keep these two use cases separate because the
intentions/outcome is really quite different.
</pre>
</blockquote>
<pre wrap="">For clarify of conversation, +1.
Though solving both issues with one protocol/approach would be
ultimately ideal.
Chris
</pre>
<blockquote type="cite">
<pre wrap="">SitG Admin wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I'd guess that a contributing factor here is that most OPs don't
support
passing the email address via SREG.
</pre>
</blockquote>
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">--
Chief Architect AIM: gffletch
Identity Services Work: <a class="moz-txt-link-abbreviated" href="mailto:george.fletcher@corp.aol.com">george.fletcher@corp.aol.com</a>
AOL LLC Home: <a class="moz-txt-link-abbreviated" href="mailto:gffletch@aol.com">gffletch@aol.com</a>
Mobile: +1-703-462-3494
Office: +1-703-265-2544 Blog: <a class="moz-txt-link-freetext" href="http://practicalid.blogspot.com">http://practicalid.blogspot.com</a>
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1"><img
src="cid:part1.01040502.00040806@rogers.com" alt="ConnectID"
style="border: 0pt none ;"></a></div>
</body>
</html>