[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: References
Bob has appropriated not only my name, but my thoughts. I agree exactly with everything he says below. --bob Bob Blakley (blakley@tivoli.com, regardless of what the email headers may say!) Chief Scientist Enterprise Solutions Unit Tivoli Systems, Inc. (an IBM Company) "RL 'Bob' Morgan" <rlmorgan@washington.edu> on 04/11/2001 05:58:17 PM Please respond to "RL 'Bob' Morgan" <rlmorgan@washington.edu> To: Evan Prodromou <evan@outlook.net> cc: security-use@lists.oasis-open.org Subject: Re: References Evan: > I really think that there is a strong requirement for some kind of > abbreviated form of "assertion handle" -- a way to get a full > assertion from a small bit of data. XML is wordy, and we need small > data for browser bindings. I suspect my response was one of the ones that disappointed you. Let me explain. The *requirement* that I think we all agree on is that bindings for transmission of SAML data via browsers (hence in URLs, cookies, HTML forms, whichever of the available methods is appropriate) be defined. It is claimed by you and others that a requirement of this specific binding is some smaller form of assertion, in particular a smaller form called a Reference. Presumably this is based on the notion that the various browser communication methods have size limits, and that assertions will in some cases exceed those limits. While I suspect we may, in the process of designing SAML support for browser bindings, come up with something like a Reference, I think we will do so only via a process something like this: 1. We will consider the various means by which browsers might carry SAML data (assertions, messages, whatever), and decide which ones SAML will support. 2. We will identify which versions of which browsers we need to support. 3. We will obtain hard documentation on the size limits of the chosen communication methods in those browsers. 4. We will consider which SAML data browsers will have to carry, and, once we decide how it will be formatted, and what the data objects are, we'll have some idea of typical object sizes. We'll also consider the security issues involved in communicating via browsers, which may affect the form of data being sent. 5. We will, if the identified size limits are a problem for carrying the identified data objects, consider various ways of solving that problem: gzip compression, binary XML, References, etc, and determine which ones we want to support. We'll also consider what formats can support the security requirements. And at that point, after all that engineering which presumably will happen in the bindings subgroup, we'll know whether we need References and what they should look like. There simply is no requirement for them at this point, that I can see. Saying that there is is doing engineering at requirements time, which is a mistake. That's why I voted to remove this requirement. - RL "Bob" ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: security-use-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC