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

Paul Madsen paulmadsen at rogers.com
Mon Oct 27 19:41:53 UTC 2008


Hi George, I'm not sure where the card folks are on this issue.

I did find a post of Mike's at http://self-issued.info/?p=9, 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.

paul


George Fletcher wrote:
> 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>
>

-- 
ConnectID <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081027/612ec1e4/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gMwy.1.gif
Type: image/gif
Size: 11322 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081027/612ec1e4/attachment-0002.gif>


More information about the general mailing list