Hi Rowan, On 31-Jan-07, at 1:26 PM, Rowan Kerr wrote: > On 1/9/07, Johnny Bufu <[EMAIL PROTECTED]> 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 _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
