[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Groups - draft-sstc-saml-idp-discovery-02.pdf uploaded
> > 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. If the spec is modified to say you MUST NOT send one, I don't think that leaves any holes. > Note that multiple HTTP parameter instances leads to unspecified > behavior. Server-side web languages handle multi-valued parameters > differently. Violating a MUST NOT is unspecified by definition. That's better than making the DS have to check for stupid messages unless it really wants to. Nothing to stop it of course. > 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. Ok, that helps. > > > - 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. To the user, I mean. <HTML> <BODY>OOPS</BODY> </HTML> > I don't follow. Seems the spec should explicitly tell the DS what to > do in this case. I think some people will want it to report the problem to the user and some people will want it to return nothing and send back control. Depends on the deployment. If we had to force one or the other, then obviously the one to force is to return nothing, but I don't think it's really necessary except in the passive case where you can't display an error. > > 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? It doesn't yet, the metadata stuff was kind of tacked on late and needs some clarifications like this one. I'm just saying that only in the passive case can you say clearly that under no circumstances should the thing display an error. In that situation, you have no choice, but in other cases all that matters is that you don't return a value. Beyond that, it depends what you want the UI to look like. As a spec matter, it would say MAY do X or Y, which means that an SP of course has to prepare for getting back nothing as in passive. But it has to expect that option anyway (I mean, there simply may be no IdP for the user to pick), so that's not a new requirement on an SP. If that's not clear, I suggest we discuss on next week's call rather than talk past each other. I may not have time to do a new draft by then anyway. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]