Re: OpenID Attribute Exchange 1.0 draft 4
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..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. to openid.ax.type. > > 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
Re: OpenID Attribute Exchange 1.0 draft 4
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. 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..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. to openid.ax.type. 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:[EMAIL PROTECTED] http://standardinteractive.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Attribute Exchange 1.0 draft 4
Hello list! 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 Summary: OpenID Attribute Exchange is an OpenID service extension for exchanging identity information between endpoints. Messages for retrieval and storage of identity information are provided. The main change since draft 3 is the specification for exchanging attributes with multiple values, by having a "count" parameter and incremental parameter names for each value. Other minor changes to clarify some aspects include: - Added note about the state of flux of the attribute types and metadata specifications - Added definition for 'attribute' - Explicitly referenced OpenID's extension mechanism as the transport for attribute exchanges - Renamed openid.ax.fetch. to openid.ax.type. - Added reference to OpenID Authentication's security considerations We look forward to any feedback and comments from the community towards improving the attribute exchange! Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
