Attribute Exchange 1.0 svn revision 295 review

Josh Hoyt josh at janrain.com
Thu Apr 5 23:48:20 UTC 2007


On Apr 5, 2007 at 8:41 AM, Dick Hardt <dick at sxip.com> wrote:
> > 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.

Generally, yes, although when we were discussing the spec, we talked
about using one pass of attribute exchange to get all of the available
attributes and another pass to request the attributes themselves. When
requesting the available attributes, it seems like you'd want to say
"give me all the attributes that are available" instead of "give me up
to 500 available attributes," but I could be wrong.

It might be good to give a bound on the response size for every
request, although in cases such as above, it might be useful to the
relying party to know if there were values that overflowed the limit.
It wouldn't be difficult to add a flag, but I'm also not sure whether
it would be worth the extra complexity.



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

Well, clearly it's better to have one way to do it. But seriously, the
main problem that I have with it is that the specification prescribes
the response format based on the request format. That is, my code has
to keep track of whether the request used count=1 or just didn't
specify a count, instead of just recording that the request asked for
one value, so that the later code can know how to encode the value. If
there's really more than one way to do it, you should be allowed to do
it either way.

I'm guessing that you made that restriction on the response format so
that relying parties can know what the form of the response will be.
Is that correct?


Another restriction on the response message is that you have to send
responses even if they are empty. Can you give the rationale for
requiring the fields with no values to be sent?


Josh



More information about the specs mailing list