[OpenID] About Facebook, MySpace and OpenID

John Bradley john.bradley at wingaa.com
Fri Apr 3 23:08:28 UTC 2009

In fairness google is interpreting required as required.

The issue is that they are treating optional as ignored to simplify  
the UX.

Any number of OPs allow you to customize persona, for Sreg and AX.

I have no problem with OPs targeting there services to different  

I suspect that PIP knows that there users are more sophisticated or at- 
least wanted an openID or they wouldn't have signed up.

Google on the other hand has to support people who have never been  
exposed to openID and just clicked on a button at Plaxo or someplace.

I am not saying that PIP and Google could or should have the same UX.

Only that RP's need a consistent response across all OPs for AX  
requests otherwise they have no reason to adopt it.

One of the areas where I don't currently have a AX test is for the  
behavior of an OP when it doesn't have a required attribute.

If we look at the spec:
Value: an attribute alias, or a list of aliases corresponding to the  
URIs defined by "openid.ax.type.<alias>" parameters. Multiple  
attribute aliases are separated with a comma, ",".

By requesting attributes using this field, a hint is sent to the OP  
about the RP's requirements for offering certain functionality and  
should be used by the OP to help the user decide what attributes to  
release. RP's requirements should not be enforced by the OP.

The RP should offer, out of band of attribute exchange, an alternate  
method of collecting the attributes it needs, if they weren't obtained  
via attribute exchange.

Value: an attribute alias, or a list of aliases corresponding to the  
URIs defined by "openid.ax.type.<alias>" parameters. Multiple  
attribute aliases are separated with a comma, ",".

Attributes requested using this field are deemed optional by the RP;  
the RP should be able to complete the interaction with the user even  
if values are not provided by the OP for the optional attributes.


It is clear that the RP can expect to get a response back and continue  
the transaction if the OP doesn't provide the value.

On the other hand the language for required was written by a  
politician.  A hint that the RP may not provide certain functionality  
without the value.

Is certain functionality declining the login or making the user  
manually input a email to verify?

I can read Googles interpretation  into the above spec however that is  
clearly not how others interpret it.

If I were to read the spec on its own as an OP I would probably come  
to the conclusion that what I need is an interface that shows the RP  
has requested:
1. A set of information that is purely optional and they will provide  
service even if the information is not provided.
2. A set of information that the RP may restrict or deny service if I  
don't provide.

I let the user select or deselect any of there available attributes  
and send back a positive response unless the user decides to cancel  
the login.
This includes not sending back required attributes.

The RP is guaranteed to get a response and needs to figure out what to  
do with the user as a result of that.

I don't think anyone is exactly following my reading mostly because  
they are looking at the name openid.ax.required and not the normative  

Until there is a  consensus around the user level flow for AX it is  
hard for me to crate more detailed tests or even determine success of  
failure of anything above the protocol layer.

John Bradley
On 3-Apr-09, at 3:01 PM, Deron Meranda wrote:

> On Fri, Apr 3, 2009 at 3:50 PM, John Bradley  
> <john.bradley at wingaa.com> wrote:
>> I will grant you that the choice google has made to deny returning  
>> optional
>> claims to the RP without a user dialog makes the UI simpler.
>> The problem for RPs is that they may still be willing to accept the  
>> login
>> without the email and collect or verify the email in some other  
>> manner.
> Yes, this is exactly the "problem" I have with Google's way of  
> interpreting
> optional to mean required.  It's not optional for the user, it's  
> optional
> for Google.
> Another slight annoyance, perhaps specific to Google, is that even  
> if I have
> it return an email address, I don't get to pick it.
> Basically, any Google account can have a lot of different email  
> addresses.
> First, you can just add or remove periods (dots) where-ever
>   http://mail.google.com/support/bin/answer.py?hl=en&answer=10313#
> or you can also make up address aliases
>  http://mail.google.com/support/bin/answer.py?answer=12096&topic=13271
> I may want to give out my primary address for my bank's blog,
> but a different one for my neighbor's.
>> From a RP point of view OP's dealing with AX requests in a  
>> consistent way is
>> a requirement.
> Agree.
> Some OPs like Verisign PIP let me customize my attribute return
> values (albeit SREG rather than AX) almost to the extreme opposite of
> Google: per-RP answers, multiple AX profiles for default answers, etc.
> -- 
> Deron Meranda

More information about the general mailing list