RE: review of draft-wierenga-ietf-sasl-saml-00

["Scott Cantor" <[e-mail]>]

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

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.

-- Scott