Subject: Re: My proposal for CALSCH-ACLs

From: "Frank Dawson" <[email-masked]>
Date: Fri, 18 Sep 1998 10:34:45 -0400

Doug:

I STONGLY disagree with the initial CAP draft having ACL control at the
calendar component or property level. This atomic level of ACL is beyond
what we need.

If you are serious about a CAP draft by year's end, then we need focus on
defining a CAP spec based on simplified (but useful) set of requirements for
the CUA/Calendar Store interactions. You can't say that you want an initial
draft of a spec by year's end and then step into a complex arena, such as
calendaring and scheduling security, and try to boil the ocean on function
enablement.

You also need to look at accepted practice. The majority of enterprise
calendaring systems out there today have an ACL model that is based on
calendaring capabilities, not calendar structure. As a matter of fact, this
approach of basing "rights" specificity on capability is very client
centric. It provides "rights" that directly map to what the CUA is
providing. For example, a simpler ACL model would be based on rights that
amount to booleans for the following :

   No Access (provided by FALSE to all of the following rights)
   View Busytime Information
   View Public Events (two more for To-dos and Journal entries)
   View Private Events (two more for To-dos and Journal entries)
   View Confidential Events (two more for To-dos and Journal entries)
   Add Public Events (two more for To-dos and Journal entries)
   Add Private Events (two more for To-dos and Journal entries)
   Add Confidential Events (two more for To-dos and Journal entries)
   Change Public Events (two more for To-dos and Journal entries)
   Change Private Events (two more for To-dos and Journal entries)
   Change Confidential Events (two more for To-dos and Journal entries)

Defining a "rights" component for CAP ACL beyond this is not acceptable for
a near term CAP spec. Something beyond this level of function enablement is
counter to the theme of scheduling the CAP effort to get a draft out by year
end. It would be beyond what is provided for in the majority of enterprise
calendaring applications today. It would also be defining an ACL
infrastructure that may present significant problems mapping into whatever
directory and common IETF ACL architecture is defined in the near future.

- - Frank Dawson

---

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Fri, 18 Sep 1998 16:05:05 -0700 (PDT)

> From: "Frank Dawson" <[email-masked]>
> 
> I STRONGLY disagree with the initial CAP draft having ACL control at the

There were strong suggestions that ACLs at this level were needed
in CAP. I think the issue can be resolved soon by having a well
defined set of fallbacks.

ACLs over the wire is an administrative issue. There is no
reason that all calendar clients would need to know they exist.
I do think that it is important to define the ACLs so that client
can understand the model and can prepare for operations that
will fail with permission denied.

A CUA without understanding the ACL model, might:

  Expect to have 100% control over the calendar *if* the name of the
  calendar is the same as the users authenticated users name.

  Another CUA (as described by the fellow from MIT at the LA IETF),
  Might know that all calendar entries are never deleteable as
  their server must enforce this per some kind of record keeping law.

A CUA that understands the ACL model, can then:

  Understand that they might get permission denied without knowing
  the details of why it happened.
  
  Might implement a (yet undefined) command to find what ACLs the
  user has and adjust the CUA at runtime to guide the users operation
  of the CUA.
  
I think there MUST be SOME administration in CAP. Not all CUAs will
need to implement administration commands. I throw ACLs into administration.

> calendaring and scheduling security, and try to boil the ocean on function

Yes I would like an initial draft by the first of the year.

The security issues have been address in other drafts/RFCs that
have access control. There really is not anything new. We just
have to map the ideas that others have discussed into CALSCH.

Calendar store interactions, I will be sending out my proposal
on that Tuesday (22nd) or so :-)

>    Change Confidential Events (two more for To-dos and Journal entries)

This is almost the Sun legacy model. However for shared calendars using
iCalendar, how would you allow a user to update their PARTSTAT,
while at the same time not allowing them to alter the rest of the
calendar entry?

The ACL model that I have proposed will also work with the model
you have above. I made sure of that as Sun has almost same model.

