W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2002

RE: "Onion model" explained

From: Joseph Hui <Joseph.Hui@exodus.net>
Date: Thu, 25 Jul 2002 14:01:53 -0700
Message-ID: <45258A4365C6B24A9832BFE224837D551D1CDD@SJDCEX01.int.exodus.net>
To: "Hal Lockhart" <hal.lockhart@entegrity.com>
Cc: <www-ws-arch@w3.org>
Hal,
 
FWIW, you did say to the effect of "authN by itself
was *NEVER* enough."  That was tantamount to 
using "always" instead of "often" in that glossary def.
 
Anyway, this discussion has degenerated into something
of little value, and thus have no interest in protracting.
So it's done for me.
 
Joe Hui
Exodus, a Cable & Wireless service
=================================
 
 ----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Thursday, July 25, 2002 1:22 PM
To: Joseph Hui; Pete Wenzel
Cc: www-ws-arch@w3.org
Subject: RE: "Onion model" explained



Joe, 
  
> Hal, 
> 
> Note the keyword "often" in the glossary definition. 
> The arguments you and Pete made was to make it "always." 

This is NOT the case. I have consistently argued that the information could be used for Authorization, Audit Trail, Confidentiality, verification of Integrity and many other ways. I am also willing to stipulate that the informaiton might not be used at all, however in that case, it would have just as good, or even better in that case, for the Authentication to have not been done. Therefore, I would not consider this a usecase to motivate the provision of Authentication. This is what I said I meant by "not interesting."

My distinction is that Authentication is an information gathering step, whereas all of these other things are information use steps. Note that the phrase "often as a prerequisite" in the definition makes it clear that the "allowing access" part is not a part of authentication, but a subsequent step.

> What Pete said amounted to like saying axiomatically that 
> if you hear a person speak and recognize whose voice it is, 
> then it can be inferred that the person is authorized to 
> speak to you. 

Not at all. That is how I interpret your claim that Authentication can be used alone. I would say that recognizing the voice is Authentication and deciding to have a conversation (or not) is Authorization.

> It's apparent the above line of reasoning makes sense 
> to you and not to me.  That's old news.  So there's nothing 
> in it for me to loop around a trolling line. 

I think the real difference of opinion is around what the term Authentication encompases. I assert that Authentication only includes the verification. Any use of the data is part of some other security process. I further assert that both definitions I cited make this clear.

Hal 

> 
> Joe Hui 
> Exodus, a Cable & Wireless service. 
> ===================================== 
> -----Original Message----- 
> From: Hal Lockhart [ mailto:hal.lockhart@entegrity.com] 
> Sent: Tuesday, July 23, 2002 11:52 AM 
> To: 'Pete Wenzel'; Joseph Hui 
> Cc: www-ws-arch@w3.org 
> Subject: RE: "Onion model" explained 
> 
> 
> I agree with Pete. In my mind you have an AuthZ policy with 
> two distinct steps, something like this: 
> 1. If (authentication of suitable type does not suceed) 
> ignore message 
> 2. Update the info associated with the party sending the request. 
> Since you made an implemention choice to do this in program 
> code, you choose to view these steps as part of the 
> application. However, they could have just as well been done 
> using an authorization policy infrastructure, in which case 
> it would be obvious that this constituted authorization. 
> The WSA glossary defines Authentication as: 
> To positively verify the identity of a user, device, or other 
> entity in a computer system, often as a prerequisite to 
> allowing access to resources in a system 
> The SAML definition is similar: 
> To confirm a system entity's asserted principal identity with a 
> specified, or understood, level of confidence. 
> Neither says anything about MAKING USE of the identity. I 
> claim that as soon as you do so, you are doing Authorization 
> or generating Audit trail or something else. 
> Hal 
> > -----Original Message----- 
> > From: Pete Wenzel [ mailto:pete@seebeyond.com] 
> > Sent: Tuesday, July 23, 2002 2:11 PM 
> > To: Joseph Hui 
> > Cc: Hal Lockhart; www-ws-arch@w3.org 
> > Subject: Re: "Onion model" explained 
> > 
> > 
> > Thus spoke Joseph Hui (Joseph.Hui@exodus.net) on Mon, Jul 22, 
> > 2002 at 08:03:51PM -0700: 
> > > >From:      Hal Lockhart [ mailto:hal.lockhart@entegrity.com] 
> > > [snip] 
> > > >1. I still maintain that Authentiation is never an end 
> in itself, 
> > > >   it is a step that collects data to be used in some other 
> > > >   decision. 
> > > ... 
> > > The point I made, as I recall, was to show the fallacy 
> > > of "authN by itself was *never* enough" [Assertion A]. 
> > > ... 
> > > here's one heartbeat app with a negative trigger. 
> > > Every N seconds Alice sends an "I'm-alive" signal to Bob. 
> > > By sharing a common secret, only Bob knows how to 
> > > authenticate the signals from Alice.  Bob will invoke 
> > > Proc A if M heartbeats from Alice are missed. 
> > > See?  No authZ whatsoever, 
> > 
> > But authentication of Alice's signal has a side-effect:  it causes 
> > Bob to reset his watchdog timer-counter.  Signals that cannot be 
> > authenticated as coming from Alice should not result in the reset 
> > behavior.  In other words, we can say that Alice is authorized to 
> > reset Bob's counter (or, equivalently, that Alice is authorized to 
> > prevent Bob's execution of Proc A). 
> > 
> > > not even Integrity or 
> > > Encryption (as in the cases of H-MAC or dsig), 
> > > was involved.... 
> > 
> > Yes, these have independent uses; clearly sometimes AuthN+AuthZ is 
> > enough.  However, the heartbeat example doesn't demonstrate 
> that AuthN 
> > is enough by itself, because there is more taking place than just 
> > AuthN. 
> > 
> > --Pete 
> > Pete Wenzel <pete@seebeyond.com> 
> > SeeBeyond 
> > Standards & Product Strategy 
> > +1-626-471-6311 (US-Pacific) 
> > 
> 
Received on Thursday, 25 July 2002 17:01:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:03 GMT