RE: [security-services] Simple Sign not so simple

["Scott Cantor" <cantor.2@osu.edu>]

>  > 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.

For my purposes, no, it wasn't the intent. We don't force use of UTF-8
anywhere in SAML at the moment.

If people want to do it, that's a change for the spec, so...people can
decide I guess. If it's because some parsers can't handle anything but
UTF-8, I guess that's a reason.

> AFAIK, it doesn't really matter which we choose from a protocol
standpoint.
> Is there an implementation reason to prefer one over the other?

Yes, see my response. Generally what you get in your code via POST is
decoded. That's true with Redirect also, and I'd like to change that binding
too, but that's moot at this point. I wanted to make this binding a bit
simpler in that respect.

> 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?

No. It depends where you "look". It's encoded on the wire and inside the
POST body. It's decoded by the time most apps see it.

> 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. ;-)

-- Scott