Shibboleth Developers

[Tom Scavo <>]

On 12/2/05, Scott Cantor 
<>
 wrote:
>
> ... one could
> imagine defining a new SAML 2.0 binding from the SP that could involve
> exploiting a MIME type (or yes an <object> tag ala InfoCard) to trigger a
> browser plugin.

Why is a new binding needed?  Can't you just use HTTP POST?

> The idea came up in the context of phishing, in a particular Liberty use
> case, and it seemed to me that any AuthnRequest is certainly an opportunity
> for that and could benefit from a user-controlled layer.

Why is SAML2 AuthnRequest any more susceptible to phishing than, say,
a Shib Authentication Request?

> Anyway, the idea would be to really avoid the need for a ECP in a lot of
> simple cases where all you want is just the ability to let the client direct
> the request, and make sure that the user knows that the IdP they get to is
> the one they configured.

Your ideal browser client is beginning to sound a lot like the
non-browser clients we have to accommodate with GridShib.  This is an
important point...there will be resistance to specialized clients. 
Any profile that works with a plain vanilla browser will have an
inherent advantage.

> The new binding would just enable the plugin to extract the request
> information and then relay it to the IdP using one of the normal SAML
> bindings.

Seems like you're talking about a new profile, not a new binding.  The
SP can POST a SAML AuthnRequest as usual, but with an <object> tag
included.  In fact, why not just eliminate SP-first altogether?  You
seem to be calling for a client-first browser profile...

> If the plugin wanted, of course, it could get more exotic and
> parse the request to help the user, but that isn't strictly necessary.

Signed AuthnRequests would be a problem in this case, right?

Tom