[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]