RE: References

["Platt, Darren" <dplatt@securant.com>]

<Taken from Hal's message>
> Part of the reason for making this distinction is that I 
> favor the former
> over the latter for SAML.
</Taken from Hal's message>

I agree - "compact data value which has no inherent meaning" is better than
"some meaningful data ... presented in compressed and perhaps encrypted
form".  I agree, as well, that we're getting into design here - and that
this particular bit of design should be done in the bindings subgroup.

- Darren



> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Thursday, April 12, 2001 7:46 AM
> To: 'RL 'Bob' Morgan'; Evan Prodromou
> Cc: security-use@lists.oasis-open.org
> Subject: RE: References
> 
> 
> 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
> > 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-use-request@lists.oasis-open.org
>