OpenID Attribute Exchange 1.0 draft 4

Rowan Kerr rowan at standardinteractive.com
Wed Jan 31 21:26:21 UTC 2007


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.

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.

Surely other people are intersted in using AX? Without that, I know I
wouldn't have been implementing OpenID 2.. it would be nice to get
some more dialog going about it.

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.


> - Added note about the state of flux of the attribute types and
> metadata specifications

Some sort of openid community standard for a base set of Metadata
would be really helpful. Sure, Standard can go and publish our
own spec that our partners know about but it will be of limited use
when they would like to perform AX with a different OP.

(If it'll be too arduous to acheive concensus at a community
level, perhaps the "equivalency" protocol I've seen mentioned
somewhere could be fleshed out and become the preferred
method of supporting attributes across moultiple OP's).

Who else on-list wants to be able to use a well-defined
set of attributes? Speak up :)


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

I suppose the main OpenID specs already rely on the
absence of values rather than the presence or naming
of, so maybe it's more in keeping with the general protocol.

-Rowan


-- 
Rowan Kerr
Senior Web Programmer, Standard Interactive
tel:+14169344451
xmpp:rowan at standardinteractive.com
http://standardinteractive.com/



More information about the specs mailing list