Yahoo available AX attrs

Peter Watkins peterw at tux.org
Tue Dec 8 04:24:23 UTC 2009


On Mon, Dec 07, 2009 at 07:45:49PM -0800, Allen Tom wrote:

> 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)

I see. Not a problem for us -- we only accept https for OpenID (which is
the main reason we only have buttons for Yahoo and Google), and our RP app
runs on https. Drives me crazy dealing with sites like Twitter and Facebook
that ask users to enter username+password on plain http:// pages. :-)

> 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.

Ah, good point. My plan has been to assume any email address provided by 
certain OPs (for now Yahoo and Google) was already verified. I guess we 
can do that right now for Yahoo since you can guarantee the @yahoo.com are
legitimate.

Thanks,

Peter

> 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


More information about the specs mailing list