<!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">
Hi George, I'm not sure where the card folks are on this issue. <br>
<br>
I did find a post of Mike's at <a class="moz-txt-link-freetext" href="http://self-issued.info/?p=9">http://self-issued.info/?p=9</a>, which
seems to propose a hybrid solution, ie have the RP ask for an attribute
explicitly labelled as 'verified' , but have the STS provide back the
extra information as an additional data structure appended to the bare
attribute name/value pair.<br>
<br>
paul<br>
<br>
<br>
George Fletcher wrote:
<blockquote cite="mid:49061666.7050902@aol.com" type="cite">So if I
make the comparison to InfoCards... if I get an assertion from a
managed card... is there any way to tell whether email "claim" value is
actually "verified" by the managed card STS vs just self-asserted by
the user to the managed STS?
<br>
<br>
Thanks,
<br>
George
<br>
<br>
Paul Madsen wrote:
<br>
<blockquote type="cite">Who said anything about XML? I merely
suggested not overloading the attribute name with some binary
assessment of assurance.
<br>
<br>
Does OpenID authentication have the RP ask for an identifier explicitly
labelled as 'verified'? Or does it ask for an identifier, with the
specifics of the mechanism by which the OP is to verify ownership
deferred to PAPE?
<br>
<br>
Will VerifiedShippingAddress be next?
<br>
<br>
<br>
Peter Williams wrote:
<br>
<blockquote type="cite">Sticking the string verified in front of a
attrvalue, vs sticking some xml nested "confirmation" tagging in
front...of the same attr value. What's the difference (excepting type
theory and security engineering methods)?
<br>
<br>
If the conforming processor treats one prefix as another, semantically,
there is none. All one needs the unambiguous syntax.
<br>
<br>
Simplistic prefixes feel more like openid culture. Don't want to make
openid turn into saml, though semantic convergence would be nice,
particularly for gatewaying.
<br>
<br>
Not sure how much convergence there really is yet within the saml
community itself, tho, the more I look into it, even over basics like
metadata and key management. jar hell seems to have evolved into
profile hell....
<br>
<br>
<br>
________________________________
<br>
From: Paul Madsen <a class="moz-txt-link-rfc2396E" href="mailto:paulmadsen@rogers.com"><paulmadsen@rogers.com></a>
<br>
Sent: Monday, October 27, 2008 2:10 PM
<br>
To: George Fletcher <a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><gffletch@aol.com></a>
<br>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a> <a class="moz-txt-link-rfc2396E" href="mailto:general@openid.net"><general@openid.net></a>
<br>
Subject: [SPAM]Re: [OpenID] [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Combining
Google & Yahoo user experience research
<br>
<br>
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:
<br>
<br>
I think the difference here is that the process that the RP desires is
<br>
something like...
<br>
<br>
1. have the user enter their email address
<br>
2. determine that the domain owner of the email address supports "email
<br>
verification"
<br>
3. use a pop-up window to direct the user to the domain owner's "email
<br>
verification" endpoint
<br>
4. have the user prove "ownership" of the entered email address
<br>
5. return verified state to the RP
<br>
<br>
I would also like to see either a PAPE policy or an AX attribute that
<br>
signifies "verified email" where if the RP trusts the OP the user
<br>
doesn't have to do any additional authentications.
<br>
<br>
Thanks,
<br>
George
<br>
<br>
Nat wrote:
<br>
<br>
<br>
Perhaps you can construct a PAPE policy that signifies the verified
<br>
email and send the email by SREG.
<br>
<br>
=nat@TOKYO via iPhone
<br>
<br>
On 2008/10/27, at 21:21, George Fletcher
<a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><gffletch@aol.com></a><a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><mailto:gffletch@aol.com></a> wrote:
<br>
<br>
<br>
<br>
In the discussions I've had, there was one other use case. That is a
<br>
site that isn't ready yet to support the full OpenID cross-domain SSO
<br>
concept, yet wants to streamline their registration process such that
<br>
they don't have to use the out-of-band email verification mechanism.
In
<br>
this case, a small extension to the OpenID protocol (similar in concept
<br>
to AX) could be constructed that would allow a user to verify their
<br>
ownership over the email address using a "synchronous" process vs the
<br>
current async one. So, if the RP's only concern is to verify that the
<br>
user "owns" the email address they've specified, then the RP doesn't
<br>
want the email address mapped to an OpenID, they want to know that the
<br>
email address is valid and the user knows the password to it.
<br>
<br>
This use case isn't really related to OpenID other than it's possible
to
<br>
use the current flow and protocol (with a small extension) to implement
<br>
it. If AX is about exchanging attributes, this would be an extension to
<br>
"verify" attributes:)
<br>
<br>
Thanks,
<br>
George
<br>
<br>
Chris Messina wrote:
<br>
<br>
<br>
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><a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><mailto:gffletch@aol.com></a>
<br>
wrote:
<br>
<br>
<br>
<br>
I think there are at least two use cases involving email addresses
<br>
that
<br>
can be easily confused...
<br>
<br>
1. Use the email address as an indicator or pointer to a valid
<br>
OpenID as
<br>
the email address is an identifier that the user currently remembers.
<br>
- this is the use case that EAUT is targeting and, if I understood
<br>
correctly, what Chris is discussing as well
<br>
<br>
<br>
<br>
Yes. The point is, until MySpace users become familiar with using
<br>
their "MySpace OpenID" or "OpenID" (depending on how we recommend
<br>
MySpace market this behavior), we have ample reason to make it
<br>
possible for people to use identifiers with which they're already
<br>
familiar and use in common practice to sign in to web services:
<br>
namely, email addresses.
<br>
<br>
It also would provide a means to "upgrade" legacy accounts keyed to
<br>
email addresses to use remote authentication via OpenID... reducing
<br>
the need to remember discreet passwords (or sharing a unique password
<br>
between sites).
<br>
<br>
Although there will be increasing numbers of URL-formatted/based
<br>
identifiers out there for people to use for OpenID authentication, it
<br>
seems that a great way to simplify OpenID's offering and to make it
<br>
more palatable to those who argue that they identify themselves by an
<br>
email address is indeed to figure out the best way to enable that
<br>
possibility, and to disarm that argument.
<br>
<br>
<br>
<br>
<br>
2. Verify an email address for those RP's that want/need/require a
<br>
"verified email address"
<br>
- this is more about the RP getting a verified identity attribute
<br>
- the expectation is that an OpenID based flow would allow a user who
<br>
has to verify their email address to do it in "real time" rather than
<br>
the async email method used today
<br>
<br>
<br>
<br>
A common complaint that I hear from people using OpenID to sign up for
<br>
new services comes down to an "OpenID tax": once they've successfully
<br>
authenticated with OpenID (which definitely isn't quite as fool proof
<br>
as I would hope), they're immediately asked to provide an email
<br>
address and then to validate it, receiving an out-of-band token. The
<br>
feedback I hear is that most people would rather just sign up with
<br>
their email address in the first place than have to deal with this
<br>
silly process.
<br>
<br>
This will continue to be a valid criticism unless or until we are able
<br>
to make URL-based verified identifiers more useful than email
<br>
addresses to RPs.
<br>
<br>
<br>
<br>
<br>
<br>
I believe we need to keep these two use cases separate because the
<br>
intentions/outcome is really quite different.
<br>
<br>
<br>
<br>
For clarify of conversation, +1.
<br>
<br>
Though solving both issues with one protocol/approach would be
<br>
ultimately ideal.
<br>
<br>
Chris
<br>
<br>
<br>
<br>
<br>
SitG Admin wrote:
<br>
<br>
<br>
<br>
I'd guess that a contributing factor here is that most OPs don't
<br>
support
<br>
passing the email address via SREG.
<br>
<br>
<br>
<br>
<br>
Since the discussion here seems to be about not only verifying E-mail
<br>
addresses, but using them in place of a URI, does it matter whether a
<br>
RP supports *receiving* an E-mail address via SREG?
<br>
<br>
I don't want users' E-mail. I don't *need* users' E-mail. I don't
<br>
care. Is the requirement (that a user be able to receive E-mail at
<br>
their address) going to require me to be able to send them E-mail so
<br>
I can confirm their OpenID?
<br>
<br>
-Shade
<br>
_______________________________________________
<br>
general mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a><a class="moz-txt-link-rfc2396E" href="mailto:general@openid.net"><mailto:general@openid.net></a>
<br>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
general mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a><a class="moz-txt-link-rfc2396E" href="mailto:general@openid.net"><mailto:general@openid.net></a>
<br>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--
<br>
Chief Architect AIM: gffletch
<br>
Identity Services Work:
<a class="moz-txt-link-abbreviated" href="mailto:george.fletcher@corp.aol.com">george.fletcher@corp.aol.com</a><a class="moz-txt-link-rfc2396E" href="mailto:george.fletcher@corp.aol.com"><mailto:george.fletcher@corp.aol.com></a>
<br>
AOL LLC Home:
<a class="moz-txt-link-abbreviated" href="mailto:gffletch@aol.com">gffletch@aol.com</a><a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><mailto:gffletch@aol.com></a>
<br>
Mobile: +1-703-462-3494
<br>
Office: +1-703-265-2544 Blog: <a class="moz-txt-link-freetext" href="http://practicalid.blogspot.com">http://practicalid.blogspot.com</a>
<br>
<br>
_______________________________________________
<br>
general mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a><a class="moz-txt-link-rfc2396E" href="mailto:general@openid.net"><mailto:general@openid.net></a>
<br>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
<br>
<br>
<br>
<br>
<br>
<br>
--
<br>
[<a class="moz-txt-link-freetext" href="cid:part1.01040502.00040806@rogers.com">cid:part1.01040502.00040806@rogers.com</a>]<a class="moz-txt-link-rfc2396E" href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1"><http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1></a>
<br>
<br>
------------------------------------------------------------------------
<br>
<br>
No virus found in this incoming message.
<br>
Checked by AVG. Version: 7.5.549 / Virus Database: 270.8.3/1747 -
Release Date: 26/10/2008 9:27 AM
<br>
</blockquote>
<br>
-- <br>
ConnectID <a class="moz-txt-link-rfc2396E" href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1"><http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1></a>
<br>
</blockquote>
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1"><img
src="cid:part1.09070403.06040606@rogers.com" alt="ConnectID"
style="border: 0pt none ;"></a></div>
</body>
</html>