RE: References

[Hal Lockhart <hal.lockhart@entegrity.com>]

I agree with the Bob's and I believe I said so in my ballot. This is
engineering not a requirement.

However I have a terminology nit to pick.

I would like to suggest the term Reference be reserved for a compact data
value which has no inherent meaning, but simply acts as means to identify an
Assertion and perhaps prove it refers to the party presenting the reference.
Note that this meaning is consistent with the use of the term in C++ and
Java as well as in scholarship.

This is distinct from a scheme in which some meaningful data is presented in
compressed and perhaps encrypted form. Ticket or Token might be an
appropriate term for such an item.

Part of the reason for making this distinction is that I favor the former
over the latter for SAML.

Hal

> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu]
> Sent: Wednesday, April 11, 2001 6:58 PM
> To: Evan Prodromou
> 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
>