[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: References
Should we add the concept of a reference and token in our domain model and/or glossary? Copying from Hal: Reference: An identifier for an assertion. related to all assertions Token: An compressed and perhaps encrypted form of data Dave > -----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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC