[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