Yahoo available AX attrs

Joseph A Holsten joseph at josephholsten.com
Tue Dec 8 09:57:21 UTC 2009


I understand the desire to say that the email is verified, but it  
strikes me as a bit like the urgent priority field in email. "No email  
provided" vs "This is the user's email" vs "This is Really the User's  
Email and I Mean It". Unless it means "This is the user's email, I've  
done due diligence, and you can hold me legally liable." Everything  
else boils down to understanding what the OP means when they make an  
assertion.

If you really want a verified flag/timestamp/zero-knowledge-proof,  
perhaps you have a better idea about the interaction flow when things  
aren't verified to 100% certainty. Would the OP require the user to  
verify their email before allowing them to authenticate? Leave it up  
to the RP to verify? What if the OP says they're certain but the RP  
doesn't actually trust them? What happens when the OP says they've  
verified, but not 100% certain? Do you expect different RPs to make  
different decisions in these circumstances? How would they choose?

I'm assuming we're not talking about RPs that have a significant  
legal / medical / financial interest in accurate assertions, because  
that's legal liability / consent / know your customer and you'll need  
more than a timestamp+i-mean-it for that.
--
j

On Dec 7, 2009, at 10:36 PM, Allen Tom wrote:

> I’d recommend using a timestamp indicating when it was last  
> verified, with a special value to indicate that the OP is also the  
> email provider and has 100% certainty. (perhaps just setting the  
> verification time==now is sufficient)
>
> Allen
>
>
> On 12/7/09 8:29 PM, "Chris Messina" <chris.messina at gmail.com> wrote:
>
>> Sounds like something to add to PoCo... perhaps something as simple  
>> as a "verified" boolean added to email addresses?
>>
>> http://portablecontacts.net/draft-schema.html#anchor4
>>
>> Chris
>>
>> On Mon, Dec 7, 2009 at 8:25 PM, Brian Kissel <bkissel at janrain.com>  
>> wrote:
>>> +1 on email address metadata, many RPs definitely want this.
>>>
>>> Cheers,
>>>
>>> Brian
>>> ___________
>>>
>>> Brian Kissel
>>> CEO, JanRain - WebID and Social Publishing for User Engagement
>>> Email: bkissel at janrain.com     Cell: 503.866.4424     Fax:  
>>> 503.296.5502
>>>
>>>
>>> -----Original Message-----
>>> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-bounces at lists.openid.net 
>>> ] On Behalf Of Allen Tom
>>> Sent: Monday, December 07, 2009 7:46 PM
>>> To: Peter Watkins; Chris Obdam; openid-specs at lists.openid.net
>>> Subject: Re: Yahoo available AX attrs
>>>
>>> Oops - I clicked send too early.
>>>
>>> The bad UX with AX is the security warning that most browsers  
>>> display when
>>> POSTing a form from HTTPS to HTTP, which is the case when the  
>>> Yahoo OP
>>> returns a lot of attributes. AX attribute names are excessively  
>>> long, so
>>> it's very likely that using different attribute names for first/ 
>>> last/middle
>>> name will cause the response to be returned via POST. (2KB is the  
>>> cutoff
>>> point)
>>>
>>> With regards to email address - unless we're 100% sure about the  
>>> email
>>> address, we'd like to return metadata about the email address.  
>>> Specifically,
>>> we'd like to indicate whether or not the email address was  
>>> verified, and if
>>> so, when it was verified. This is definitely something that we'd  
>>> like to get
>>> in to AX 2.0.
>>>
>>> Allen
>>>
>>>
>>>
>>> On 12/7/09 7:39 PM, "Allen Tom" <atom at yahoo-inc.com> wrote:
>>>
>>> > It definitely makes sense to use different attributes for  
>>> givennanme/surname
>>> > so that RPs don't have to parse the string, and a few other RPs  
>>> have also
>>> > asked for it.  Our initial goal for our AX implementation was  
>>> just to match
>>> > SREG, and SREG only has a single openid.sreg.fullname attribute.
>>> >
>>> > We'll add support for separate first/last/middle/suffix  
>>> attributes in a
>>> > followup release - probably early next year. I do hope that  
>>> we're able to
>>> > standardize the attribute names, and also keep them short and  
>>> compact. If you
>>> > ask for all our supported attributes, the response will exceed  
>>> 2KB, which
>>> > requires that the response is returned via POST, causing a  
>>> really bad UX.
>>> >
>>> > With regards to email address - we'd like to be able to return  
>>> metadata about
>>> > the email address w
>>> >
>>> >
>>> >
>>> > On 12/7/09 7:25 AM, "Peter Watkins" <peterw at tux.org> wrote:
>>> >
>>> >> On Mon, Dec 07, 2009 at 09:16:46AM +0100, Chris Obdam wrote:
>>> >>>> Chris (Obdam)  - which additional attributes would you like  
>>> to see
>>> >>>> available? The attributes that we’ll be adding early next  
>>> year will include
>>> >>>> Yahoo Profile URL and account creation date. A bunch of  
>>> people have asked
>>> >>>> for Flickr Photos URL and Upcoming Profile URL, so we’ll  
>>> probably get
>>> >>>> around
>>> >>>> to adding those too.
>>> >>> I would like to access every attr specified in de AXschema? :-)
>>> >>>
>>> >>> In my Yahoo profile i have provided my address (home and  
>>> work). I would like
>>> >>> to use those in a sign form somewhere else.
>>> >>> Same goes for my phone numbers.
>>> >>
>>> >> So would I. One of the simpler goals of our Single Sign On is  
>>> prepopulating
>>> >> form fields; having postal address and phone number would be a  
>>> help.
>>> >>
>>> >> I'd also like to see First and Last names available as separate  
>>> attributes,
>>> >> otherwise we're trying to intelligently split both "Mary Jane  
>>> Parker" and
>>> >> "Malcom Mac Murray".
>>> >>
>>> >> Also I would prefer that you give us the user's *primary* email  
>>> address. In
>>> >> my Yahoo profile, my Yahoo email address is flagged as "Share  
>>> with no one"
>>> >> and I have a different email address flagged as primary, but  
>>> your AX sends
>>> >> my yahoo email address. That's bad from usability in part  
>>> because I very,
>>> >> very seldom check my Yahoo email inbox.
>>> >>
>>> >> The Yahoo website attribute would also be nice to have; as we  
>>> start
>>> >> building more "social" features on our sites, it would be nice  
>>> to make
>>> >> it easier for our users to share links to their primary web  
>>> presences,
>>> >> although I can understand if Yahoo management prefers to only  
>>> expose the
>>> >> Profile URL for business reasons.
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Peter
>>> >>
>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs



More information about the specs mailing list