[OpenID] [SPAM]Re: [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Combining Google & Yahoo user experience research
George Fletcher
gffletch at aol.com
Mon Oct 27 19:28:38 UTC 2008
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?
Thanks,
George
Paul Madsen wrote:
> Who said anything about XML? I merely suggested not overloading the
> attribute name with some binary assessment of assurance.
>
> 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?
>
> Will VerifiedShippingAddress be next?
>
>
> Peter Williams wrote:
>> 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)?
>>
>> If the conforming processor treats one prefix as another, semantically, there is none. All one needs the unambiguous syntax.
>>
>> 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.
>>
>> 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....
>>
>>
>> ________________________________
>> From: Paul Madsen <paulmadsen at rogers.com>
>> Sent: Monday, October 27, 2008 2:10 PM
>> To: George Fletcher <gffletch at aol.com>
>> Cc: general at openid.net <general at openid.net>
>> Subject: [SPAM]Re: [OpenID] [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Combining Google & Yahoo user experience research
>>
>> 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><mailto: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><mailto: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<mailto:general at openid.net>
>> http://openid.net/mailman/listinfo/general
>>
>>
>>
>>
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net<mailto:general at openid.net>
>> http://openid.net/mailman/listinfo/general
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Chief Architect AIM: gffletch
>> Identity Services Work: george.fletcher at corp.aol.com<mailto:george.fletcher at corp.aol.com>
>> AOL LLC Home: gffletch at aol.com<mailto: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<mailto:general at openid.net>
>> http://openid.net/mailman/listinfo/general
>>
>>
>>
>>
>>
>> --
>> [cid:part1.01040502.00040806 at rogers.com]<http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
>>
>>
>> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG.
>> Version: 7.5.549 / Virus Database: 270.8.3/1747 - Release Date: 26/10/2008 9:27 AM
>>
>
> --
> ConnectID <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
--
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
More information about the general
mailing list