 |
 |
On 5/25/10 10:46 PM, Scott Cantor wrote: Scott, >> A mechanism similar to this could provide significantly better security >> guarantees if the client knew its own IDP URI. > ... >> I think that if these two additions can be fleshed out and if there are >> significant use cases where clients could know their IDP, then the >> mechanism should be modified to support these use cases. > > That is in essence the reason I am still planning to propose an alternative > design that makes direct use of the SAML profile that was designed for this > basic scenario of a client that's been modified. It does not impose > significant technical barriers to clients (they don't have to know much > about SAML or create XML Signatures or any of the other common complaints). I am assuming you refer to the ECP profile. How different would this be from the SASL point of view? I.e. what difference would it make on the "SASL wire"? > > I believe the cost of deploying a client is such that it's absolutely > essential to use that change to move discovery to it. > > I was hoping to have an I-D submitted by now, but I haven't found the time. > Hopefully fairly soon. > >> However, as I mentioned, I don't know how to do better than the current >> mechanism given the common requirement that the server provide an IDP >> discovery URI. I do understand that requirement is important. > > I haven't seen a compelling argument for why it's important. It's actually > been a problem for federation since its inception, and when you can avoid > it, you really have to. There is no compelling argument other than that this is the way it is done in most identity federations today and I wanted to stay as close as possible to today's implementations and not fall into the trap of trying to introduce something new and at the same time try to fix all other problems in the world. > It's something you can work around in cases in which the application relies > on identifiers that resemble email addresses and can be used to perform an > implicit kind of discovery, but that's not a generalized case, and it still > results in the additional security issues you mentioned. Agreed. Klaas