Subject: RE: Access Control deferred?

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Tue, 15 Dec 1998 15:53:31 -0800

HTTP is an example of a protocol that allows access to items (web pages)
without defining how access control is done.  It only provides an error code
to be used if access is denied.  Access control is done out-of-band.  Since
HTTP is clearly not "unacceptable", we had the idea that maybe we could
delay defining how to do access control for the first version of CAP. 

If we leave access control out of CAP, that does not stop implementations
from doing access control, e.g. through an administrative interface, and it
does not stop implementations from respecting access control settings.  The
proposal is that CAP would just avoid saying how to set access control in an
interoperable fashion.  

I'm glad to see so many comments on the list lately about our requirements
-- is any other input on access control??

Lisa

-----Original Message-----
From: Bob Mahoney [mailto:[email-masked]]
Sent: Tuesday, December 08, 1998 9:17 AM
To: [email-masked]
Subject: Access Control deferred?

Yesterday during the meeting I asked about the conflict between the
deferred items in section 4.9 and the apparent inclusion of security
measures in the slides shown.  Can one of the document authors clarify this?

I am concerned that we are designing an access protocol without access
control.  That would be unacceptable.  Clients need to provide a mechanism
for users to allow or disallow access to their personal calendars, and
relying on an administrator to take this action clearly does not scale.
(We consider our organization's calendar users to number ~16,000)

The slides seemed to conflict with the draft.  If I'm merely confused, can
someone clarify?

>4.9     Access Control (deferred)
>
>The ability to get and set access control data on calendars and
>calendar components is useful, but beyond the scope of the initial
>CAP specification. A CS may apply access control entries to calendars
>and components, but CAP need not specify how these are to be set and
>retrieved. Access control entries could be set and retrieved by
>administrators on the CS through another protocol. Additionally, a CS
>can enforce the class of each component, by restricting access to
>"confidential" and "private" components, without any design in CAP to

-Bob
>allow this.

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 16 Dec 1998 20:44:49 -0500

At 03:53 PM 12/15/98 -0800, Lisa Lippert (Dusseault) (Exchange) wrote:
...
>proposal is that CAP would just avoid saying how to set access control in an

"e.g. through an administrative interface"

Ack! I wouldn't want to administer a system where 20,000 users had to go
through some seperate adminsitrative, and probably non-interoperable,
interface to change a delegation or a read privilage. I certainly wouldn't
buy such a system.

I think there is a lot of work to do on the requirements still.

Paul

---

From: Bob Mahoney <[email-masked]>
Date: Sat, 19 Dec 1998 08:09:02 -0500

>proposal is that CAP would just avoid saying how to set access control in an

Having a separate administrative interface really is a losing idea.  I'm
really not sure how the customer demographics for the large vendors breaks
down, but for anything larger than a small work-group, this just won't fly.
 The end-user demands for maintaining access control on their calendars
could represent a significant workload on the administrator.  I expect that
most administrative folks already have plenty of time-sensitive work thrown
at them by their users.

(Wander down to the network/system admin folks in your building, and ask
them if they want to take this task on for your organization...  :-)

That this doesn't *stop* implementations from doing access control brings
up an interesting thought.  If a particular feature, like access control,
is present in most vendor's currently shipping products, doesn't that by
itself make a strong argument that an interoperability protocol in this
space should implement it as well? 

-Bob

---

From: Bob Mahoney <[email-masked]>
Date: Sat, 19 Dec 1998 09:57:17 -0500

>most administrative folks already have plenty of time-sensitive work thrown

I didn't word this well.  I realize this function doesn't *need* to require
human intervention.  My point was intended to be that, without an
agreed-upon and standard methodology, it won't work for all users to all
stores.  The exception cases (probably any case where different vendor's
products interact) would probably require some sort of intervention.

Access control really is an important feature, and we should make certain
that it's part of this standard, even if it's hard. 

(Now on to parse Doug & Frank's proposal...  :-)

-Bob