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

["Scott Cantor" <cantor.2@osu.edu>]

> Comments:
> 
> - I think this is more a "profile" than a "protocol".  Section 2.1
> seems to support that contention.  Does it make more sense to call
> this the "Identity Provider Discovery Service Profile"?

I think it's both. It's definitely a new protocol, there's no such message
exchange anywhere now. It's a profile in the sense that we use that to
define the unit of standardization for just about everything, plus there's a
specific constraint in this proposal to leave it at single IdP determination
without precluding others.

With infinite time, I'd restructure the thing around that division, but the
benefits of this thing are not large enough to justify such an investment
for me right this second.

> - 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. I do
have a diagram from Rod, it's on a list to add.

> - What happens if the 'return' URL already has a query string
> parameter named 'entityID' (or the value of 'returnIDParam', if
> present)?

SP Deployer <- moron

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

> - 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 could create an example that's explicit, meaning a
WS-Federation example. I didn't for the usual political reasons, but I
could.

This is a metaprotocol, by which I mean the request is what determines the
format of the response, so that in theory many alternate discovery protocols
can be spoofed with it as long as you can send a suitable request. This has
been verified, for example, with the discovery protocol in WS-Fed 1.1. A
WS-Fed RP wouldn't produce such a request but a link on a page could result
in this DS responding to a WS-Fed RP in the manner it expects.

> - There is no mention of metadata in section 2.4.3.  If the DS uses
> metadata to authorize an SP, the instructions in section 2.4.3
> (especially lines 198--200) need to be modified.

I will move part of the text in 2.5 into that section.

> - 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 or returning nothing is acceptable and
shouldn't be prescribed here. Returning nothing is required in the passive
case, but otherwise it's got to depend on the deployment what to do.

-- Scott