Shibboleth Developers

["Scott Cantor" <>]

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

No. A POST is inherently targeted at the IdP/WAYF, and there's no real
signal to a browser extension to do anything with it other than just do the
form POST to the IdP.

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

It's not. I don't think I said it was, but if we developed an alternative
binding for old requests at this point, it would be useless because none of
the deployed base supports it.

Of course, none of the commercial SAML 2 products support a new binding
either, but we could, and if it was at all useful it would get fed back
anyway.

> Your ideal browser client is beginning to sound a lot like the
> non-browser clients we have to accommodate with GridShib.

Browsers consume HTTP services, period. That's what matters, not the dances
they do for SSO or what you plug into them. Here, you have one little thing
you'd like to be able to inject into something that is otherwise 100%
vanilla web. ECP is definitely a way of doing that, but it's also a lot to
bite off *just* for that.

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

That of course is another matter. If that's ultimately the end of the story,
then we can stop trying to do anything to fix discovery, because it's
hopeless.

I have a mind to stop listening to people explain why nobody will ever use a
useful browser extension and just build one.

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

And that's a binding, not a profile. Same protocol, same message, just
different encoding into the response medium (HTML).

> In fact, why not just eliminate SP-first altogether?  You
> seem to be calling for a client-first browser profile...

No, I didn't call for that at all. And I don't think that's realistic.

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

No. I didn't say "change the request", I said "parse it". As in take a peek
at it to let the user see some of the information. Ultimately if it's a go,
the rest is SAML, you POST the original data using an existing binding.
There's no signature breakage.

-- Scott