> end.

I don't agree. Even if not all of the ACL model makes it in the draft, I
think we need to define ACLs for the reasons I have stated above.

> It would be beyond what is provided for in the majority of enterprise

I agree that it does expand the access control model.

I *do* think that it is mapable into existing CUAs.

As to any common IETF ACL architecture that may be defined in
the future. We in the CALSCH-WG should spend the time to make
sure that if anyone ever submits such a draft that it allows
for CALSCH needs.

ACAP (as Chris Newman pointed out) has a generic ACL administrative
model. I think it could get a bit verbose. I see no conflict here.
And I have already thought through an "ACAP ACL command" to 
"CALSCH ACL data" mapping that would have to be done if ACAP
were used for administration of the iCalendar server.

The only thing that I wish ACAP would have done is differentiate
between write Vs (append Vs modify). Append Vs modify would have
to be done with the use of digit rights (RFC2244 ACAP section 3.5).

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/dougr.html
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: "Frank Dawson" <[email-masked]>
Date: Mon, 28 Sep 1998 10:12:14 -0400

>defined set of fallbacks.

<frd>I disagree. Taking an approach of defining CAP based on a fundamental
assumption that you will have a critical-success-factor dependence on the
use of fallbacks to address mismatches between vendor support for a central
functions of the protocol is a non-starter. If we are so fall apart on the
level of specificity of access rights architecture, then it doesn't sound
like this feature should be included in the draft.

Let me repeat, access rights should specify a C&S feature-specific
capability, not a datum access-specific capability. iCalendar is an on the
wire representation of calendaring data. It was not mandated for the
persistence format for the calendar store. Implementations will demonstrate
interoperabiity even though they are using different storage architectures
and formats. For example, some calendar servers will keep a cache of busy
time data. Others will dynamically generate busy time on request, but not
depend on such a separate store of busy time information. Yet, we want to
have an access right that indicates that certain calendar users may or many
not have the rights to access my busy time information. Such a scenario is
clear proof to me that we should not define a CAP access rights architecture
that is based on datum-access, but rather it should be defined on general
calendar or scheduling capability access.</frd>

---

From: "Alec Dun (Exchange)" <[email-masked]>
Date: Mon, 28 Sep 1998 14:18:48 -0700

Yep.  The propertly level ACL requirement comes from scenarios such as
letting some people see when your appointments are, while not exposing what
the appointments are about or who you're meeting with.

Quite a number or vendors I talked to wanted fine-grained control over what
properties could and could not be seen on a per/user basis.

Thanks,
Alec.

-----Original Message-----
From: Doug Royer [N6AAW] [mailto:[email-masked]]
Sent: Friday, September 18, 1998 4:05 PM
To: [email-masked]
Subject: Re: My proposal for CALSCH-ACLs

  

-Doug

---

From: "Geoff Coupe" <[email-masked]>
Date: Tue, 29 Sep 1998 18:40:12 +0200

Folks,

I agree strongly with Alex, and would add that this is not just a "vendor
requirement". I work in a services company, and we already have the
requirement that we want to expose elements of our calendars to clients on
an organisational basis. Thus, client A would be able to see appointments
relating to his/her organisation, client B would be able to see appointments
relating to his/her organisation, and so on. Internally, all of my
appointments (apart from those that I have marked personal/private) would be
visible to my colleagues. The rationale is that this capability is
demonstrating good customer focus, while providing separation on an
organisational basis. You can get some good competitive information if you
have totally free access to calendars!

I can also see that with the enforcement of the new European Data Privacy
act next month, that this will have some impact on what we are expected to
do in a business context.

Geoff Coupe
Shell Services International

-----Original Message-----
From: Alec Dun (Exchange) <[email-masked]>
To: 'Doug Royer [N6AAW]' <[email-masked]>; [email-masked]
<[email-masked]>
Date: Monday, September 28, 1998 11:35 PM
Subject: RE: My proposal for CALSCH-ACLs