OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[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