Yes, for example, the first SAML Interop
used SSL only with the Artifact Profile.
I don’t think there is any problem
with inclusive c14n unless you stick the signed material (assertion) into a
surrounding XML document. None of the web browser profiles (the focus of early
work) do this. The WSS SAML Token Profile does this, but it was not approved
until 2004.
The reason for the change was not that we
experienced any problems. Excl c14n did not exist when SAML 1.0 was finished. When
excl c14n became available, its advantages for applications such as WSS were
recognized and the SAML specs were adjusted accordingly. We switched to always
using excl c14n for uniformity, although the use of incl c14n is perfectly
satisfactory in many cases.
Strictly speaking, the problems you might
encounter are not Interoperability (each algo is identified in the Signature
element and Incl if anything is more pervasive) but rather a matter of spurious
verification errors. In the WS-I Eve Maler proposed lumping these under a
general category of Operational errors, to distinguish them from
Interoperability problems or Security vulnerabilities.
Hal
From: Cahill, Conor P
[mailto:]
Sent: Tuesday, March 14, 2006 9:19
AM
To: Brian Campbell;
Subject: RE: [saml-dev] (ex / non
ex) canonical XML
I think many early implementations worked
without the need for signatures (e.g. artifiact across browser and unsigned
assertion on trusted back channel).
Conor
From: Brian
Campbell [mailto:]
Sent: Tuesday, March 14, 2006 9:15
AM
To:
Subject: [saml-dev] (ex / non ex)
canonical XML
All,
Forces beyond my control have taken me on a little trip back
in time to look at SAML 1.0 (I didn’t get involved in this space until
after SAML 1.1 was out so this has been an interesting learning experience for
me). I see that one of the major differences between dot zero and
dot one is changing the recommended c14n method from canonical XML (http://www.w3.org/TR/2001/REC-xml-c14n-20010315) to exclusive canonical XML (http://www.w3.org/2001/10/xml-exc-c14n#). I can see why this change was made and,
although I’ve not yet had the pleasure, I can imagine that there were
some interoperability problems when trying to use the non-exclusive
transform. My question is - how did SAML 1.0 implementations deal with
this? Were they only able to interoperate when signatures where applied
to the response in the post profile? What is the value of a signed
assertion if the signature cannot be verified independent of its original
document context (I guess there isn’t one and that’s why 1.1 made
the change but did implementations try to work around it somehow)? Did
implementers end up just using exclusive in spite of the spec recommendation?
I would appreciate any historical perspective that can be
provided by those of you that have been involved with stuff longer than I.
Thanks,
Brian
By the way, the sstc-saml-diff-1.1-draft-01
document has proven to be a very informative resource - I’d like to say
thanks to Prateek, Dipak, Jahan and Robert.
