Attribute Exchange 1.0 svn revision 295 review

[Josh Hoyt]

List,

I sat down with a couple other JanRain engineers and we took a look at
the Attribute Exchange draft and recorded some issues that we have.
There are probably other smaller issues, but this is what we came up
with in a quick (?) review.

Is editing of this spec by authors of other OpenID specifications
welcome? (I hope that by this review and my past spec work I'm showing
that I have adequate understanding and appropriate goals.)

Josh

Attribute Exchange specification v1.0 svn revision 295 review
***************************************************************

Update URL issues
=================

I assume that the update_url is intended to match the realm of the
authentication request. The spec doesn't say this anywhere.

There is no information about what form an update request will take,
or what a response to an update request will look like. Is an update
request supposed to be an OpenID authentication mode=id_res message?
If so, I think this is at least a little confusing, since the
user-agent of this HTTP transaction is not the user's browser, but the
provider's.

There doesn't seem to be a way to expire an update URL or unsubscribe
from updates.

There is no discussion of how an OpenID provider should behave if an
update URL does not respond (retry? stop using that URL? some of
each?)

Store Requests
==============

The realm in a store request is somewhat meaningless; The provider has
no way of knowing whether the data came from something that's in that
realm, even if a return_to URL is provided.

What will happen to the data when a store is requested is not
discussed (will it replace the current value? will it get
concatenated? Does it depend on the attribute? If it's left up to the
provider, how will an RP know when it should initiate a store?)

Multiple Values
===============

There is no way to say "I want as many of X as you have, and I don't
care how many that is"

There is the issue that I brought up in a separate message where
count=1 is different from not specifying a count, even though they
both mean 1 or 0 values.

The spec wording is unclear on what the count response parameter
should be. The example shows sending back a different count, which
suggests that the response count can be less than the request count,
but that should be explicit.

Could we do away with unspecified count in the interests of simpler
code everywhere? That way, we always know there's a count and the data
is always accessed in the same way.

It's not clear from the specification whether zero-length strings as
values for things with a count should be treated the same as they are
for things without a count.