- From: Ed Simon <edsimon@xmlsec.com>
- Date: Sun, 25 Jun 2006 19:51:00 -0400
- To: <w3c-ietf-xmldsig@w3.org>
I guess I should mention there is, of course, also the canonicalization of the <SignedInfo> element, not just the target XML. I won't go into detail here, but if the issue is to minimize signature processing work, I would propose creating a specification that profiles XML Signature to the basic needs of SAML. This could be done in the general case by closely defining a subset of XML Signature (much like WS-I has done for SOAP) and, optionally, creating a canonicalization method that, enforces that profile. The idea is to reduce the variability of the output bytes to the signature method. Then, as the bytes are always the same, computing the canonicalization becomes superfluous (the canonicalization method effectively means your canonicalization work is pre-done). In essence, you ultimately have what is in http://www.oasis-open.org/committees/download.php/18722/draft-hodges-saml-bi nding-noxmldsig-01.pdf except one is still supporting the XML Signature syntax. (The actual XML Signature, which does not envelope the base64 of the SAML, could be base64-ed as well and placed in an XHTML form control so that there is no non-XHTML. To me, an advantage of doing things the way is that apps can continue to use XML Signature processing for SAML while gaining the benefits and functionality in the proposed protocol. Anyway, hearing some of the rationale for the proposed protocol would be helpful. Regards, Ed _____________________________ Ed Simon <edsimon@xmlsec.com> Principal, XMLsec Inc. (613) 726-9645 Interested in XML, Web Services, or Security? Visit "http://www.xmlsec.com". New! "Privacy Protection for E-Services" published by Idea Group (ISBN: 1-59140-914-4 for hard cover, 1-59140-915-2 for soft cover). Includes a chapter, by Ed Simon, on "Protecting Privacy Using XML, XACML, and SAML". See the Table of Contents here: "http://tinyurl.com/rukr4". -----Original Message----- From: w3c-ietf-xmldsig-request@w3.org [mailto:w3c-ietf-xmldsig-request@w3.org] On Behalf Of Ed Simon Sent: June 25, 2006 15:56 To: w3c-ietf-xmldsig@w3.org Subject: RE: [fwd] [dix] fyi: SAMLv2: HTTP POST ?NoXMLdsig? Binding (from: Jeff.Hodges@neustar.biz) I would suggest that it might be more appropriate to call it "no Canonicalization" rather than "NoXMLdsig"; it is entirely possible, sensible, and widely practised to use an XML Signature to sign a base64-encoded string. The reason it is called XML Signature is because the signatue is expressed in XML, not because the hashed data has to be expressed as XML. Why not keep the XML Signature and use it to sign the base64-encoded SAML in the proposed protocol? Or use another pre-existing, non-XML-aware spec as Anders has suggested? Ed _____________________________ Ed Simon <edsimon@xmlsec.com> Principal, XMLsec Inc. (613) 726-9645 Interested in XML, Web Services, or Security? Visit "http://www.xmlsec.com". New! "Privacy Protection for E-Services" published by Idea Group (ISBN: 1-59140-914-4 for hard cover, 1-59140-915-2 for soft cover). Includes a chapter, by Ed Simon, on "Protecting Privacy Using XML, XACML, and SAML". See the Table of Contents here: "http://tinyurl.com/rukr4". -----Original Message----- From: w3c-ietf-xmldsig-request@w3.org [mailto:w3c-ietf-xmldsig-request@w3.org] On Behalf Of Anders Rundgren Sent: June 24, 2006 16:58 To: w3c-ietf-xmldsig@w3.org Subject: Re: [fwd] [dix] fyi: SAMLv2: HTTP POST ?NoXMLdsig? Binding (from: Jeff.Hodges@neustar.biz) Interesting, although I don't understand this completely. It seems that the signature only contains the actual signature value and no KeyInfo etc. If I had looked for a simpler (binary) solution, I would rather have used CMS. The primary (only) rationale for this proposal appears to be that canonicalization takes too much CPU. There is a risk that this may be based on non-optimal implementations rather than a fact. Anders Rundgren ----- Original Message ----- From: "Thomas Roessler" <tlr@w3.org> To: <w3c-ietf-xmldsig@w3.org> Sent: Saturday, June 24, 2006 07:39 Subject: [fwd] [dix] fyi: SAMLv2: HTTP POST ?NoXMLdsig? Binding (from: Jeff.Hodges@neustar.biz) FYI -- Thomas Roessler, W3C <tlr@w3.org> ----- Forwarded message from Jeff Hodges <Jeff.Hodges@neustar.biz> ----- From: Jeff Hodges <Jeff.Hodges@neustar.biz> To: Digital Identity Exchange <dix@ietf.org> Date: Fri, 23 Jun 2006 15:16:34 -0700 Subject: [dix] fyi: SAMLv2: HTTP POST ?NoXMLdsig? Binding Reply-To: Digital Identity Exchange <dix@ietf.org> List-Id: Digital Identity Exchange <dix.ietf.org> X-Spam-Level: Given the various issues with XMLdsig and discussions with various folks, Scott Cantor and I crafted a new SAML HTTP POST binding which doesn't rely on XMLdsig, but specifies optional signing of the conveyed messages, as "blobs". We've tentatively named the binding "HTTP-POST-NoXMLdsig". The working draft spec is here.. SAMLv2: HTTP POST ?NoXMLdsig? Binding [DRAFT] http://www.oasis-open.org/committees/download.php/18722/draft-hodges-saml-bi nding-noxmldsig-01.pdf The basic notion of this draft binding was well-received by the SSTC and the consensus on a recent SSTC concall was that we'd proceed with putting it on the SSTC/OASIS equivalent of "the standards track". Note that this spec is a *working draft* and some details will change, and comments are welcome. This binding could be leveraged/profiled in the DIX context in order to provide the capability for implementors/deployers to optionally use conventional sign-the-BLOB techniques, or the SXIP/DIX Message Signature/Verification technique, or no signatures. JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ----- End forwarded message -----
Received on Sunday, 25 June 2006 23:51:14 UTC