RE: [security-services] Groups -sstc-saml-bindings-2.0-draft-05-diff.pdfuploaded

Sorry for the extra version yesterday, wasn't sure how fast I'd get this one
done. The change bars in this diff are against -03, so -04 can be ignored.

Continued to revise overall presentation of some of the material, and I've
added a proposal for what I'm calling the HTTP-Redirect/POST binding, which
transports SAML messages via a user-agent intermediary.

This effectively replaces the binding aspects of the browser/POST profile
with a protocol-independent version that defers specific message content and
protection requirements to protocol or profile specs. In ID-FF, support for
URL-encoding vs. form POST of XML is essentially unified in the interest of
interoperability.

The tricky bit is the URL encoding, particularly the acknowledgement that
you need not enable anything and everything to be usable over a URL to make
it worth allowing *something* over a URL.

A few other points to highlight, but can wait for a call.

As I've said on any number of occasions, I believe that "artifacts" are
another binding and are simply a URL-encoded message reference followed by a
SOAP exchange. End product is a protocol message at the artifact receiver,
same as any other binding. ArtifactRequest in core is not specified for
this, but I would like to change that. It may be odd to send an
ArtifactRequest and get back an AuthnRequest, but it is architecturally
sound, IMHO.

-- Scott

"Rooting for the Yankees is like rooting for the house in blackjack."