Re: [security-services] Groups -draft-sstc-saml-idp-discovery-02.pdf uploaded

[Greg Whitehead <greg.whitehead@hp.com>]

See below.


On 2/23/07 4:13 PM, "Tom Scavo" <trscavo@gmail.com> wrote:

> On 2/23/07, Scott Cantor <cantor.2@osu.edu> wrote:
>> 
>>> - Early in section 2, can you list the steps in one place, at the
>>> beginning?  Also, can you include a flow diagram that shows how the
>>> Discovery Service fits into the larger Web SSO Profile?
>> 
>> I didn't think it was long enough to need a separate stepwise intro.
> 
> Well, it might just be me, but I think you need to provide some
> context for the details discussed in the subsequent subsections.
> 
>>> In other words, shouldn't the query string parameter on the
>>> 'return' URL be suitably restricted to prevent parameter name clashes?
>>>  What should the DS do if such a collision occurs?
>> 
>> I don't think it's justified to make a DS check for it. I guess I should
>> just say "MUST NOT include..." then.
> 
> I think you have a minor problem here.  The DS needs to check for this
> edge case and take evasive action if there's a name clash.
> 
> Note that multiple HTTP parameter instances leads to unspecified
> behavior.  Server-side web languages handle multi-valued parameters
> differently.

I think you can put the burden on the requester with "MUST NOT" language on
the request. The DS can check if it wants to be nice, but its ultimately the
requester that will barf on the response (for reasons that will be traced
back to their own violation of the spec).

>>> - The purpose of the 'returnIDParam' parameter is confusing at first.
>>> Can the brief explanation on lines 175--176 be clarified?  (Sorry, I
>>> don't have anything to offer at this point.)
>> 
>> Maybe it would help me if you explained what you thought it was for before
>> you understood it?
> 
> I checked my notes, and my initial reaction was "huh?"  It was only
> 'til I got to section 2.4.3 that I understood the intent of that
> parameter.
> 
>>> - In section 2.5, what happens if the DS is unable to match the value
>>> of the 'return' parameter with a location in metadata?
>> 
>> I think either reporting the error
> 
> Error?  There is no error protocol as far as I can see.
> 
>> or returning nothing is acceptable and
>> shouldn't be prescribed here.
> 
> I don't follow.  Seems the spec should explicitly tell the DS what to
> do in this case.
> 
>> Returning nothing is required in the passive
>> case, but otherwise it's got to depend on the deployment what to do.
> 
> I missed that.  Where does it say that returning nothing is the
> prescribed thing to do?
> 
> Tom