wrote:
> In recent interop testing we have found several points worth clarifying.
excellent, thanks for the feedback.
> 1. Spec says that whitespace inside the XML is preserved. It would
> be helpful to mention that whitespace before and after the
> XML should also be preserved. Or else forbid the leading and
> trailing whitespace.
good point... or... hm, does it really matter? What you feed in as the value
of the "SAMLRequest=value"/"SAMLResponse=value" construct assembled in step 2
of section 2.5, is just going to get extracted and validated on the other end,
as a string of bytes -- so does it matter?
> 2. It would be worth mentioning that in addition to the XML document,
> also the processing instructions, etc. need to be preserved. Or
> else forbid the <?xml ...> preamble.
again, does it matter?
> 3. A stance should be taken on use of UTF-8 encoding (presumably
> this is the only encoding allowed by the binding).
Ah, clarify this in other words? I guess we assumed since the macroscopic
encoding is XML that that spec would address any byte-level encoding questions.
> 4. A stance should be taken on the UTF byte order mark (BOM). I think
> it should be outlawed.
rationale for explicitly excluding it? What one is signing is just a string of
octets...
> 5. Is the SigAlg included in the signed data in URL encoded form
> or not, i.e.
>
> SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1
>
> or
>
> SigAlg=http://www.w3.org/2000/09/xmldsig#rsa-sha1
hm...
oh, ok, I think i get what you're asking, good question.
AFAIK, it doesn't really matter which we choose from a protocol standpoint. Is
there an implementation reason to prefer one over the other?
And does it really matter? In that if one is decoding a message signed&bound
according to this spec, they can just look at the SigAlg value and "tell" by
inspection which encoding was employed. yes?
> 6. Handling of following special cases should be clarified
> a. Response to request that had empty, but present, RelayState.
> b. Response to request that had no RelayState
>
> My reading of the spec as it stands is that in both cases
> the material that is signed will be
>
> SAMLResponse=...&RelayState=&SigAlg=...
>
> I.e. the RelayState= label is present in the signature in
> all cases irrespective of whether the RelayState was supplied
> in the request.
ok, so this obviously isn't clear in the spec because otherwise you wouldn't
have this question.
Our intent is that "...RelayState=value..." is _optional_ in the octet string
that is constructed in step 2, and subsequently fed into the signature
function in step 3 of section 2.5.
Can you suggest a way it can be clarified?
> 7. For debugging and also clarification of the material to be signed,
> the example should have additional section that shows the material
> that was signed.
ok. can you pls provide an example?
=JeffH
