Subject: RE: Access Control deferred?

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Sat, 19 Dec 1998 11:49:10 -0800

You have great points and I agree with all of them.  My major concerns about
access control are: 
 - it's a very tough area to do properly (taking into account all the
dependencies)
 - this work is being taken on elsewhere in Apps, and the CalSched group
might be able to take advantage of existing general solutions if CAP ACLs
can be put off for a while
 - Most of all, I'm very concerned about the schedule for CAP.  The plan is
very ambitious.

Lisa	

-----Original Message-----
From: Bob Mahoney [mailto:[email-masked]]
Sent: Saturday, December 19, 1998 5:09 AM
To: Lisa Lippert (Dusseault) (Exchange)
Cc: [email-masked]
Subject: RE: Access Control deferred?

>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.  

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: Sun, 20 Dec 1998 09:51:53 -0500

Lisa-

> - it's a very tough area to do properly (taking into account all the

It is, and I'm certainly not intending to diminish the difficulty.  It
might not be as intricate as the timezone work was (as he mumbles a small
prayer), but it won't be a no-brainer.

> - Most of all, I'm very concerned about the schedule for CAP.  The plan is

I'm partially concerned that if this work is not done in the initial draft,
it won't get done in a reasonable timeframe.  There have certainly been
examples in the past of vendors being most interested in printing "Supports
RFC9999!" on the box, and leaving on-going support as a much less urgent
matter.  I would not want to see vendors doing their own thing in this
space in advance of some promised future statement from us on the matter.
I do not expect that the vendors tracking this work wish to put out a lame
product, but I do know that they want this work *finished*.

This is not an optional "fluff" functionality.  It is the control over who
can access and modify important personal and enterprise information.  It
should be firmly in the "v1.0" feature set.

We all want this done ASAP.  But the schedule is not a "laws of physics"
barrier to doing the essential work.  We can't do everything, I know, but I
think this one we have to do.

-Bob

---

From: Pat Egen <[email-masked]>
Date: Sun, 20 Dec 1998 13:46:34 -0500

Lisa, which working groups are working on Access control and are any of the
participants on this mailing list working on those groups? If not, maybe someone
should be to ensure that the ACL's have some of the granularity required for
calendar access.  It's going to be different than whether or not someone has the
rights to see my mail, etc.  Calendaring could be needing to know is someone a
part of a team, do they only see "busy times", do they see nothing at all, can I
secure certain pieces of my calendar so that only members of my team can see the
data, etc.  How can this be done by a generic ACL definition? Maybe I'm missing
something here, but it seems like the CAP requirements need to set some sort of
guidelines at least.

---

From: Phil Wolff <[email-masked]>
Date: Sun, 20 Dec 1998 12:11:35 -0800

Do the current calendar specs provide enough data to allow an ACL policy engine to
formulate an intelligent decision?

It seems that we need at least a few more attributes:

- a policy engine URI. It may or may not be the originator's calendar server. It
might, for instance, be an LDAP service elsewhere.

- a revelation property for each element. This would tell the policy engine the
range of acceptable replies at the element level. For instance:
-- Viewer may Show this element
-- Viewer may Hide this element
-- Viewer may Hide this element's values but permit existence of values to be known
-- Viewer may Change this element

I'll leave to the practical among us whether to enhance the calender protocols to
support access control. But I'd like to see the first release contain enough raw
material that robust and useful ACLs can be formulated and applied.

- Phil

--

-------------------------------------------------------------
Phil Wolff
mailto:[email-masked]
home:  http://www.slip.net/~pwolff/
about: http://www.slip.net/~pwolff/identity/
AIM screen name: evanwolff
voice 1-510-444-8234