OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] Simple Sign not so simple


Scott Cantor replied:
 >
 > =JeffH had scrawled:
 >  > 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?
 >
 > There's text in SAMLBind for this, we just forgot to copy it. This where I
 > agree with Sampo's point...you shouldn't have to read HTTP-Redirect to
 > understand this one. ;-)

Ok, so the text we have in saml-bindings-2.0-os addressing this appears to be 
at the end of section "3.4.4.1 DEFLATE Encoding" (line 624) and reads..

  "Finally, note that if there is no RelayState value, the entire
   parameter should be omitted from the signature computation (and
   not included as an empty parameter name)."


In reviewing sstc-saml-binding-simplesign-cs-01, I think a statement to this 
effect belongs in step 2 of section "2.5 SimpleSign Signature" (line 306). In 
reviewing that step, I can see where Sampo & Co.'s question came from.

I propose adding the above caveat from saml-bindings-2.0-os to step 2 of 
section "2.5 SimpleSign Signature" of sstc-saml-binding-simplesign-cs-01, like so:

   2. A string consisting of the concatenation of the raw, unencoded XML
      making up the SAML protocol message (NOT the base64-encoded version),
      the RelayState value (if present), and the SigAlg value, is constructed
      in one of the following ways (each individually ordered as shown):

        SAMLRequest=value&RelayState=value&SigAlg=value

        SAMLResponse=value&RelayState=value&SigAlg=value

      Note that if there is no RelayState value, the entire parameter should
      be omitted from the signature computation (and not included as an empty
      parameter name), resulting in a string of one of these forms:

        SAMLRequest=value&SigAlg=value

        SAMLResponse=value&SigAlg=value


Now, a reasonable question is "what have implementors actually done?" ;)

I'm hoping most all of you have intuitively done it the above way.

Feedback?

thanks,

=JeffH



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]