> 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"?

Significantly different from yours, since there's no empty response and no
callback communication between the SP and the IdP, but I believe it can be
compatible with SAML ECP on the IdP side, and is essentially a direct
mapping from using HTTP as a "container" for the SP/client SOAP envelopes to
using the SASL messages.

It suffers the same MITM issues that Sam mentioned, since that's what
happens if you punt that to TLS without any channel bindings. I'm not in a
position to address that without help, I just believe there's a better
non-web flow here. It also creates a much more flexible field for phishing
to be addressed, since the client/IdP exchange is not a browser and a web
site.

The only issue to address in translating the profile over to SASL is the
fact that in a non-web case there's no real "responseURL" involved, which is
something that's baked into the standard ECP profile, but I think it can be
"emulated" with no particular effort in the interest of compatibility, or
removed at the cost of same.
 
> 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.

This makes sense if you're remaining compatible with something people *want*
to deal with, but IdP discovery is the last thing anybody operating an SP
*wants* to deal with. It's a gigantic usability problem, and arguably the
biggest reason why federation has scaling issues.

Anyway, it's on me to produce the draft, which I've started on (using yours
as a starting point, which I hope is ok).

-- Scott