RE: [security-services] Non-browser HTTP binding for SAML

["Scott Cantor" <cantor.2@osu.edu>]

> Interestingly I was having a similar conversation (one of the reasons I
> was late to the call). Dealing with "form posted" content even in a
> server-to-server mechanism isn't difficult because most of the tools
> handle this for you. So the servlet just pulls them apart and puts them
> in a hash-map.

Sure.

> However, the point is well made... and if some transport
> mechanism allowed for signing that would be fine.

Yeah, but this particular transport doesn't, and has a lot of politics and
entrenched maintainers.
 
> At AOL we don't
> require the "form post" syntax, but are just using it because it more
> closely matches what's already in SimpleSign and we were/are trying to
> stay as close to the standard as possible.

So, I guess the question is how useful it would be to stay with form post
and design a generic binding for SAML that allows for additional data (like,
say, your application message). Sounds like taking REST to its logical
conclusion and making the XML part itself optional.

> P.S. I'm guessing an OAuth binding would also just put the XML in
> plaintext in the message and would remove the "form post" syntax. The
> only reason to keep something like the "form post" syntax is if
> additional elements are desired to be combined with the SAML message.

I think there's perhaps more reason than that. It's just not practical today
to sign an HTTP message any other way. I keep thinking S/MIME should be the
answer, but it doesn't seem to be.

-- Scott