OpenID Attribute Exchange 1.0 draft 4

[Johnny Bufu]

Hi Rowan,

On 31-Jan-07, at 1:26 PM, Rowan Kerr wrote:
> On 1/9/07, Johnny Bufu <johnny at sxip.com> wrote:
>> Please have a look at the latest (draft 4) OpenID Attribute Exchange
>> 1.0 specification:
>>
>> http://openid.net/specs/openid-attribute-exchange-1_0-04.html
>
> This is looking good. I've been going over it updating my drupal
> modules to draft 4.

Thanks for the feedback and for supporting AX!

> The multiple values request is nice, and I'm sure we'll find a use for
> it at Standard shortly as we get  a couple of our partners online with
> OpenID and AX. Of course, it's going to be a bit more difficult to get
> PHP behaving with the openid.type.<stuff>.1 but the limitations of one
> language shouldn't hold up the entire spec.

Ideally, this would be handled transparently by the libraries. Not  
sure what the php issues are, but  the JanRain guys said they would  
support AX in their libraries, so you could use theirs, or at least  
see how they handle this.

> One thing that seems to be missing at the moment is how to treat a
> collection of values.
> eg:  You fetch someone's name but want first, last, etc all together
> as one response.
>
> Maybe a ax.type.foo.join value would be useful?
> So then the discrete values of first and last name would be  
> returned by the OP
> joined with whatever was specified in ax.type.foo.join.

What use case are you trying to address? I'm trying to understand why  
you would prefer the join to be performed by the OP, rather than have  
the RP request the pieces it wants, and mix them together as it needs.


>> - Renamed openid.ax.fetch.<alias> to openid.ax.type.<alias>
>
> So now the only difference between a Fetch and Store is
> the existance of openid.ax.if_available and openid.ax.required
> and openid.ax.value...  I'm not sure if that makes the messages
> harder to deal with because it's more opaque, or if it's nicer
> because the messages are now more standard.

Yes, consistency among all types of messages was the reason for this  
change. But you're right, now they are quite similar. We've realized  
this is less convenient in some cases while implementing AX, and for  
the next draft we plan to add an ax.mode = fetch_request |  
fetch_response | store_request | store_response parameter to address  
this.


Thanks,
Johnny