Attribute Exchange 1.0 svn revision 295 review

[Dick Hardt]

On 4-Apr-07, at 2:07 PM, Josh Hoyt wrote:
> 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.)

Yes!

Great feedback below

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

Good addition.

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

The intention was that it was in the same format as the original  
message. Do you have another suggestion?

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

Another good point.

Returning a 404 would be one way to expire the URL.

>
> 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?)

That would seem to be implementation dependent as the OP is acting on  
behalf of the user, but agreed the spec should at least have a  
recommendation.

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

The realm would be a hint
>
> 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?)

It is up to the OP to manage the attributes and deal with multiple  
values since this is the user's data. Not all that different from  
what an RP does when it gets data.

An RP would initiate a store if it thinks the data will be useful to  
other RPs.

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

Good point. Perhaps have  a magic value like -1 to indicate as many  
as the user will release?
I had thought the RP would likely have a maximum they would want in  
most situations.

>
> 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 perl way would be to have "more then one way to do it" and allow  
both methods to mean the same thing.

The python way would be "there is one way to do it" and not allow  
count=1 in a request

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

good point

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

Are you suggesting we always send the count?
Most requests we have done only are requesting a single value, so  
that seems like lots of overhead.
Agree having one way to do it has its advantages, you are showing  
your Python roots. :-)

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

Agree is is not clear.

I would suggest zero-length is the value that is returned.
If no value is to be returned, then nothing is sent.

-- Dick