W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2006

RE: [fwd] [dix] fyi: SAMLv2: HTTP POST ?NoXMLdsig? Binding (from: Jeff.Hodges@neustar.biz)

From: Ed Simon <edsimon@xmlsec.com>
Date: Sun, 25 Jun 2006 19:51:00 -0400
To: <w3c-ietf-xmldsig@w3.org>
Message-ID: <E1FueNb-00018L-Fr@lisa.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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:40 UTC