[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Non-browser HTTP binding for SAML
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]