RE: [security-services] sstc-bindings-extensions-02

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

> If at all possible, I would like to hang on to the SAML 
> prefix. Think of it as a crude form of XML's "fully qualified name"; it
> helps ensure that names in the search part don't clash (and if they do,
> hey, why is someone else using the SAML prefix?). 

Right, except that this redirection URL is entirely defined in your profile. There can't be any other parameters but the ones you
define here. Even put that in as a MUST if you like. Any other state is carried "by reference" in the Relay State.

> I think it is a bit of a toss up in terms of which encoding would lead to
> greater binary data inflation. I am less familiar with URL encoding but I
> agree that it would do the job.

Basically, if you have an unusual character, it gets turned into three bytes, whereas base64 automatically expands out every chunk.
So usually the URL encoding would be smaller unless you had an awful lot of funny characters, or something internationalized.

> How about hashing the UUID? Using SHA-1 you can always bring 
> a value down to 20 bytes.

That would work.

> Admittedly, this is a somewhat nasty way to generate IDs. At the same time
> requiring strings to have upper bounds is reasonably important here. What
> would be an acceptable limit on RequestID?

I could say 32 or 36 selfishly, since that's what a UUID is in hex (without or with the traditional dashes, respectively), but I can
live with the hash.

The point I'm making in general is that if you look at the Liberty 1.1 profiles spec, you can find their estimate of the upper bound
of their URL AuthnRequest, and it's not *that* large. And that includes a lot of stuff we don't have here, like a signature, so I
don't think your flow is anywhere near getting in trouble.

-- Scott