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, 11 Jul 2002 16:27:32 -0700
Message-ID: <45258A4365C6B24A9832BFE224837D551D1C9B@SJDCEX01.int.exodus.net>
To: "Christopher B Ferris" <chrisfer@us.ibm.com>
Cc: "Hal Lockhart" <hal.lockhart@entegrity.com>, <www-ws-arch@w3.org>

> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
>> >If Alice makes a decision about her interaction with Bob,
>> >that is an Authorization decision.
>> No, not necessarily.  Alice may interact will anyone before making
>> an authz decision.  The interaction may only involve handshake
>> and trivial application data exchange.  That is, Alice's security
>> policy may say she's only concerned with really whom she is shaking
>> hands with, AND NOTHING MORE.
> But does that not constitute an authZ decision?

Maybe I was trying to make a good point using a bad example.
In day-to-day convention, one can, as you and Hal did, indeed validly
interpret it as an authZ decision, by inferring Alice's sec policy
to be, in plain English: authorize authenticated Bob X.

But in sec-speak convention (as I know it or am accustomed to),
the same policy will be stated as, in two discrete parts:

   1) Authenticate all peers.
   2) Authorize Bob X.

The authZ part kicks in if only if the authN part succeeds.

Now, the Alice sec policy I was using to drive the authN-alone
point across is:

   1) Authenticate all peers.

There's no X inferred.

Let's use this same authN-only sec policy in my next example,
but forget about Bob.  
Alice doesn't care who sent her messages, i.e. authorization
is called for.  But she does care about the senders
authenticating themselves, not for the purpose of
authorizing anything for the senders' benefit, but of knowing
who to track down and get even with in case she's offended
by a message, like one that contains cyber-Anthrax, hopefully
there's no such thing.  In practice this may go as: Alice
receiving an xml-dsig'ed message; validating the digital
signature; reading the message upon positive authentication.
Realize that the last step may again be interpreted as
a form of authZ in day-to-day convention, but not in the
traditional sec speak that keeps authN and authZ as discrete
security aspects/facets, and only authN is in the play
in this example.

Another no-authZ example, closer to reality, is that when
you buy a book from Amazon.com online, you only care about 
http://www.amazon.com authenticating itself to be the
real McCoy (through your properly configured browser
that will on your behalf verify the cert that from some
https://xyz.amazon.com site) before revealing your
credit card number.  Assuming you're like me and most
Internet shoppers, you don't really care to keep
an ACL sheet by your keyboard for authorizing who
may sell you books.  

>> >Presumably she requires some proof of possesion, a certificate
>> >alone proves nothing, but this is a side issue.
>> A certificate proves nothing?  By certificate I meant a cert 
>> that Alice
>> deemed trustworthy, say a CA signed cert.  Now, if a CA signed cert,
>> which millions of Internet shoppers trust their money to, 
>> means nothing
>> to you, then I don't think we'll go anywhere on the issue.
> A certificate alone means nothing, even one that is CA 
> signed, absent a CPS.

Well, it means whatever Alice deems trustworthy or otherwise,
assuming Alice already practices "safe certs," such as
checking the CRL (Cert Revokation List) with due dilligence.


Joe Hui
Exodus, a Cable & Wireless service
Received on Thursday, 11 July 2002 19:26:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:57 UTC