[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] sstc-bindings-extensions-02
>> >>I like the notion of essentially divorcing these two flows >>from each other and basically not trying to directly map all >>of the XML >>in <Request> to a URL, which I think is a losing proposition. >> >>General comments: >> >>Since the query string is entirely defined by this profile, I >>suggest saving space by reducing the size of the parameter names, >>particularly dropping the SAML prefix in each case (no, it's >>not much, but it's of zero-processing value). >> 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?). >>Doesn't base64 generally inflate the size of what it encodes? >>I would think straight URL encoding of the data per usual practice >>would make more sense in most cases. 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. I think one point in favor of URL encoding is that the output of base64 results in a string that may further require URL encoding (i.e., there is potential for further expansion even after base64 encoding). So it would seem preferable to go directly for URL encoding. I will make this change. >> >>Some of the length limitations seem a little tight, >>particularly the RequestID. I would imagine I'm not the only >>one who would have >>implemented their IDs as UUIDs, which are more than 20 bytes. >>I could special case this ID, but in general, I think we can relax >>some of these limits and still end up in fairly good shape, >>length-wise. >> How about hashing the UUID? Using SHA-1 you can always bring a value down to 20 bytes. 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 would prefer somewhat less hashing of URIs and things, and >>more SHOULDs about length. >> Sounds reasonable. I will make a pass thru the document and see where these suggestions might apply. >>-- Scott >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]